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.