[Icecast] Icecast WebM Support Patch Second Edition

[Krad Radio]

One liner fix update for a potential segfault when a client connects and
the header is not yet received from the source.

Updated full patch attached.



On Thu, Feb 9, 2012 at 5:37 AM, Dennis Heerema <dennis at heerema.net> wrote:

>  Hi David,
>
>  Streaming live WebM would also give a boost to this open format.
>  Whitch Client do you use to stream the webm format to icecast with?
>

I'm using Krad Cam, which is in a very early alpha form. More information
is here:

https://gist.github.com/1773943

There is also a "Test Signal" client that sends a video only stream for
testing purposes.

-David



>  Regards,
>
> Dennis
>
>
>  -----Original Message-----
> From: Krad Radio <kradradio at gmail.com>
> To: icecast-dev at xiph.org, icecast at xiph.org
> Date: Wed, 8 Feb 2012 23:53:05 -0500
> Subject: [Icecast] Icecast WebM Support Patch Second Edition
>
> Howdy,
>
>
>  tl;dr:  Nothing new or interesting to non-developers
>
>  Attached is a newer Icecast WebM support patch for Icecast SVN, there is
> simply aesthetic changes. Whitespace has been altered to match Icecast
> project style,
>  some functions have been renamed and moved around.
>
>  Some discussion.
>
>  The format_ebml.c file lines 0-296 operates much the same as the
> format_ogg.c file does. It uses a parsing library api to feed in and pull
> out bytes via
>  the _get_buffer function. In the case of Ogg this is of course libogg, in
> the case of ebml, the "parsing library" consists of the functions below
> line 296.
>  This mini-included library comes from some debugging code that I wrote
> during my work on a much more robust EBML muxing library, originally I had
> thought
>  icecast would need to do some manipulation of the EBML segment header in
> all cases, but it turns out in most cases this is better done by the source
> client.
>  This mini-included library implements the same function calls that
> Icecast would need to use if it was using this EBML muxing library, but
> "parse" is a very
>  generous descriptor of whats actually happening. If you are familiar with
> the internals of Ogg streaming, you know that the stream starts out with a
> few header pages
>  that are then followed by pages containing the acutual video and audio
> packets. EBML doctype WebM and MKV (The only currently known) work in
> a similar way.
>  There is a "Segment Header" followed by "Clusters" (Its actually more
> nuanced than this, but this oversimplification will suffice for the
> moment). Clusters are comparable to
>  Ogg pages. The connecting client needs to be sent the header, and then it
> can start on any cluster as long as it starts exactly on a cluster. (This
> is actually not a format requirement per se but all media players I am
> aware of lack the ability to re-sync themselves if started on a random
> byte, something I intend not to be a limitation of my own work). So, in a
> live WebM stream, everything before the first cluster is the "Header" and
> then the rest is the clusters, of which the boundary between them is marked
> with 4 specific bytes. So at every cluster the refbuf is marked as a sync
> point. The size of clusters could vary significantly during a stream or
> from stream to stream, but on a properly constructed one would indicate a
> keyframe in the case of a stream with video. The 'mini-library' doesn't
> actually 'parse' the stream at all, all it does is look for the four byte
> sequence indicating a cluster boundary and informs the format functions
> appropriately. I am a fraudulent mathematician at best, but I calculate
> that there is a 1 in 4.2 billion chance of this happening for any given 4
> bytes, and 1 in 4294 per megabyte, and likely once per 4.2 gigabytes. This
> is not a problem once the stream has started for the client however, it
> only matters when the source connects and the header is stored, and when a
> client connects and needs a proper starting point. I suppose that makes it
> very unlikely to cause a problem, even though its technically wrong. It
> also means that each byte is being compared, whilst when properly parsing
> most would be skipped, but computers are so damn fast that its moot. At any
> rate proper parsing could be added this this mini-library or provided by
> the external library as it matures.
>
>  Enjoy,
>
>  David
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20120209/e17d4618/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icecast-webm-support-clean1-fix.patch
Type: text/x-patch
Size: 20553 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20120209/e17d4618/attachment.bin>