Opened 7 years ago

Closed 7 years ago

#1122 closed defect (worksforme)

H264 interlaced multithreaded decoding artifacts

Reported by: efenstor Owned by:
Priority: important Component: avcodec
Version: git-master Keywords: h264 regression
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

The problem described in the ticket #993 (http://ffmpeg.org/trac/ffmpeg/ticket/993) is back again. Present in 0.10.2 from https://launchpad.net/~jon-severinsson/+archive/ffmpeg and git as well.

Change History (6)

comment:1 Changed 7 years ago by cehoyos

  • Component changed from FFmpeg to avcodec
  • Keywords h264 regression added
  • Reproduced by developer set
  • Status changed from new to open

I was able to reproduce this with -threads 7:

$ ffmpeg -threads 7 -i 00009.MTS -f framecrc out7
ffmpeg version N-39129-gf6b7863 Copyright (c) 2000-2012 the FFmpeg developers
  built on Mar 22 2012 19:37:33 with gcc 4.3.2
  configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl
  libavutil      51. 44.100 / 51. 44.100
  libavcodec     54. 12.100 / 54. 12.100
  libavformat    54.  2.100 / 54.  2.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 65.102 /  2. 65.102
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  7.100 /  0.  7.100
  libpostproc    52.  0.100 / 52.  0.100
[h264 @ 0x8ed87e0] Increasing reorder buffer to 1
[mpegts @ 0x8ed4b60] max_analyze_duration 5000000 reached at 5003333
Input #0, mpegts, from '00009.MTS':
  Duration: 00:00:36.54, start: 0.766967, bitrate: 6884 kb/s
  Program 1
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, s16, 256 kb/s
[buffer @ 0x8ed4ac0] w:1440 h:1080 pixfmt:yuv420p tb:1/1000000 sar:4/3 sws_param:
Output #0, framecrc, to 'out7':
  Metadata:
    encoder         : Lavf54.2.100
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1440x1080 [SAR 4:3 DAR 16:9], q=2-31, 200 kb/s, 59.94 tbn, 59.94 tbc
    Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (h264 -> rawvideo)
  Stream #0:1 -> #0:1 (ac3 -> pcm_s16le)
Press [q] to stop, [?] for help
frame= 1095 fps= 21 q=0.0 Lsize=     127kB time=00:00:36.55 bitrate=  28.4kbits/s
video:2494547kB audio:6852kB global headers:0kB muxing overhead -99.994933%

After several tries, the output was different from "-threads 1".

comment:2 Changed 7 years ago by michael

has anyone successfully git bisected this ?
what is the first known to be broken and last known to be working revission ?

comment:3 Changed 7 years ago by cehoyos

I tested the following command line:

$ ffmpeg -threads n -i 00009.MTS -f framecrc -an out

For n==1, I get an identical out file trying several times, for n==7 I get a different out file on nearly every run on a (single-core SSE2) Pentium M with both git head and 18a7f74 (indicating that this may not be a regression or that I see a different problem).

I was unable to reproduce this issue on a Core-2 Duo.

comment:4 Changed 7 years ago by michael

On the box where it can be reproduced does it also happen with asm or optimizations disabled ?
all my tries to reproduce this have failed sofar, valgrind also shows nothing unusual

comment:5 Changed 7 years ago by efenstor

I am not completely sure yet, but after several tests it seems to me like in the version 0.10.3 the problem is gone. I can only hope it's a consequence of intentional eradication of the bug and not its elusive nature.

comment:6 Changed 7 years ago by michael

  • Resolution set to worksforme
  • Status changed from open to closed

It appears noone can reproduce this anymore since 5 months so iam closing it. If someone can reproduce it please reopen and provide as much information valgrind/hellgrind as possible and test disable-asm disable-optimiztaion
thanks!

Note: See TracTickets for help on using tickets.