demux_lavf: compensate timestamp resets for OGG web radio streams

Some OGG web radio streams use timestamp resets when a new song starts
(you can find those Xiph's directory - other streams there don't show
this behavior). Basically, the OGG stream behaves like concatenated OGG
files, and "of course" the timestamps will start at 0 again when the
song changes. This is very inconvenient, and breaks the seekable demuxer
cache. In fact, any kind of seeking will break

This is more time wasted in Xiph's bullshit. No, having timestamp resets
by design is not reasonable, and fuck you. I much prefer the awful
ICY/mp3 streaming mess, even if that's lower quality and awful. Maybe it
wouldn't be so bad if libavformat could tell us WHERE THE FUCK THE RESET
HAPPENS. But it doesn't, and the randomly changing timestamps is the
only thing we get from its API.

At this point, demux_lavf.c is like 90% hacks. But well, if libavformat
applies this strange mixture of being clever for us vs. giving us
unfiltered garbage (while pretending it abstracts everything, and hiding
_useful_ implementation/low level details), not much we can do.

This timestamp linearizing would, in general, probably be better done
after the decoder, because then we wouldn't need to deal with timestamp
resets. But the main purpose of this change is to fix seeking within the
demuxer cache, so we have to do it on the lowest level.

This can probably be applied to other containers and video streams too.
But that is untested. Some further caveats are explained in the manpage.
This commit is contained in:
wm4
2019-06-09 23:39:03 +02:00
parent cb82a206a9
commit 27fcd4ddc6
2 changed files with 74 additions and 5 deletions

View File

@@ -3037,6 +3037,22 @@ Demuxer
libavformat might reallocate the buffer internally, or not fully use all
of it.
``--demuxer-lavf-linearize-timestamps=<yes|no|auto>``
Attempt to linearize timestamp resets in demuxed streams (default: auto).
This was tested only for single audio streams. It's unknown whether it
works correctly for video (but likely won't). Note that the implementation
is slightly incorrect either way, and will introduce a discontinuity by
about 1 codec frame size.
The ``auto`` mode enables this for OGG audio stream. This covers the common
and annoying case of OGG web radio streams. Some of these will reset
timestamps to 0 every time a new song begins. This breaks the mpv seekable
cache, which can't deal with timestamp resets. Note that FFmpeg/libavformat's
seeking API can't deal with this either; it's likely that if this option
breaks this even more, while if it's disabled, you can at least seek within
the first song in the stream. Well, you won't get anything useful either
way if the seek is outside of mpv's cache.
``--demuxer-mkv-subtitle-preroll=<yes|index|no>``, ``--mkv-subtitle-preroll``
Try harder to show embedded soft subtitles when seeking somewhere. Normally,
it can happen that the subtitle at the seek target is not shown due to how