Opened 4 years ago

Closed 4 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 4 years ago by piccarre

The uploaded stuff is

decoding_notconsistent_multithread.{ts,txt,sh}

comment:2 Changed 4 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 4 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%

Version 0, edited 4 years ago by piccarre (next)

comment:4 Changed 4 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 4 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 4 years ago by richardpl

Is this still reproducible?

comment:7 Changed 4 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 4 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.