[FFmpeg-devel] [PATCH] SHOUTcast HTTP Support
Mon Jan 25 12:50:06 CET 2010
On Sun, Jan 24, 2010 at 03:20:31PM -0500, Micah F. Galizia wrote:
> On 10-01-18 03:27 PM, Michael Niedermayer wrote:
>> On Mon, Jan 18, 2010 at 03:12:31PM -0500, Ronald S. Bultje wrote:
>>> On Mon, Jan 18, 2010 at 2:36 PM, Michael Niedermayer<michaelni at gmx.at>
>>>> On Mon, Jan 18, 2010 at 02:17:12PM -0500, Ronald S. Bultje wrote:
>>>>> [...]http demuxer.
>>>>> What do others think of this?
>>>> its a protocol not a demuxer :)
>>>> besides this iam not sure how to best implement all that, btw
>>>> do other protocols exist that contain metadata at the protocol level
>>>> or is this stuff the only known case?
>>> MMS, if implemented as a protocol, contains some metadata (which is
>>> duplicated in the ASF stream).
>> if itsin the stream we dont need it from protocol level
> I have taken this feedback and added a SHOUTcast demuxer that only handles
> mp3 streams. I had a look at some vorbis streams, and ffplay alrady
> handles the metadata, so it doesn't appear to actually be using SHOUTcast
> This implementation just wraps the mp3 demuxer. I'm able to do this
> because the mp3 demuxer doesn't actually use private data
Iam not in favor of ad-hoc wraping hacks.
I think the minimal requirements for this to be accepted as a demuxer are
* the demuxer must not be dependant on http (file dumps must work and probed
* it must not be depedant on mp3 (probe should just be called to figure out
whats inside ...)
Also there where some discussions about demuxer chaining on this list that
may be relevant.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel