[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support

[Micah F. Galizia]

On 10-01-25 10:25 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jan 24, 2010 at 3:20 PM, Micah F. Galizia
> <micahgalizia at gmail.com>  wrote:
>> This implementation just wraps the mp3 demuxer.  I'm able to do this because
>> the mp3 demuxer doesn't actually use private data
>> (AVFormatContext::priv_data).  If this changes, or wrapping a different
>> demuxer that use priv_data is necessary, the shoutcast demuxer could
>> maintain a pointer to the wrapped demuxers private data, and swap it before
>> calling into the wrapped demuxer.
>
> As Michael said, you can open a new demuxer from this demuxer, that's
> e.g. what the mov demuxer does for dv, etc. I think that's cleaner.
>
>> The read_probe method of the demuxer is a little long because AVProbeData
>> does not include any way to reference the URLContext that has already been
>> opened. As a result, I have to open a new one to check if the stream
>> supports ICY.
>
> You're getting closer, but what I meant is that you should find some
> way to transfer the HTTP header metadata into the probe function of
> shout, so it can parse the metaint straight from the AVMetadata,
> rather than re-opening the connection. If this needs any changes in
> AVProbeData, we can certainly consider them.
>
> Other than that, it's starting to look good, thanks for you work!

Greetings again,

Attached is another version of the patch.  This version is not dependent 
on HTTP or MP3 and all SHOUTcast metadata is handled in the demuxer. The 
SHOUTcast demuxer does reuse the HTTP header processing code (regardless 
of if this is a stream dumped to a file or the actual stream itself), so 
the process_line method of http.c has been changed to make it more reusable.

This change does not affect how we play non-icy http streams since 
http_open_cnx will continue to do the header processing unless the 
shoutcast demuxer is configured and the stream supports it. So 
basically, we only use the shoutcast demuxer if we are really in a 
shoutcast stream (not if we are just playing a file over http).

I know that previously Michael said that ad-hoc wrapping hacks are not 
favorable, but I did look at how this sort of thing is done elsewhere, 
and for mov/DV we explicitly make calls into the DV demuxer, which 
doesn't help. I also searched for general demuxer chaining (on the list 
and through the code) and I couldn't find anything. So, in the interest 
in keeping the changes small (and contained within the demuxer) I am 
still wrapping a child demuxer. That said, we do probe for the format, 
and I've tested this successfully with mp3 and vorbis streams (one is 
listed at dir.xiph.org).

The metadata works out nicely too as the icy-* header data is used for 
the overall AVFormatContext and the in-band periodic track artist/title 
updates are used for chapters. I had a look at using an AVMetadataConv 
for the demuxer (since other demuxers have them) but from what I could 
tell, they are not actually used (unless the intent is that the 
application calls metadata_conv?), so I didn't bother including one.

As with the previous few patches, there is some throw-away code in 
ffplay.c to demonstrate the use of chapters.

I think that is about all (other than the patch), so TIA!

-- 
Micah F. Galizia
micahgalizia at gmail.com

"The mark of an immature man is that he wants to die nobly for a cause, 
while the mark of the mature man is that he wants to live humbly for 
one."   --W. Stekel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shoutcast6.patch
Type: text/x-diff
Size: 16775 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100220/378360f3/attachment.patch>