Author Topic: x264 git status: Stable  (Read 35234 times)

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
x264 git status: Stable
« on: December 10, 2009, 04:30:45 PM »
This thread will contain status updates for the current x264 git based on whatever bugs I have managed to replicate.

Current status: Stable

Bug types, for reference (from most to least bad):

Invalid Bitstream Type A: x264 may produce files which are not spec-compliant and will be decoded incorrectly.  An instance of the bug will result in the bitstream decoder losing sync, resulting in the entire frame being lost.

Invalid Bitstream Type B: x264 may produce files which are not spec-compliant and will be decoded incorrectly.  An instance of the bug will result in at least one block being decoded incorrectly, but may not result in the bitstream decoder losing sync.  Counts as a case of Decoder Desync.

Decoder Desync: x264 and the decoder disagree on how the video should be decoded.  Error may accumulate from frame to frame.

Level Violation: x264 writes values to the bitstream that may be decoded correctly by many decoders, but are nonetheless incorrect.  Equivalent to an Invalid Bitstream Type B on a decoder that doesn't support the out-of-range values, most commonly hardware decoders.  Examples include, for example, out of range MVs.

Crash: x264 may crash during encoding.

Suboptimal Quality: x264 may produce suboptimal quality, but is aware of it, and thus will not desync with the decoder.

Bug keywords, for reference:

Nondeterministic: bug is unpredictable even on the same source with the same settings, almost always related to threading issues.  Most nondetermistic bugs go away when threads are turned off.

Rare: Unlikely enough that it's possible to miss the bug with a short test of a few hundred frames.  Still likely a serious problem for any real encoding.

Very rare: May happen only once in hundreds of thousands of frames, or in one particular source.  For nondeterministic bugs, some configurations/kernels may aggravate a "very rare" bug into a "rare" bug.

Extremely rare: May happen only once in millions of frames, if ever.  Often may take the form of a bug that was never actually observed--its existence was derived from the code only.

Stable: No known bugs.  Any previously known bugs are believed to have been fixed.  This doesn't mean that we are absolutely sure x264 is stable, but rather that we haven't replicated any reports to the contrary.

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: STABLE
« Reply #1 on: December 10, 2009, 05:17:31 PM »
Postmortem on r1364-70 bug

Bug: Direct = {auto or temporal} + Weightp = {1 or 2} ---> Nondeterministic, rare, invalid bitstream Type B, with potential even-rarer crashes.
Introduced in: r1364
Fixed in: r1370
Workaround: Don't use direct = auto or temporal

Problem: In sliced threading, I moved macroblock_slice_init into each thread.  However, some of the logic in macroblock_slice_init, unbeknownst to me, had to run before the next thread was initialized.  Thus, if the operating system delayed thread N and allowed thread N+1 to start up before thread N, serious problems could occur.

Solution: Split the relevant part of slice_init that has to be run per-thread off, and move macroblock_slice_init back to where it belongs.

Special thanks: Everyone who reported related problems, JM for catching the invalid bitstream part of the bug that hinted to the real problem, and gdb for sitting patiently for hours while I picked at every damn location in memory until I figured out the problem.


Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: STABLE
« Reply #2 on: February 23, 2010, 02:05:36 AM »
Postmortem on recent bugfixes

Bug: In extreme cases, at very high quantizers with complex chroma detail, chroma SSD values could integer overflow, wrap around to negative, and cause invalid skips, resulting in blocking in B-frames.
Bug type: Suboptimal quality
Introduced in: r1187
Fixed in: r1444

Bug: x264 overread the scratch buffer array for non-mod16 resolutions with some settings combinations.
Bug type: Crash (if you were very unlucky)
Introduced in: r1066
Fixed in: r1445

Bug: With ref > 8 or b-pyramid in interlaced mode, an array over-read could result in slightly wrong bipred in B-frames.
Bug type: Decoder desync
Introduced in: r1430
Fixed in: r1446

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: Stable
« Reply #3 on: March 27, 2010, 07:00:35 PM »
Postmortem on recent bugfixes

Bug: subme < 3 + p8x8/b8x8 had broken predictors in motion estimation
Bug type: Suboptimal quality (reduced compression)
Introduced in: r1548
Fixed in: r1570

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: Stable
« Reply #4 on: May 26, 2010, 09:39:43 AM »
Postmortem on recent bugfixes

Bug: PCM blocks didn't flush the bitstream correctly in CABAC.  This was rarely an issue as PCM blocks are basically never used outside of lossless or near-lossless.
Bug type: Invalid Bitstream Type A
Introduced in: r1592
Fixed in: r1603

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: Stable
« Reply #5 on: June 01, 2010, 09:39:17 PM »
Postmortem on recent bugfixes

Bug: 8x8dct + CAVLC + deblock resulted in slightly incorrect deblock strength calculations.
Bug type: Decoder Desync
Introduced in: r1612
Fixed in: r1614

Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: Stable
« Reply #6 on: July 15, 2010, 04:19:20 AM »
Postmortem on recent bugfixes

Bug: 8x8dct + CAVLC + deblock + slices + no sliced threads resulted in slightly incorrect deblock strength calculations.
Bug type: Decoder Desync
Introduced in: r1612
Fixed in: r1669


Bug: PCM blocks were encoded incorrectly.  Broke lossless and/or insanely high bitrate encoding with subme >= 6.
Bug type: Decoder Desync
Introduced in: r1666
Fixed in: r1675



Offline Dark Shikari

  • x264 developer
  • Administrator
  • Member
  • *****
  • Posts: 650
    • View Profile
Re: x264 git status: Stable
« Reply #7 on: January 29, 2011, 05:37:51 PM »
Postmortem on recent bugfixes

Bug: AVX detection didn't work properly on older OSs.
Bug type: Crash
Introduced in: r1880
Fixed in: r1882

Bug: CAVLC/CABAC generated out of range delta quants in some rare circumstances.
Bug type: Decoder Desync
Introduced in: r1881
Fixed in: r1884