[Ffmpeg-devel] Re: [RFC] mms support

Ronald S. Bultje rbultje
Fri Dec 8 15:07:03 CET 2006

Hi Ryan,

On Fri, 2006-12-08, Ryan Martell wrote:
> So for my third attempt [..], I have completely rewritten the mms  
> code today from the spotty specification (TCP only, for now). [..]
> It works great, as far as I can tell. (I get all the data off the  
> net, pausing works, stopping works, seeking might work...)

This is great news! There is to many small and useless external
libraries already.

> Now I'm trying to bolt it into asf.c, and that's where the fun is.   
> Most of asf.c is designed to use a ByteIOContext pointing to a file,  
> and it does all sorts of wonderful seeks and url_ftells, etc.  I  
> thought maybe i could just pass it an ASF packet (via a stack based  
> ByteIOContext, with some magic on the positioning for the ftells) and  
> it would use everything out if it (allowing me not to maintain  
> state), but it only uses a little at a time...
> So my question is, what's the best way to do this- I have big packets  
> coming over the wire, they need to go into a ByteIOContext with  
> ftells that return proper values, and they have to be persistant  
> across calls to read_packet, because the codec doesn't consume an  
> entire asf packet at a time.

I think with the state machine, you've got most of the stuff ready to
write a URLProtocol wrapper, right? I've told you this before, I still
think a URLProtocol is the most straightforward way to do that, unless
you fancy doing your own ByteIOContext hacks.

Your main problem here will be how to do the extra stuff that mms can do
in the URLProtocol wrapper. This way, stuff like seeking should work
just fine. The main problem would be to implement "pausing", and
possibly also things like datarate selection (if the server supports
that). For that, you could for example export some extra
protocol-specific functions in mms.c. ffmpeg.c (or asf.c, if that is
easier) and mms.c can talk to each other using the private data pointer
in the URLContext struct (ByteIOContext->opaque is the URLContext, and
URLContext->priv_data is what you give it in mms.c as private data
pointer. This is not necessarily the cleanest way, but it would work, at
least for now.
You could do this slightly cleaner by using the rtp functions
read_play() and read_pause() in the AVInputFormat struct, implementing
those in asf.c and only do something if the input is mms. Then, using
the above mechanism (asf.c talking to mms.c using the struct private
data pointers), you could make it "proxy" those calls to mms.c, which
would then handle it.

> Or is there some way to use an AVParser?

AVParsers are for codecs in a bytestream format, i.e. where you need to
read the contents of the stream to align it by frames (think mp3, mpeg
video, that kind of stuff), which is what the decoders in ffmpeg (at
least for mpeg video) expect, so you get raw video -> parser -> decoder
or demuxer -> parser -> decoder (the demuxer layer already does the
parsing for you in av_read_frame_internal(), which is why you never see
it being done). I don't think it helps here.

Just to finish off, I like your work, I've been wanting to do it myself
for a while but never got to it. Thanks!


More information about the ffmpeg-devel mailing list