Possible bug in multithreaded decoding in 0.10.3

[luca]

Summary of the bug:
decoding of a sequence is not consistent

How to reproduce:
Simply execute ffmpeg video-only to yuv output and diff

I uploaded a script with sequence, shell script, and instructions to reproduce it.

The feeling is that there is something wrong with interlaced decoding and multithread

[luca]

The uploaded stuff is

decoding_notconsistent_multithread.{ts,txt,sh}

[Carl Eugen Hoyos]

Please test current git head and please provide the command line and the console output here in the ticket.

[luca]

GIT Head bug gone

[root@DVP-Blade2 ffmpeg]# ./ffmpeg -y -threads 1 -i 0001.ts -vcodec rawvideo -an ref.yuv
ffmpeg version N-41397-g9148ae5 Copyright (c) 2000-2012 the FFmpeg developers

built on Jun 7 2012 22:46:19 with gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
configuration:
libavutil 51. 56.100 / 51. 56.100
libavcodec 54. 25.100 / 54. 25.100
libavformat 54. 6.101 / 54. 6.101
libavdevice 54. 0.100 / 54. 0.100
libavfilter 2. 78.101 / 2. 78.101
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100

[mpegts @ 0xaa54220] max_analyze_duration 5000000 reached at 5000000
Input #0, mpegts, from '0001.ts':

Duration: 00:00:05.38, start: 8.594800, bitrate: 1642 kb/s
Program 1

Metadata:

service_name : Service01
service_provider: FFmpeg

Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 72 0x576 [SAR 16:11 DAR 20:11], 50 fps, 50 tbr, 90k tbn, 50 tbc
Stream #0:1[0x101]: Audio: aac ([15][0][0][0] / 0x000F), 44100 Hz, stereo, s 16, 171 kb/s

[buffer @ 0xaa5b040] w:720 h:576 pixfmt:yuv420p tb:1/90000 sar:16/11 sws_param:f lags=2
[ffmpeg_buffersink @ 0xaa5aac0] No opaque field provided
Output #0, rawvideo, to 'ref.yuv':

Metadata:

encoder : Lavf54.6.101
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x576 [SAR 16:1 1 DAR 20:11], q=2-31, 200 kb/s, 90k tbn, 50 tbc

Stream mapping:

Stream #0:0 -> #0:0 (h264 -> rawvideo)

Press [q] to stop, ? for help
frame= 193 fps=0.0 q=0.0 size= 117248kB time=00:00:03.86 bitrate=248832.0kbits frame= 269 fps=0.0 q=0.0 Lsize= 163418kB time=00:00:05.38 bitrate=248832.0kbit s/s dup=137 drop=0
video:163418kB audio:0kB global headers:0kB muxing overhead 0.000000%

[Carl Eugen Hoyos]

If this is not reproducible with 0.11, I suggest you find the commit fixing the problem with git bisect so we can backport.
If the problem is reproducible with 0.11, I will try to find the commit.

[Elon Musk]

Is this still reproducible?

[Carl Eugen Hoyos]

I would assume it is still reproducible with 0.10.6 (at least no fix was knowingly committed afaict), it was fixed in 0.11.

[Carl Eugen Hoyos]

The problem was originally fixed in 18a7f74, also fixed in 0.10.4.