Opened 3 years ago

Last modified 3 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 Changed 3 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords mpeg2video lowres added
  • Reproduced by developer set
  • Status changed from new to open
  • Summary changed from mpeg2video: green artefacts at the bottom with lowres 3 to mpeg2video 4:2:2: green artefacts at the bottom with lowres 3
  • Version changed from unspecified to git-master

comment:2 follow-up: Changed 3 years ago by michael

  • Analyzed by developer set

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 ?

comment:3 in reply to: ↑ 2 Changed 3 years ago by ami_stuff

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.