#2109 closed defect (fixed)
lavf demuxer on audio file with album art causes buffer fill errors
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Component: | demuxer |
Version: | HEAD | Severity: | normal |
Keywords: | Cc: | reimar | |
Blocked By: | Blocking: | ||
Reproduced by developer: | no | Analyzed by developer: | no |
Description
The first ~100 lines of what happens when -demuxer lavf is used with a audio file that also happens to contain album art is attached. It goes on for another 103MB over the course of the next 320 seconds.
-demuxer audio works fine because unlike lavf, it doesn't pretend the album art tag is a 1-frame video stream.
I have been told lavf sets a flag when it does this however, perhaps it would be possible to create a new mplayer option that allows the video stream to be discarded when the album art flag is set on a video stream when using the lavf demuxer-- -novideo for example cleans things up, it would be nice to automatically detect broken video streams and ignore them completely.
Verbatim output (103MB): http://buhman.org/mplayer-output
Sample audio (9.8MB): http://buhman.org/sample.mp3
Attachments (3)
Change History (10)
by , 11 years ago
Attachment: | file_2109.txt added |
---|
comment:1 by , 11 years ago
Please give the exact command-line you are using. I can't reproduce the issue, that "pts MISSING" message is printed only exactly once for me.
comment:2 by , 11 years ago
I have also uploaded the sample on ftp://upload.ffmpeg.org/incoming/lavf-demuxer-on-audio-file-with-album-art-causes-buffer-fill-errors-2109.mp3
Reimar: you are quite correct. I had a few things lurking in my .mplayer/config that also contribute. Removing my configuration, I can reproduce the problem with exactly:
mplayer -demuxer lavf -framedrop yes sample.mp3
My apologies.
comment:3 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Cover art handling unfortunately still has a few more issues (e.g. seeking working really badly), but this one should be fixed in r35482.
comment:4 by , 11 years ago
attachments.isobsolete: | 0 → 1 |
---|---|
Owner: | changed from | to
Resolution: | fixed |
Status: | closed → reopened |
I've compiled r35482 as you suggested, and the only thing that fixes is the ridiculous amount of error spewage in r35421.
The actual behavior is completely unchanged; lavf still only makes a single-frame mjpeg video stream, and this breaks seeking as you said.
comment:5 by , 11 years ago
Cc: | added |
---|
You didn't mention anything about seeking your original report, I closed it because it fixes the only issue you mentioned.
The seeking issues also "only" affect seeking relative to the current position, absolute seeks should work fine. Also, these seeking issues come up in numerous other situations (slideshows, screen recordings etc.).
It is a bit more tricky to fix properly though.
comment:6 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
And the seeking should be fixed in r35486. Though we'll have to see if it breaks something.
comment:7 by , 11 years ago
attachments.isobsolete: | 0 → 1 |
---|
I can confirm at least r35487 seeks properly.
mplayer output