[FFmpeg-devel] [PATCHv4] lavf: add libopenmpt demuxer

[Nicolas George]

[ Trimming people I know are on the list from the Cc. ]

Le primidi 21 messidor, an CCXXIV, Jörn Heusipp a écrit :
> (I am one of the libopenmpt maintainers)
> We have been following the ffmpeg libopenmpt demuxer patches and we already
> gave feedback at https://bugs.openmpt.org/view.php?id=817 (for reference).

Thanks for pitching in.

> Regarding AVProbeData:
> Looking at AVProbeData, I can see no (optional) field describing the file
> size:
> typedef struct AVProbeData {
>     const char *filename;
>     unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra
> allocated bytes filled with zero. */
>     int buf_size;       /**< Size of buf except extra allocated bytes */
>     const char *mime_type; /**< mime_type, when known. */
> } AVProbeData;
> Sadly, that makes it rather useless for probing module formats: There are
> module formats which have no magic bytes at all, or very bad ones which
> require verifying other simple parts of the header in order to determine any
> meaningful probing result, some even require seeking through the file and
> verifying other later parts, some even have a footer that may need to be
> verified.
> Because of this situation, the libopenmpt I/O layer absolutely needs to know
> the file size in order to do anything useful. In our adaption layer for
> streams (like stdin or HTTP without length information), we lazily pre-cache
> the whole file until hitting EOF as soon as the size is required or the code
> wants to seek to the end. As any kind of streaming does not apply to module
> formats, this was (and is) a sane design choice for libopenmpt.

The probing infrastructure can not provide the file size, for all we know it
could be an infinite stream coming from a live capture device.

Naively, I would suggest to assume that AVProbeData contains the whole file
and try probing that. That would be like trying to play a file that was
truncated on disk for some reason. If the probing fails, libavformat will
read some more and try again until it reaches the probe size limit.

For an obscure format (I mean it without any disrespect, only as a fact with
regard to FFMpeg's usual use), false negatives on the probing are not that
big a problem: it will fall back to using the extension, and if even that
fails the user can still specify "-f libopenmpt" or the equivalent in their
application.

> Regarding probing performance:

A thing to consider when discussing probing performance: the most important
is the speed of the obviously negative answers. A Matroska file or a MP3
file does not look at all like a tracker file, and libopenmpt should be able
to figure it out very quickly. Only when the file actually looks like a
tracker file should it make extra checks to be sure.

If that condition is met, then probing performance is probably not an issue:
users playing non-tracker file will not suffer from it.

By the way, any thought on getting openmpt into Debian? libmodplug has the
very significant advantage of only being an apt-get install away.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160708/7f47f0c1/attachment.sig>