X264 Development Newsletters - Revision history

DoesItReallyMatter: +{{Back to|Category:x264}}

2019-03-27T08:35:55Z

+{{Back to|Category:x264}}

← Older revision		Revision as of 08:35, 27 March 2019
Line 1:		Line 1:
	{{Lowercase}}		{{Lowercase}}
			{{Back to\|Category:x264}}
	This is an archive of the x264 Development Newsletters.		This is an archive of the x264 Development Newsletters.

DoesItReallyMatter: +{{Lowercase}}

2019-03-09T20:22:06Z

+{{Lowercase}}

← Older revision		Revision as of 20:22, 9 March 2019
Line 1:		Line 1:
			{{Lowercase}}
	This is an archive of the x264 Development Newsletters.		This is an archive of the x264 Development Newsletters.

J-b at 13:55, 30 September 2013

2013-09-30T13:55:42Z

← Older revision		Revision as of 13:55, 30 September 2013
Line 603:		Line 603:
	three-toed sloth swimming down a river of frozen helium while chained		three-toed sloth swimming down a river of frozen helium while chained
	to an osmium anchor stuck inside a black hole).		to an osmium anchor stuck inside a black hole).

			[[Category:x264]]

Saintdev at 07:21, 19 February 2011

2011-02-19T07:21:34Z

← Older revision		Revision as of 07:21, 19 February 2011
Line 537:		Line 537:

	Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a one-legged paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).		Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a one-legged paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).

			== [http://mailman.videolan.org/pipermail/x264-devel/2011-February/008293.html Volume 12] ==
			''02/18/2011''

			This is the twelfth x264 development newsletter. If you missed the
			first eleven, this is a regular email containing updates on fixes and
			improvements in the most recent x264 push, along with updates on
			what's coming next. Previous versions can be found in the mailing
			list archives.

			===== Fixes: =====

			Fix some Intel compiler warnings.

			Fix a crash in the mp4 muxer in x264cli if x264_encoder_open failed.

			Fix a case in which a malloc(0) was done; on some OSs, like Solaris,
			this returned a null pointer instead of a pointer to a 0-byte memory
			block, thus causing libx264 to think that its malloc failed. Both
			these behaviors are POSIX-compatible.

			Fix a minor bug in RD caused by a stray semicolon. It probably didn't
			affect much.

			Fix a memory leak on encoder close if not all frames were flushed
			during encoding.

			===== Improvements: =====

			Save memory: don't init MV cost data that isn't needed.

			Use bs_write1 for all 1-bit header bits, not just some.

			Even more accurate handling of slice-max-size escape bytes: track the
			actual bytes rather than trying to estimate them. Slightly slower,
			but should cover even the most insane corner cases (we found a corner
			case in which x264 could literally end up outputting one escape byte
			for every single macroblock!).

			In frame-packing 3D, don't place scenecuts on the right view, ever.
			Some players dislike this. Note: x264 won't stop you from using an
			odd keyint, which will mess this up.

			The first edition of Daniel Kang's massive AVX patch is in --
			hopefully this will give a few % of performance on the new Sandy
			Bridge chips.

			===== Upcoming: =====

			--device and automatic --level restriction support is in the works, as
			part of Google Code-In. The patch is done, but needs review.

			A per-option help system is in the works, as part of Google Code-In.
			The patch is done, but needs editing of the help entries.

			Adaptive MBAFF development is actually coming along for once this
			time. Inter frames are basically done.

			x262 is under development: a best-in-class MPEG-2 encoder built using
			the x264 framework. P-frames are done and working.

			Work is planned to integrate x264 with the Sandy Bridge's encoding
			ASIC for improved encoding performance. Current status is: waiting on
			Intel (these guys move at the speed of an obese one-legged paraplegic
			three-toed sloth swimming down a river of frozen helium while chained
			to an osmium anchor stuck inside a black hole).

Saintdev at 07:06, 7 February 2011

2011-02-07T07:06:41Z

← Older revision		Revision as of 07:06, 7 February 2011
Line 492:		Line 492:

	Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).		Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).

			== [http://mailman.videolan.org/pipermail/x264-devel/2011-February/008251.html Volume 11] ==
			''02/06/2011''

			This is the eleventh x264 development newsletter. If you missed the first nine, this is a regular email containing updates on fixes and improvements in the most recent x264 push, along with updates on what's coming next. Previous versions can be found in the mailing list archives.

			===== Fixes: =====

			Fix various regressions introduced in VBV emergency.

			Fix AVX detection on OSs that don't support AVX.

			Fix a crash on Phenom that could occur with the lookahead disabled and a calling application that tweaks the SSE control flags.

			Fix a divide-by-zero crash in the MKV/FLV muxers that could occur if encoder initialization failed.

			Fix a race condition that resulted in slightly wrong frame durations calculated for VFR input.

			Fix an overflow in i16x16 NEON planar prediction, backported from ffmpeg.

			In x86inc.asm, error on duplicate functions instead of silently renaming one of them.

			===== Improvements: =====

			Enable FastShuffle on crippled Nehalem/Penryn CPUs without SSE4.

			Output pic_struct information in the libx264 API.

			Allow weightp_fake in interlaced mode: it seems to work fine as-is.

			In Windows, restore the old console title after encoding. MSDN says this is supposed to happen automatically, but MSDN is wrong.

			Make x264cli update its progress every 0.25 seconds instead of every certain number of frames. This should be more visually consistent and fix some problems with extremely fast-updating status bars (e.g. from FFMS indexing of large files) in some situations.

			===== Upcoming: =====

			--device and automatic --level restriction support is in the works, as part of Google Code-In. The patch is done, but needs review.

			A per-option help system is in the works, as part of Google Code-In. The patch is done, but needs editing of the help entries.

			Adaptive MBAFF development is actually coming along for once this time. Inter frames are mostly done.

			x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework. Basic structure is done, with intra coding finished and inter coding begun.

			Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a one-legged paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).

Saintdev at 02:24, 31 January 2011

2011-01-31T02:24:52Z

← Older revision		Revision as of 02:24, 31 January 2011
Line 444:		Line 444:

	Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks while chained to an osmium anchor).		Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks while chained to an osmium anchor).

			== [http://mailman.videolan.org/pipermail/x264-devel/2011-January/008192.html Volume 10] ==
			''01/26/2010''

			This is the tenth x264 development newsletter. If you missed the first nine, this is a regular email containing updates on fixes and improvements in the most recent x264 push, along with updates on what's coming next. Previous versions can be found in the mailing list archives.

			===== Fixes: =====

			Some asm fixes to high bit depth: fix cases where SSE2-only instructions were used in MMX functions (caused SIGILL on old CPUs).

			Fix the cacheline check in cache32 avg2 code (minor speed improvement on some old CPUs).

			Fix CPU detection on Windows systems with >= 64 CPUs. x264 still doesn't use more than one processor group (it really doesn't need to), but at least it'll work now.

			Fix reconfiguration of b_tff: make changing field order during encoding work properly. Required for ffmpeg to signal TFF/BFF, since ffmpeg's TFF/BFF is signaled per-frame instead of per-stream.

			Fix cases where x264_encoder_encode failures (due to malloc failure) could cause x264_encoder_close to crash.

			Write the 3D frame packing SEI values more correctly (thanks to Nero for the bug report).

			===== Improvements: =====

			Bump all the dates to 2011.

			Add some missing values to the non-extended SAR table.

			Improve the regression test script to not break with really complex commandlines on OSs with limited filename length, as well as correctly return to the original branch the user is on after testing.

			Add an --input-fmt option to serve the same purpose of -f in ffmpeg; useful for cases where ffmpeg can't successfully probe the format of the input file.

			Double the base framerate of frame-sequential 3D files; a "60fps" frame-sequential 3D file is really only 30fps.

			Add AVX support to x264's assembly abstraction layer as well as one example function: still needs the actual AVX code to be written, but x264 can now take advantage of 3-operand instructions.

			VBV Emergency Mode is finally completed. This makes x264 able to deal gracefully with extreme input combined with VBV restrictions (e.g. noise, Doremi Labs test boxes). This is important for some broadcast applications.

			===== Upcoming: =====

			--device and automatic --level restriction support is in the works, as part of Google Code-In. The patch is done, but needs review.

			A per-option help system is in the works, as part of Google Code-In.<br>
			The patch is done, but needs editing of the help entries.

			Adaptive MBAFF development is actually coming along for once this time.

			x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework. Basic structure is done, with intra coding finished and inter coding begun.

			Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a river of frozen helium while chained to an osmium anchor stuck inside a black hole).

Saintdev at 04:25, 30 January 2011

2011-01-30T04:25:36Z

← Older revision		Revision as of 04:25, 30 January 2011
Line 379:		Line 379:

	Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks).		Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks).

			== [http://mailman.videolan.org/pipermail/x264-devel/2011-January/008132.html Volume 9] ==
			''01/10/11''

			This is the ninth x264 development newsletter. If you missed the
			first eight, this is a regular email containing updates on fixes and
			improvements in the most recent x264 push, along with updates on
			what's coming next. Previous versions can be found in the mailing
			list archives.

			===== Fixes: =====

			The win32 alignment crash issue is actually fixed now. Apparently gcc doesn't work right unless you initialize zero arrays explicitly.

			High bit depth now compiles with --disable-asm properly again.

			SATD predictors with high bit depth work properly with --no-mbtree on.<br>
			*Bug resulted in bizarre/wrong bitrates in CRF mode with --no-mbtree.

			The lavf demuxer no longer memory leaks like crazy on inputs with multiple video streams.

			Some overflows in VFR ratecontrol with extreme timebases have been fixed. These affected some actual videos.

			SSIM now works properly in 10-bit.

			A bug with negative costs that caused assertions on some videos in high bit depth mode has been fixed.

			YV12 now works correctly in the resize filter (there was an issue with swapped chroma planes).

			The endianness test and as test in configure now work properly in cross-compile mode.

			Weightp no longer prints random extra linebreaks to the statsfile.

			A few minor improvements have been made to the parameter SEI.

			===== Improvements: =====

			Some incorrect GCC uninitialized variable warnings have been shut up.

			Metric craptons of high bit depth assembly have been added, for significant performance improvements. Thanks to Google Code-In (now over) and our students for their enormous amount of work, particularly Daniel Kang.

			Also a few improvements in 8-bit assembly functions as well.

			Check an extra offset in weightp analysis, for improved compression on fades with --weightp 1 (and slightly, but much less, improved with weightp 2).

			Improve reference ordering in 3D frame-interleaved mode.

			VFR-aware ratecontrol: MB-tree and non-MB-tree ratecontrol will now be aware of how long frames last. This results in greatly improved quality in VFR video, particularly dedup'd anime and similar content. It is now even MORE important that calling applications give x264
			correct timestamps! Note this also affects the definition of CRF; higher framerate videos will get lower quality at the same CRF, which should improve how well CRF measures quality (as compared to the human brain itself).

			===== Upcoming: =====

			--device and automatic --level restriction support is in the works, as part of Google Code-In. The patch is done, but needs review.

			A per-option help system is in the works, as part of Google Code-In.<br>
			The patch is done, but needs editing of the help entries.

			VBV Emergency Mode is finally completed, with just fine-tuning and bugfixing left. This makes x264 able to deal gracefully with extreme input combined with VBV restrictions (e.g. noise, Doremi Labs test boxes). This is important for some broadcast applications. This was
			delayed due to Google Code-In.

			Adaptive MBAFF development is coming along, with B-frames being finished up currently.

			x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework. Basic structure is done, with intra coding finished and inter coding begun.

			Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks while chained to an osmium anchor).

Saintdev at 05:49, 29 January 2011

2011-01-29T05:49:02Z

← Older revision		Revision as of 05:49, 29 January 2011
Line 336:		Line 336:

	Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a three-toed sloth swimming down a river of bricks).		Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a three-toed sloth swimming down a river of bricks).

			== [http://mailman.videolan.org/pipermail/x264-devel/2010-December/008070.html Volume 8] ==
			''12/15/2010''

			This is the eighth x264 development newsletter. If you missed the first seven, this is a regular email containing updates on fixes and improvements in the most recent x264 push, along with updates on what's coming next. Previous versions can be found in the mailing list archives.

			===== Fixes: =====

			Weightp analysis now calculates offsets correctly in high bit depth mode.

			High bit depth intra pred x86 asm functions are now fixed (and thus re-enabled).

			That nasty gnu ld alignment bug on windows (ld refuses to align .bss to 16 bytes even when asked nicely) has been squashed with -fno-zero-initialized-in-bss.

			===== Improvements: =====

			.gitignore is now even more useful than before.

			Another bit of memory saved in high bit depth weightp.

			The regression test script now tests interlaced compression.

			8x8dct is now allowed with cavlc+lossless and subme>=6, for a slight compression improvement.

			Frame-packing SEI support is now in, for official 3D support in x264.

			A metric crapload of new high bit depth asm functions are now in (thanks, Google Code-In!)

			x264 now supports Windows threads in addition to pthreads. Thanks to Pegasys Inc. for the original patch.

			===== Upcoming: =====

			--device and automatic --level restriction support is in the works, as part of Google Code-In.

			A per-option help system is in the works, as part of Google Code-In.

			VBV Emergency Mode is finally completed, with just fine-tuning and bugfixing left. This makes x264 able to deal gracefully with extreme input combined with VBV restrictions (e.g. noise, Doremi Labs test boxes). This is important for some broadcast applications.

			Adaptive MBAFF development is coming along, with B-frames being finished up currently.

			x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework. Basic structure is done, with intra coding finished and inter coding begun.

			Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance. Current status is: waiting on Intel (these guys move at the speed of a paraplegic three-toed sloth swimming down a frozen river of bricks).

Saintdev: /* Volume 7 */

2011-01-28T02:45:09Z

Volume 7

← Older revision		Revision as of 02:45, 28 January 2011
Line 292:		Line 292:
	日本語: http://tmpgenc.pegasys-inc.com/ja/press/10_1126.html		日本語: http://tmpgenc.pegasys-inc.com/ja/press/10_1126.html

	== Volume 7 ==		== [http://mailman.videolan.org/pipermail/x264-devel/2010-December/008041.html Volume 7] ==
	''12/07/2010''		''12/07/2010''

Saintdev at 02:42, 28 January 2011

2011-01-28T02:42:48Z

@@ Line 236: / Line 236: @@
 ''11/25/2010''
-This is the sixth x264 development newsletter.  If you missed the
+This is the sixth x264 development newsletter.  If you missed the first five, this is a regular email containing updates on fixes and improvements in the most recent x264 push, along with updates on what's coming next.  Previous versions can be found in the mailing list archives.
-Note that we pushed a bugfix release this time around, so this
+Note that we pushed a bugfix release this time around, so this newsletter includes fixes from those commits as well, i.e. it covers everything since the last newsletter.
 ===== Fixes: =====
-Fix some crashes in high bit depth on some compilers due to
+Fix some crashes in high bit depth on some compilers due to insufficient array alignment.
 Fix a bug in chroma weightp which could cause corruption in rare cases.
@@ Line 269: / Line 262: @@
 x264_encoder_reconfig now copies field order flags.
-There's a new API function to return the maximum number of delayed
+There's a new API function to return the maximum number of delayed frames with the current parameters (requested by Gstreamer).
 Google Code-In is in full swing, with two sets of patches committed:<br>
@@ Line 276: / Line 268: @@
 x264 now has a totally sweet Python regression test tool.<br>
---weightp 1 is now a better speed tradeoff.  It also doesn't do any
+--weightp 1 is now a better speed tradeoff.  It also doesn't do any reference duplication, so it's suitable when encoding for broken decoders that don't handle reference duplication correctly (while still getting the benefits of fade detection).
 ===== Upcoming: =====
-VBV Emergency Mode is finally completed, with just fine-tuning and
+VBV Emergency Mode is finally completed, with just fine-tuning and bugfixing left.  This makes x264 able to deal gracefully with extreme input combined with VBV restrictions (e.g. noise, Doremi Labs test boxes).  This is important for some broadcast applications.
-Adaptive MBAFF development is coming along, with B-frames being
+Adaptive MBAFF development is coming along, with B-frames being finished up currently.
-x262 is under development: a best-in-class MPEG-2 encoder built using
+x262 is under development: a best-in-class MPEG-2 encoder built using the x264 framework.  Basic structure is done, with intra coding finished and inter coding begun.
-Work is planned to integrate x264 with the Sandy Bridge's encoding
+Work is planned to integrate x264 with the Sandy Bridge's encoding ASIC for improved encoding performance.  Current status is: waiting on Intel (these guys move at the speed of a three-toed sloth swimming down a river of bricks).
 ===== Other news:  =====
@@ Line 311: / Line 291: @@
 日本語: http://tmpgenc.pegasys-inc.com/ja/press/10_1126.html