#2137 closed defect (invalid)
Artefacts in MPEG-4 ASP elementary stream
Reported by: | Carl Eugen Hoyos | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | asp |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
I will upload an ASP elementary streams that shows accumulating artefacts with ffmpeg, plays fine with mplayer -vc xvid -demuxer lavf (-demuxer mpeg4es produces different artefacts).
$ ffmpeg -i tears.m4v -ss 9.65 out.png ffmpeg version N-48881-g7980cca Copyright (c) 2000-2013 the FFmpeg developers built on Jan 14 2013 17:11:14 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl --disable-indev=jack libavutil 52. 14.100 / 52. 14.100 libavcodec 54. 89.100 / 54. 89.100 libavformat 54. 59.107 / 54. 59.107 libavdevice 54. 3.102 / 54. 3.102 libavfilter 3. 32.100 / 3. 32.100 libswscale 2. 1.103 / 2. 1.103 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 [m4v @ 0x2bcbde0] Estimating duration from bitrate, this may be inaccurate Input #0, m4v, from 'tears.m4v': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: mpeg4, yuv420p, 640x480 [SAR 1:1 DAR 4:3], 29.97 tbr, 1200k tbn, 30k tbc Output #0, image2, to 'out.png': Metadata: encoder : Lavf54.59.107 Stream #0:0: Video: png, rgb24, 640x480 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 90k tbn, 29.97 tbc Stream mapping: Stream #0:0 -> #0:0 (mpeg4 -> png) Press [q] to stop, [?] for help [mpeg4 @ 0x2bbacc0] looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag frame= 1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A video:474kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.004531%
out.png shows artefacts that can not be seen with 00000290.png:
$ mplayer tears.m4v -demuxer lavf -vc xvid -vo png
Attachments (1)
Change History (4)
by , 12 years ago
comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
The original file was http://samples.mplayerhq.hu/V-codecs/RMP4/greenlines.rmp4.p.avi produced with Sigma Designs' "REALmagic" encoder and the original question should have been if the FourCC is needed to identify the idct (since xvid apparently doesn't need it).
Which (kind of) sample will fail to decode correctly with the xvid decoder?
comment:3 by , 11 years ago
Replying to cehoyos:
Which (kind of) sample will fail to decode correctly with the xvid decoder?
If xvid uses this idct by default (instead of somehow detecting itself as encoder) then more or less any sample with large gop encoded by a different encoder with different idct could potentially fail. most samples would of course not fail
you can use -idct 14
is there any player that can autodetect this ?
if not this ticket probably should be closed,