Also subtitles should be able to work without the required font. If not that means the font should be put in the Codec Private of the subtitle track and not attachments. Attachments are not supposed to be needed for playback.<div>
<br></div><div>On the other end if you have 10 languages that use the same font it would be sub-optimal to have 10 copies in the Codec Private area. But then subtitles that require a specific font to work are broken anyway...<br>
<br><div class="gmail_quote">On Thu, May 27, 2010 at 2:04 PM, Steve Lhomme <span dir="ltr"><<a href="mailto:slhomme@matroska.org">slhomme@matroska.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
well, mkclean (and mkvalidator) are there to make sure the files use the optimum choices for all sort of playback scenarios (as defined here <a href="http://www.matroska.org/technical/order/index.html" target="_blank">http://www.matroska.org/technical/order/index.html</a>). 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.<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Thu, May 27, 2010 at 1:54 PM, Ben Danper <span dir="ltr"><<a href="mailto:sebten@live.com" target="_blank">sebten@live.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
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.<br>


<br>
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).<br>


<br>
Nonetheless it doesn't matter much, thanks anyway<br>
<br>
________________________________<br>
> Date: Thu, 27 May 2010 13:22:08 +0200<br>
<div>> Subject: Re: About mkclean and attachment placement<br>
> From: <a href="mailto:slhomme@matroska.org" target="_blank">slhomme@matroska.org</a><br>
> To: <a href="mailto:sebten@live.com" target="_blank">sebten@live.com</a><br>
> CC: <a href="mailto:matroska-devel@lists.matroska.org" target="_blank">matroska-devel@lists.matroska.org</a><br>
><br>
</div><div>> The problem is "what is the goal of putting it at the front" ?<br>
><br>
> 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.<br>


><br>
><br>
> Steve<br>
><br>
</div><div>> On Thu, May 27, 2010 at 1:11 PM, Ben Danper> wrote:<br>
><br>
><br>
><br>
> 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.<br>


><br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Thanks for your time<br>
><br>
><br>
><br>
> Date: Thu, 27 May 2010 09:21:07 +0200<br>
><br>
> Subject: Re: About mkclean and attachment placement<br>
><br>
> From: <a href="mailto:slhomme@matroska.org" target="_blank">slhomme@matroska.org</a><br>
><br>
> To: <a href="mailto:sebten@live.com" target="_blank">sebten@live.com</a><br>
><br>
> CC: <a href="mailto:matroska-devel@lists.matroska.org" target="_blank">matroska-devel@lists.matroska.org</a><br>
><br>
><br>
><br>
> Hi Ben,<br>
><br>
> 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.<br>
><br>
> 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.<br>


><br>
><br>
><br>
><br>
> Steve<br>
><br>
><br>
><br>
</div><div>> On Thu, May 27, 2010 at 1:51 AM, Ben Danper> wrote:<br>
><br>
><br>
><br>
> Hi,<br>
><br>
><br>
><br>
> I've been testing mkclean, it works pretty well.<br>
><br>
><br>
><br>
> However I noticed it places attachments at the end, unlike some other muxers. Then I found <a href="http://www.matroska.org/technical/order/index.html" target="_blank">http://www.matroska.org/technical/order/index.html</a> which 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."<br>


><br>
><br>
><br>
><br>
> A large (the largest?) use case of attachments seems to be embedded fonts for subtitles, which need to be read before playback starts.<br>
><br>
><br>
><br>
> 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.<br>


><br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Thanks<br>
><br>
><br>
><br>
><br>
><br>
> _________________________________________________________________<br>
><br>
> Hotmail: Trusted email with powerful SPAM protection.<br>
><br>
> <a href="https://signup.live.com/signup.aspx?id=60969" target="_blank">https://signup.live.com/signup.aspx?id=60969</a><br>
><br>
<br>
</div>_________________________________________________________________<br>
Hotmail: Free, trusted and rich email service.<br>
<div><div></div><div><a href="https://signup.live.com/signup.aspx?id=60969" target="_blank">https://signup.live.com/signup.aspx?id=60969</a></div></div></blockquote></div><br>
</div></div></blockquote></div><br></div>