skiptags: properly conceal ID3/APE tags (fixes #18501)
commit2c34ea75491e40e0aeb3f9e33094f5cd2da6d05a
authorRémi Denis-Courmont <remi@remlab.net>
Sat, 8 Jul 2017 09:24:27 +0000 (8 12:24 +0300)
committerRémi Denis-Courmont <remi@remlab.net>
Sun, 9 Jul 2017 09:11:32 +0000 (9 12:11 +0300)
tree7c6096a567f317d414e2db23afe8dbca1750bbd2
parent199193c6bd73fee67ebe47c0a878990d5f0cbb4b
skiptags: properly conceal ID3/APE tags (fixes #18501)

As most demuxers cannot handle tags at the beginning of their input
streams, the demuxer code has automatically skipped them for a long
time.

Unfortunately, a number of demuxers also assume that the initial stream
byte offset is zero (while some others seem to assume zero in some paths
and not in others). This seems like a reasonable assumption. And even if
it were not, fixing all affected stream filters and demuxers to perform
only relative seeking seems impractical and unpalatable.

This stream filter shifts the stream byte offset so that the tags are
entirely invisible, and the demuxer can assume the start is at offset 0.

Of couse, the tags must still be accessible to the meta extraction
engine(s). The TagLib plugin uses "low-level" vlc_access_NewMRL() so it
is not subject to stream filters, and not affected by this change.
(This change does however remove tags from "demuxdump".)

NOTE: On the one hand, this also enables demuxing a file format with
embedded absolute file offsets, if the tags were prepended after muxing.
On the other hand, it conversely breaks demuxing such a file format if
the tags are added during muxing. As far as I know, tags are normally
appended rather than prepended to avoid this ambiguity.
modules/MODULES_LIST
modules/stream_filter/Makefile.am
modules/stream_filter/skiptags.c [new file with mode: 0644]
po/POTFILES.in