videolan x264 broken in latest releases ?

[hydra3333]

Using the binaries over at Videolan:

A bug seems to have appeared commencing with r2579 binary when processing a vanilla mpeg2 .mpg interlaced TV file capture file. The mpeg2 files are from VideoReDo and are the result of "QuickStreamFix" which have then been successfully edited without error by VRD.

A very large number of these error messages appear
[mpeg2video @ 00000000032504c0] releasing zombie picture
Using the same .mpg input file and x264-x64 to produce an interlaced mpeg4 output,
- r2538 works without the error message
- issue appears in r2579
- issue persists in r2597

I wonder what is [mpeg2video @ 00000000032504c0] releasing zombie picture ?

I have reverted to r2538 ... any recommendations ?

[LoRd_MuldeR]

Well, this error/warning is not from x264 (libx264) itself, but from the built-in FFmpeg (libavcodec) MPEG-2 decoder.

So, apparently, something has changed on the FFmpeg side. Probably whoever is making the "VideoLAN" builds of x264 has updated to a newer (different) FFmpeg version. And newer FFmpeg is now spitting out those warnings.

Is there actually some corruption (decoding error) in the re-encoded file? Otherwise, just ignore those warnings. Quite possible the issue has always existed, but newer FFmpeg has become more verbose/picky.

(BTW: The term "zombie" in programming usually refers to something that it is no longer active/alive, but has not been released from memory yet. Like a "zombie process" is a process that has terminated, but it's PID still exists)

[hydra3333]

Thanks. In the absence of any info on the videolan forum (their threads on x264 have been deleted) I guess I'll stick with r2538 which doesn't yield the very many messages.

"Is there actually some corruption (decoding error) in the re-encoded file?"
Not that I noticed. Although, having said that, a year or so ago I attempted to use ffmpeg h264 encoding to a 576i .mp4 file (source was avisynth) and the results was all "shuddery" after a couple of minutes whereas x264 was perfect. If the newer x264 is like that for the reason you mentioned that'd be disappointing.

Unless you have a suggestion, I guess I'll work out what the equivalent ffmpeg commandline is for this
"%X264EXEx32%" --thread-input --threads %xthreads% --frames "%FRAMES%"
--profile high --level 4.1 --preset slow
--interlaced --tff --no-cabac --crf %CRF%
--sar 64:45 --colormatrix bt470bg
-o "%PARtemph264%" "576i-mpeg2.mpg"

the audio is transcoded into mp3 separately and the audio/video muxed using
"%MP4Boxexe%" -add "%PARtemph264%" -add "%parmp3%":lang=eng -isma -new "%PARmp3mp4%"
so that the moov atom is at the front of the file.

[LoRd_MuldeR]

Have you tried, for example, the Komisar's build?
http://komisar.gin.by/

[hydra3333]

no I haven't as yet.