Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2109 closed defect (fixed)

lavf demuxer on audio file with album art causes buffer fill errors

Reported by: zack@… Owned by: zack@…
Priority: normal Component: demuxer
Version: HEAD Severity: normal
Keywords: Cc: reimar
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

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)

file_2109.txt (3.0 KB) - added by zack@… 7 years ago.
mplayer output
file_2109.2.txt (2.3 KB) - added by zack@… 7 years ago.
mplayer r35482 output
file_2109.3.txt (3.5 KB) - added by zack@… 7 years ago.
mplayer r35487 output

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by zack@…

mplayer output

comment:1 Changed 7 years ago by reimar

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 Changed 7 years ago by zack@…

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 Changed 7 years ago by reimar

  • Resolution set to fixed
  • Status changed from new to 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.

Changed 7 years ago by zack@…

mplayer r35482 output

comment:4 Changed 7 years ago by zack@…

  • attachments.isobsolete changed from 0 to 1
  • Owner changed from reimar to zack@…
  • Resolution fixed deleted
  • Status changed from closed to 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 Changed 7 years ago by reimar

  • Cc Reimar.Doeffinger@… 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 Changed 7 years ago by reimar

  • Resolution set to fixed
  • Status changed from reopened to closed

And the seeking should be fixed in r35486. Though we'll have to see if it breaks something.

Changed 7 years ago by zack@…

mplayer r35487 output

comment:7 Changed 7 years ago by zack@…

  • attachments.isobsolete changed from 0 to 1

I can confirm at least r35487 seeks properly.

Note: See TracTickets for help on using tickets.