[FFmpeg-devel] [PATCH] Added an Adobe HTTP Dynamic Streaming (HDS) demuxer

Ed Torbett ed.torbett at simulation-systems.co.uk
Tue Nov 19 13:50:00 CET 2013


Hi Cory,

I've performed some testing of the HDS demuxer with some HDS streams I have access to (part of a public order CCTV system, so they're closed feeds). This system uses Wowza media server.

In order to get the code to compile, I had to implement several of the changes stated by Michael: Primarily the use of <> around the libxml headers and the lines containing mixed declaration and initialisation.

After fixing these, there are a couple of other issues:

Firstly, the hardcoding of "?hdcore" prevents the demuxer working on anything other than akamaihd streams. In the case of Wowza (the media server we use), the query parameter is "?DVR" for some streams and some others have no suffix. Secondly, this doesn't need to be appended to the bootstrap URL as the query string should already be included in the URL provided in the manifest.

Next, the stream continually downloads the same fragment number every time without incrementing the fragment number. I have identified this as an issue in Wowza; the <streamType> element is populated with the value "dvr" rather than "live". However, this implementation suggests that this will not work very well with non-live streams.

Having temporarily worked around this by allowing "dvr" to be interpreted as "live", I now get the following error repeatedly and no data is decoded:

frame duplication too large, skipping

I have attached a verbose log to help with debugging this issue.

Hope this helps improve the HDS demuxer.

Regards,
Edward Torbett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output.log
Type: application/octet-stream
Size: 86831 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131119/cbf3a2f9/attachment.obj>


More information about the ffmpeg-devel mailing list