On Sat, Sep 11, 2010 at 8:51 AM, Roger Hågensen <span dir="ltr"><<a href="mailto:rescator@emsai.net">rescator@emsai.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5"> On 2010-09-09 09:24, Philip Jägenstedt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 09 Sep 2010 02:15:27 +0200, David Singer <<a href="mailto:singer@apple.com" target="_blank">singer@apple.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Sep 8, 2010 at 3:13 PM, And Clover <<a href="mailto:and-py@doxdesk.com" target="_blank">and-py@doxdesk.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps I *meant* to serve a non-video<br>
file with something that looks a fingerprint from a video format at the top.<br>
</blockquote>
<br>
Anything's possible, but it's vastly more likely that you just made a mistake.<br>
</blockquote>
<br>
It may be possible to make one file that is valid under two formats.  Kinda like those old competitions "write a single file that when compiled and run through as many languages as possible prints "hello, world!" :-).<br>


</blockquote>
<br>
For at least WAVE, Ogg and WebM it's not possible as they begin with different magic bytes.<br>
<br>
</blockquote>
<br></div></div>
Then why not define a new "magic" that is universal, so that if a proper content type is not stated then a sniffing for a standardized universal magic is done?<br>
<br>
Yep, I'm referring to my BINID proposal.<br>
If a content type is missing, sniff the first 265 bytes and see if it is a BINID, if it is a BINID check if it's a supported/expected one, and it is then play away, all is good.<br>
If a content type is given, then just in case sniff the first 265 bytes and see if it is a BINID, if it is a BINID check if it's a supported/expected one, and it is then play away, all is good.<br>
If a content type is missing, and the sniffing of the first 265 bytes shows it is not a BINID or not a supported one, then it can only be treated as unknown binary and would fail (though in the case of a unsupported BINID the user would be shown what the BINID is so they won't be fully stuck if they miss a particular codec or the browser doesn't support it).<br>


If a content type is given, and sniffing the first 265 bytes shows it's not a BINID or not a supported one, then treat it as per the context (video or audio) and hope the video or audio codec layer is able to find out what it is (what "should" happen currently right?).<br>


<br>
It would be very easy to add support for something like BINID as it can be output at the start of a file or stream as the server sends it, a script could even output it or it could be at the start of the actual file itself,<br>


and in the case of live streaming a server could easily add it to the start of the stream even if it's mid-stream. Even a wrongly configured webserver wouldn't be able to mess up the handling of this.<br>
The benefit is that the browser would see that, Oh, this is a BINID and it's Webm, I'll pass this on to the video codec then.<br>
Or if <audio> and the browser sees it is a BINID and it's MP3 it would pass it to the mp3 audio codec.<br>
In time something like BINID might even propagate elsewhere beyond just <video> and <audio>.<br>
<br>
I'm not saying that BINID must be used, but at least something very close to it (as unknown formats can be shown to a human user and make sense and be searchable), and maybe the first 8 bytes should be constructed slightly differently?.<br>


Oh and although I haven't tested this, I suspect that most current codecs would ignore the first 265 bytes when they sniff for the start of the data anyway so a BINID would be partially backwards compatible,<br>
and in any case certainly easy to patch in support for quite easily.<br>
And the best part is that the browser could easily strip or skip past the BINID when passing the data to the OS or codecs (if such do not support BINID at all), or if saving the audio or video locally per user request.<br>


<br>
Something like BINID (short for Binary Identification actually) is needed, and there is nothing wrong with HTML5 and <video> <audio> standard defining it,<br>
it wouldn't be the first time a web standard has been adopted elsewhere later, it would surely see adoption outside of this, I certainly would use it elsewhere.<br>
<br>
I invented BINID for a reason, because .*** file extensions just isn't good enough, and sniffing binary files is a real pain, the same pain as the <video> and <audio> discussion here is pointing out right now.<br>


<br>
So if sniffing is bad, but sniffing can't be avoided, then why not simply standardize the sniffing by defining a universal, simple and end user friendly (the BINID can be displayed to the user, even if unknown/unsupported),<br>


and the sniffing would be limited to the first 265 bytes (in the case of the BINID proposal), and this limited sniffing can't determine what something is and the context and extra info (like content type) does not clarify what it is or what to do with it then simply fail and inform the user, it doesn't have to be more complicated than that.<br>


<br>
As simple as possible, but no simpler. Isn't that the ideal mantra of all coders here?<br>
<br>
Remember, I'm not saying you must use BINID (but hey it's there and fleshed out already), if you must change the name, do so, if you must change the 8 byte sequence, do so, just make sure it has a max length, and the "ID" is humanly disaplayable if the format is unsupported. Just make it into an RFC or something, and spec it in the HTML standard that it must be supported, and spec how to behave if it's not present (like I pointed further above) and it's solved as best as is possible. (unless somebody have an even better idea here that is?)<br>


<br>
And yeah, this kinda stretched beyond the scope of HTML5 specs, but you'd be swatting two flies at once, solving the sniffing issue with <video> and <audio>, but also the sniffing issue that every OS has had for the last couple of um... decades?! (poke your OS/Filesystem colleagues and ask them what they think of something like this.)<br>


Then again, HTML5 is kinda a OS in it's own right, being a app platform (not to mention supporting local storage of databases and files even), so maybe it's not that far outside the scope anyway to define something like this?<br>

<font color="#888888">
<br>
-- <br>
Roger "Rescator" Hågensen.<br>
Freelancer - <a href="http://EmSai.net/" target="_blank">http://EmSai.net/</a><br>
<br>
</font></blockquote></div><br>Is there a link to your BINID proposal? From reading this I wonder: Would it entail having to re-write all existing files with an extra identifier at the start?<br><br>Silvia.<br><br>