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-dev/attachments/20120208/ac2eddbb/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-webm-support-clean1.patch Type: text/x-patch Size: 20519 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20120208/ac2eddbb/attachment-0001.bin
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? 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/57628595/attachment.htm
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-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: icecast-webm-support-clean1-fix.patch Type: text/x-patch Size: 20552 bytes Desc: not available Url : http://lists.xiph.org/pipermail/icecast/attachments/20120209/e17d4618/attachment-0001.bin