[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support
Micah F. Galizia
Sat Feb 20 22:51:47 CET 2010
On 10-01-25 10:25 AM, Ronald S. Bultje wrote:
> 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!
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...
Size: 16775 bytes
Desc: not available
More information about the ffmpeg-devel