[FFmpeg-devel] [RFC] native MMS as URLProtocol

Björn Axelsson bjorn.axelsson
Tue Aug 28 16:06:53 CEST 2007


Hello list,
here's my take on modifying Ryan Martell's native_mms.c as a protocol
rather than as a format. In this version there's also quite a few
smaller changes for better server compability and code simplicity.

It makes much more sense as a protocol, but it will also require
extensions to the URLProtocol and ByteIOContext APIs with play, pause
and time-seek functionality (the same functionality as read_play,
read_pause and read_seek in AVInputFormat). 

Extending the APIs shouldn't be a problem, except maybe for time-seek
since there's already a seek() in URLProtocol with slightly different
inputs and semantics. The two seeks can't easily be merged, but having
two slightly different seek functions isn't very good either. Any ideas
here?

Another unsolved interface issue is pausing. Since MMS (and also RTSP)
pauses at the server end, an application must not try to read data from
a paused stream. Not a big deal, but there's no way for an application
to know whether it is safe or not to read when paused. See the temporary
hack to ffplay.c for how to _not_ solve this...

The final(?) interface issue is stream selection. For now, I just hacked
in a way to pass an AVFormatContext to the protocol which then reads the
AVDiscard values from there. This must be done efter open, but before
the first read past the header (or play() call). (In MMS, we are given
the header for free, but have to select streams before we can receive
any non-header data.)

I figure native_mms.c must be trimmed down to something easily reviewed
before a first version can be accepted. By stripping out mmst (mms over
tcp) and only supporting mmsh (mms over http) and also removing some
disabled experimental code, a first version can be reduced by maybe
500-800 lines. Most servers seem to support mmsh, so initial lack of
mmst shouldn't be a problem for testing the code.

I hope you can spot any obvious showstopper problems with this, but as
far as I have tested it it seems to work fairly well. It even passes
regression testing.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg_protocol.diff
Type: text/x-patch
Size: 5888 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070828/4c6f06c0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: native_mms.c
Type: text/x-csrc
Size: 85145 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070828/4c6f06c0/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: native_mms.h
Type: text/x-chdr
Size: 1099 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070828/4c6f06c0/attachment.h>



More information about the ffmpeg-devel mailing list