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

[CORY MCCARTHY]

Hi Ed

The HDS demuxer was tested with public streams from Akamai because that is all I could find.
I will take out the hard-coded "?hdcore" assumption.

The "frame duplication too large, skipping" message looks like an issue with the DTS.
What were the command line arguments used to reproduce the issue?

I don't have access to any streams from a Wowza media server.
Is it possible for you to send the F4M manifest XML file, bootstrap info file(if any) as well as the first downloaded fragment you mentioned?
The XML file would be a great start.  If possible can you upload the other files somewhere accessible?
This would help me debug the issue as well as see some output from a different media server.

Thank you,
Cory


----- Original Message -----
From: "Ed Torbett" <ed.torbett at simulation-systems.co.uk>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Tuesday, November 19, 2013 7:50:00 AM
Subject: Re: [FFmpeg-devel] [PATCH] Added an Adobe HTTP Dynamic Streaming	(HDS) demuxer

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

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel