[Matroska-devel] About mkclean and attachment placement

Steve Lhomme slhomme at matroska.org
Thu May 27 13:22:08 CEST 2010

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.


On Thu, May 27, 2010 at 1:11 PM, Ben Danper <sebten at live.com> 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 <sebten at live.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20100527/59526810/attachment.html>

More information about the Matroska-devel mailing list