#2618 closed defect (fixed)
MPNG used to work better
| Reported by: | Carl Eugen Hoyos | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avcodec |
| Version: | git-master | Keywords: | png regression |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
http://samples.ffmpeg.org/PNG-seq/mpng.avi used to play with ffplay with minor artefacts, is completely broken since ee30cda
$ ffmpeg -i mpng.avi out.avi
ffmpeg version N-53721-gf70d021 Copyright (c) 2000-2013 the FFmpeg developers
built on May 31 2013 21:12:24 with gcc 4.7 (SUSE Linux)
configuration: --enable-gpl --disable-indev=jack
libavutil 52. 34.100 / 52. 34.100
libavcodec 55. 12.102 / 55. 12.102
libavformat 55. 8.102 / 55. 8.102
libavdevice 55. 2.100 / 55. 2.100
libavfilter 3. 73.100 / 3. 73.100
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 3.100 / 52. 3.100
Input #0, avi, from 'mpng.avi':
Duration: 00:00:04.00, start: 0.000000, bitrate: 8987 kb/s
Stream #0:0: Video: png (MPNG / 0x474E504D), rgba, 160x120 [SAR 2834:2834 DAR 4:3], 40 tbr, 40 tbn, 40 tbc
[mpeg4 @ 0x22f8ba0] too many threads/slices (9), reducing to 8
Output #0, avi, to 'out.avi':
Metadata:
ISFT : Lavf55.8.102
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 160x120 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 40 tbn, 40 tbc
Stream mapping:
Stream #0:0 -> #0:0 (png -> mpeg4)
Press [q] to stop, [?] for help
Input stream #0:0 frame changed from size:160x120 fmt:rgba to size:160x120 fmt:rgb24
Input stream #0:0 frame changed from size:160x120 fmt:rgb24 to size:160x120 fmt:pal8
Input stream #0:0 frame changed from size:160x120 fmt:pal8 to size:160x120 fmt:gray
frame= 160 fps=0.0 q=31.0 Lsize= 432kB time=00:00:04.00 bitrate= 885.1kbits/s
video:423kB audio:0kB subtitle:0 global headers:0kB muxing overhead 2.234574%
Attachments (2)
Change History (7)
comment:1 by , 12 years ago
| Reproduced by developer: | set |
|---|---|
| Status: | new → open |
by , 11 years ago
| Attachment: | wait_for_keyframes_to_enable_p-frames_in_png_ee30cda.patch added |
|---|
by , 11 years ago
| Attachment: | wait_for_keyframes_to_enable_p-frames_in_png_fca435f.patch added |
|---|
Patch for todays revision that does not fix it anymore.
comment:2 by , 11 years ago
Two patches uploaded:
For the historic revision "ee30cda", waiting for a keyframe flag before handling P-frames fixes this issue.
(tested with: http://samples.mplayerhq.hu/V-codecs/PNG1/corepng.avi)
(tested with: )
For todays todays revision "fca435f", this does not work anymore because the keyframe flag seems to be handled differently. I don't know how to fix the demuxer(?) or even if it is a demuxer mishandling of the keyframe flag or just a broken file with wrong/missing keyframe flags.
comment:3 by , 11 years ago
| Summary: | MPNG used to work better → MPNG shows artefacts |
|---|
Michael has pushed a different fix, since artefacts are visible (as before ee30cda) I am leaving this ticket open.
comment:4 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
The regresion has been fixed, please open a seperate ticket for the issues that existed before ee30cda
(it costs time to read through tickets to find out what new issue they are used for at the bottom)
comment:5 by , 11 years ago
| Summary: | MPNG shows artefacts → MPNG used to work better |
|---|
Thats even more true when the ticket is marked as regression while what remains is not one.
And changing all keywords and flags to match a new issue would be quite wrong too
Also changing the title back so it matches the original issue
Patch for the old revision where the bug was introduced.