Opened 6 years ago

Closed 5 years ago

#1427 closed defect (fixed)

Possible bug in multithreaded decoding in 0.10.3

Reported by: piccarre Owned by:
Priority: important Component: avcodec
Version: 0.10.3 Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Change History (8)

comment:1 Changed 6 years ago by piccarre

The uploaded stuff is

decoding_notconsistent_multithread.{ts,txt,sh}

comment:2 Changed 6 years ago by cehoyos

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

comment:3 Changed 6 years ago by piccarre

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%
Last edited 5 years ago by cehoyos (previous) (diff)

comment:4 Changed 6 years ago by cehoyos

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.

comment:5 Changed 5 years ago by michael

  • Summary changed from Possible bug in multithreaded decoding to Possible bug in multithreaded decoding in 0.10.3

comment:6 Changed 5 years ago by richardpl

Is this still reproducible?

comment:7 Changed 5 years ago by cehoyos

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.

comment:8 Changed 5 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords h264 added
  • Priority changed from normal to important
  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.