The jeffc recording is mine and it starts to break around 28 seconds with several players, FFMS but not with MPC or DSS2. The other encode plays perfectly fine. What did I do wrong? Is it my encoding settings or the fact that my video is not mod16 while the other one is?
+ Reply to Thread
Results 1 to 9 of 9
It might be related to old x264/ffmpeg bugs. Old ffmpeg decoder was buggy. Try setting --no-8x8dct as a workaround to ensure better playback with all players.
I have so many videos with 8x8dct enabled and they all work, I don't think that's the culprit.
x264 forced it off until recently so many of your older encodes aren't affected. See the commit I linked. Wasn't commited until March 6th 2019. Also, not all encodes are affected. Only lossless/4:4:4+CABAC. 99.9% of people encode lossy 4:2:0 so were never affected by this.
Last edited by sneaker; 7th Jul 2019 at 04:07.
Damn, you were right, it is the 8x8dct for this one. But I'm confused, you said ffmpeg older than March 2019 would play 8x8dct=1 4:4:4 videos just fine? I thought the FFMPEG DLL that the FFMS Avisynth plugin uses is older than that. My ffms2.dll is from December 2016. Also, it turns out the majority of my 4:4:4 videos (which weren't encoded by me) have enabled 8x8dct and they play just fine. I'm lost.
The whole thing is a bit complicated:
IIRC back in the day the x264 developers interpreted the H.264 specs in a wrong way. This resulted in lossless and 4:4:4+CABAC files created by x264 to be non-spec-compliant. The developers of the ffmpeg H.264 decoder used the same wrong interpretation. So if you encoded such a file with old x264 it would play fine in old ffmpeg. Decoding was wrong in spec-compliant decoders. When the x264 devs saw their error they simply forced 8x8dct off for lossless encodes (July 2014). Luckily, such lossless encodes would then play correctly in old ffmpeg and also newer, fixed (spec-compliant) ffmpeg decoder. In March 2019 the x264 allowed 8x8dct again, now with spec-compliant output. These spec-compliant files play incorrectly in older ffmpeg.
It gets even more complicated as some software tries to detect if x264 was used and later also what x264 version (by reading x264's custom SEI, i.e. the thing MediaInfo reads to display the x264 version and encoding settings) to switch between non-conformant and conformant decoding based on this. LAV Filters do this, for example.
For x264 lossless I recommend setting --no-8x8dct to avoid any problems. Then the files will play fine in all decoders. Compression loss is minimal (<1%). There is a small speed gain.
Last edited by sneaker; 7th Jul 2019 at 08:07.
Thanks for the breakdown, I get it now. It used to make me so nervous to encode all my stuff back in the day as I expected the H264 videos to be unplayable a few years in the future but here I am with videos from 2008 that still decode perfectly. I never expected this kind of longetivity. Yet here is an instance that brings back that old fear of mine. Obviously the devs are working out a happiest possible ending for this which is not rendering decades worth of encodes unplayable just to satisfy some purist with his hundreds of different hardware he needs his tranny porn to play on.
You might say that it's a rare scenario but it is it really? All the thousands of videos on TASVideos are 4:4:4. A lot of people would be pissed off if they all suddenly fell down the gutter.
Errors happen, not much you can do. Specs like H.264 and H.265 are way too complicated for their own good to begin with. Though with lossless encoding you can at least compare against the source. The chance you can later recover 100% is very high.
They're complicated yet simple. I heard elementary H264 streams can be joined together bit-by-bit and play back without problems. That's impressive.