[FFmpeg-devel] [PATCH/RFC] Ryan Martell's native mms code

[Björn Axelsson]

On Thu, 2007-08-09 at 16:06 +0200, Michael Niedermayer wrote:
> Hi
> 
> On Thu, Aug 09, 2007 at 03:56:57PM +0200, Bj?rn Axelsson wrote:
> > On Thu, 2007-08-09 at 14:35 +0200, Reimar D?ffinger wrote:
> > > Hello,
> > > On Thu, Aug 09, 2007 at 02:24:08PM +0200, Bj?rn Axelsson wrote:
> > > > I have merged Ryan's native_mms work mentioned in an earlier mail with
> > > > the SVN trunk, to produce an easily reviewed patch. I have tried not to
> > > > change anything from Ryan's code except what was needed to make it
> > > > compile.
> > > > 
> > > > native_mms.c is mostly and will still require substantial work until it
> > > > is acceptable. It should probably also be split up into three files: one
> > > > for common functions, one for tcp/udp and one for http. 
> > > 
> > > Actually I don't see why it needs to be a demuxer at all instead of only
> > > a protocol. At least in MPlayer splitting it this way works (though
> > > stream selection admittedly is ugly and possibly not suitable in this
> > > way for ffmpeg).
> > 
> > Ryan mentions this in his original mail:
> >   Using a URLProtocol instead was an option, but it doesn't support  
> >   streaming by timestamp.  So instead I mirrored rtp stuff.
> > 
> > http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-January/020937.html
> > 
> > I believe what he is referring is that URLProtocol::url_seek() only
> > seeking by byte position, while AVInputFormat::read_seek() can seek by
> > both timestamp and byte position.
> > This, and other functionality such as play/pause, can be solved by
> > exposing a rich but specialized API from native_mms for the asf demuxer
> > to use. Something like ff_mms_read_seek(), ff_mms_read_play(),
> > ff_mms_read_pause() etc. It's not a very nice solution with a
> > specialized interface, but it should work.
> 
> the URLProtocol API could also be extended if that is needed and can be
> done cleanly
> 
> for example a url_time2pos() seems like a clean solution

Seeking to a specific time is a mms protocol command, which means that
clients don't generally convert from time->pos. The index needed to do
the conversion is kept on the server.
The protocol does support byte-based seeking though, but using that for
a time-based seek would be imprecise at best.

> a url_seek_to_time() is less nice but if we do that in the end anyway
> its probably cleaner to do it with such a function than directly
> calling ff_mms_seek()

I too would prefer url_seek_to_time(), url_play(), url_pause() over
specialized ff_mms_* versions.

I see another problem with implementing mms as a protocol: it needs
access to parsed header data from the asf muxer. The easiest way is
probably to let it have its own private muxer instance that is only used
to parse the asf header before streaming starts. Any other ideas?

-- 
Bj?rn Axelsson                    Phone: +46-(0)90-18 98 97
Intinor AB                          Fax: +46-(0)920-757 10
www.intinor.se
Interactive Television & Digital Media Distribution