[Matroska-devel] About mkclean and attachment placement

Steve Lhomme slhomme at matroska.org
Thu May 27 14:04:56 CEST 2010


well, mkclean (and mkvalidator) are there to make sure the files use the
optimum choices for all sort of playback scenarios (as defined here
http://www.matroska.org/technical/order/index.html). It's not because the
current players decide to parse the attachments no matter what that it's
best in all cases. They made that choice knowing attachments could be at the
end.

On Thu, May 27, 2010 at 1:54 PM, Ben Danper <sebten at live.com> wrote:

>
> Well, if avoiding a seek to the end for advanced players isn't enough of an
> advantage, then yeah, the way it is right now is fine. Note that "advanced
> players" means "all players", so trying to "hide" or make them ignore
> attachments placing them at the end won't work.
>
> Usually attachments aren't as large as 1 MB (which is much more than a
> typical font plus some cover art image), and besides for files meat for
> Internet playback you wouldn't use large attachments anyway (even if you
> place them at the end, they'll end up read - they have to be parsed anyway
> to check if there are more clusters after them, so it's just moving the
> pause at the beginning to the end).
>
> Nonetheless it doesn't matter much, thanks anyway
>
> ________________________________
> > Date: Thu, 27 May 2010 13:22:08 +0200
> > Subject: Re: About mkclean and attachment placement
> > From: slhomme at matroska.org
> > To: sebten at live.com
> > CC: matroska-devel at lists.matroska.org
> >
> > The problem is "what is the goal of putting it at the front" ?
> >
> > If that's to avoid seeking once very far in the file, like I said locally
> or on aLAN, you won't notice a difference. Now on a slow connection you may
> see a difference. But then if you put 1 MB at the front that you are never
> going to use, the impact could be even worse. Imagine a 512 kbps stream on a
> 512 kbps connection. That would take 1024*1024 * 8 / 512000 = 16 s to load.
> And all that time waiting before playback can start in basic playback
> conditions (ie it doesn't seek over the data but read them in sequence until
> the next element is found). In the end I can see drawbacks for basic players
> but no advantage for basic or advanced players.
> >
> >
> > Steve
> >
> > On Thu, May 27, 2010 at 1:11 PM, Ben Danper> wrote:
> >
> >
> >
> > I checked them, all of the demuxers parse attachments as part of the
> header reading process. It doesnt matter if there are subtitles or not. They
> all will seek. The only demuxer that I know of that won't seek is libnestegg
> (to be used on Firefox for WebM playback), which just doesn't know about
> attachments at all and ignores them like any unknown element.
> >
> >
> >
> >
> > I know a seek isn't a big deal but since mkclean places great effort to
> pack all the headers at the beginning putting something at the end defeats
> that a bit.
> >
> >
> >
> > Thanks for your time
> >
> >
> >
> > Date: Thu, 27 May 2010 09:21:07 +0200
> >
> > Subject: Re: About mkclean and attachment placement
> >
> > From: slhomme at matroska.org
> >
> > To: sebten at live.com
> >
> > CC: matroska-devel at lists.matroska.org
> >
> >
> >
> > Hi Ben,
> >
> > Are you sure that all the demuxers look for attachments prior playback ?
> That doesn't sound efficient if there is no subtitles in the file anyway.
> >
> > Also seeking is only bad when streamed over a slow connection. On a local
> file or local network, you will not see a noticeable difference where the
> attachments are located. It may only have an impact when playing files from
> the web. And even though, it would be odd to read 3 MB of font before
> playback if the user is never going to chose subtitles.
> >
> >
> >
> >
> > Steve
> >
> >
> >
> > On Thu, May 27, 2010 at 1:51 AM, Ben Danper> wrote:
> >
> >
> >
> > Hi,
> >
> >
> >
> > I've been testing mkclean, it works pretty well.
> >
> >
> >
> > However I noticed it places attachments at the end, unlike some other
> muxers. Then I found http://www.matroska.org/technical/order/index.htmlwhich suggests that attachment placement. It makes sense in general terms,
> however it's based on the assumption that "Attachments are not meant to use
> by default when playing the file."
> >
> >
> >
> >
> > A large (the largest?) use case of attachments seems to be embedded fonts
> for subtitles, which need to be read before playback starts.
> >
> >
> >
> > To make matters worse, demuxers that support fonts (pretty much all
> demuxers used on desktop apps, at least Haali's, libavformat's, mplayer's
> and VLC's) have no way to know whether the attachments contain fonts or not
> beforehand. The end result is that they'll seek to the end of file if there
> are any attachments.
> >
> >
> >
> >
> > So I think at least font attachments should be placed at the front. It
> isn't very important in the grand scheme of things but it would be a nice
> touch.
> >
> >
> >
> > Thanks
> >
> >
> >
> >
> >
> > _________________________________________________________________
> >
> > Hotmail: Trusted email with powerful SPAM protection.
> >
> > https://signup.live.com/signup.aspx?id=60969
> >
>
> _________________________________________________________________
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100527/3d8dbabf/attachment.html>


More information about the Matroska-devel mailing list