Opened 11 years ago
Last modified 11 years ago
#2701 open defect
mpeg2video 4:2:2: green artefacts at the bottom with lowres 3
Reported by: | ami_stuff | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | mpeg2video lowres |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | yes |
Description
http://www.datafilehost.com/download-c8be0b6f.html
C:\>ffmpeg -vlowres 3 -i green_lowres.ts -an out.avi ffmpeg version N-54141-g1a405c6 Copyright (c) 2000-2013 the FFmpeg developers built on Jun 22 2013 02:23:45 with gcc 4.5.0 (GCC) 20100414 (Fedora MinGW 4.5. 0-1.fc14) configuration: --prefix=/var/www/users/research/ffmpeg/snapshots/build --arch= x86 --target-os=mingw32 --cross-prefix=i686-pc-mingw32- --cc='ccache i686-pc-min gw32-gcc' --enable-w32threads --enable-memalign-hack --enable-runtime-cpudetect --enable-cross-compile --enable-static --disable-shared --extra-libs='-lws2_32 - lwinmm -lpthread' --extra-cflags='--static -I/var/www/users/research/ffmpeg/snap shots/build/include' --extra-ldflags='-static -L/var/www/users/research/ffmpeg/s napshots/build/lib' --enable-bzlib --enable-zlib --enable-gpl --enable-version3 --enable-nonfree --enable-libx264 --enable-libspeex --enable-libtheora --enable- libvorbis --enable-libfaac --enable-libxvid --enable-libopencore-amrnb --enable- libopencore-amrwb --enable-libmp3lame --enable-libvpx --disable-decoder=libvpx libavutil 52. 37.101 / 52. 37.101 libavcodec 55. 16.100 / 55. 16.100 libavformat 55. 9.100 / 55. 9.100 libavdevice 55. 2.100 / 55. 2.100 libavfilter 3. 77.101 / 3. 77.101 libswscale 2. 3.100 / 2. 3.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 3.100 / 52. 3.100 [mpeg2video @ 0x20f3820] allocate dummy last picture for field based first keyfr ame [mpegts @ 0x1fff960] max_analyze_duration 5000000 reached at 5002500 microsecond s Input #0, mpegts, from 'green_lowres.ts': Duration: 00:00:12.60, start: 0.097333, bitrate: 2357 kb/s Program 1 Stream #0:0[0x12d]: Video: mpeg2video (4:2:2) ([2][0][0][0] / 0x0002), yuv42 0p, 40x30 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc Stream #0:1[0x12e]: Audio: mp1 ([3][0][0][0] / 0x0003), 44100 Hz, stereo, s1 6p, 448 kb/s [mpeg4 @ 0x2124c20] too many threads/slices (3), reducing to 2 Output #0, avi, to 'out.avi': Metadata: ISFT : Lavf55.9.100 Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 40x30 [SAR 1:1 DAR 4 :3], q=2-31, 200 kb/s, 23.98 tbn, 23.98 tbc Stream mapping: Stream #0:0 -> #0:0 (mpeg2video -> mpeg4) Press [q] to stop, [?] for help [mpeg2video @ 0x20f3820] allocate dummy last picture for field based first keyfr ame frame= 302 fps=0.0 q=2.0 Lsize= 85kB time=00:00:12.63 bitrate= 55.4kbits/ s dup=0 drop=2 video:73kB audio:0kB subtitle:0 global headers:0kB muxing overhead 17.704803%
Change History (3)
comment:1 by , 11 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | mpeg2video lowres added |
Reproduced by developer: | set |
Status: | new → open |
Summary: | mpeg2video: green artefacts at the bottom with lowres 3 → mpeg2video 4:2:2: green artefacts at the bottom with lowres 3 |
Version: | unspecified → git-master |
follow-up: 3 comment:2 by , 11 years ago
Analyzed by developer: | set |
---|
comment:3 by , 11 years ago
Replying to michael:
Could this be worked around, yes but its not pretty requireing to detect this specific case and calculate the IDCT differently.
Does this affect any real world use cases ?
I don't know, but feel free to close this ticket if you think that fixing it would require too much magic. ;)
Note:
See TracTickets
for help on using tickets.
This is 4:2:0 not 4:2:2 and 4:2:0 interlaced with 240 lines has 16 invissible lines, they are all green i assume. with lowres these 16 (4 per chroma field) get mixed with the vissible ones as the 8 line block that contains 4 green lines is just one pixel at lowres 3.
Thus in some sense its expected to have a green last line.
Could this be worked around, yes but its not pretty requireing to detect this specific case and calculate the IDCT differently.
Does this affect any real world use cases ?