Opened 14 years ago
Closed 14 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 by , 14 years ago
| Component: | FFmpeg → avcodec |
|---|---|
| Keywords: | h264 regression added |
| Reproduced by developer: | set |
| Status: | new → open |
comment:2 by , 14 years ago
has anyone successfully git bisected this ?
what is the first known to be broken and last known to be working revission ?
comment:3 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | open → 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!



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".