[Ffmpeg-devel] [RFC/Patch] native mms code...

[Ryan Martell]

On Jan 6, 2007, at 7:27 PM, Michael Niedermayer wrote:

> Hi
>
> On Fri, Jan 05, 2007 at 06:04:18PM -0600, Ryan Martell wrote:
>>
>> On Jan 5, 2007, at 5:38 PM, Michael Niedermayer wrote:
>>
>>> Hi
>>>
>>> On Fri, Jan 05, 2007 at 03:56:33PM -0600, Ryan Martell wrote:
>>> [...]
>>>>>> On Tue, Jan 02, 2007 at 04:51:07PM -0600, Ryan Martell wrote:
>>>>>>
>>>>>>> 4) MMS has parameters for the tcp connection bitrate; and if  
>>>>>>> there
>>>>>>> are multiple encodings in the file, it will choose the best
>>>>>>> ones.  I
>>>>>>> am currently only streaming the first audio and first video
>>>>>>> stream.
>>>>>>> How would i get the bandwidth input from the user?  I know we
>>>>>>> don't
>>>>>>> want to add new AVOptions that aren't globally useful.  Also, I
>>>>>>> could
>>>>>>> ask for audio only in this manor.
>>>>>>
>>>>>> see AVStream.discard
>>>>>
>>>>> Will look into it.
>>>>
>>>> I don't think this is what I was looking for.  Specifically, when I
>>>> am establishing the mms stream, I can ask for any one of a  
>>>> number of
>>>> streams (it may have an audio stream, and a low, medium, and high
>>>> quality all in the same file).  The way Windoze handles that is  
>>>> by a
>>>> bitrate setting, where it chooses the best stream that will fit
>>>> within the specified bitrate.  So essentially I'd need a bitrate
>>>> parameter.  Also, I want to be able to stream audio only, so I want
>>>> to have the option of turning off the video stream.  The rtp stuff
>>>> uses a similiar feature, with the tcp settings global.  I don't  
>>>> want
>>>> to use a global if i don't have to; what's the better way?
>>>
>>> my idea was that during header parsing all streams would be enabled
>>> so that all AVStreams would be initalized with bitrate, width/height
>>> sample_rate, ...
>>> then the user (application) would set AVDiscard for all streams it
>>> doesnt
>>> want and the mms demuxer would tell the server not to send anything
>>> the
>>> user doesnt want
>>>
>>> there are several cases where a pure 0/1 video + 0/1 audio bitrate
>>> based selection would fail
>>>
>>> * a user might want all streams for archivial/backup purposes
>>> * the streams might have different resolution and the users screen
>>>  or cpu might limit her to some resolution so her stream selection
>>>  criteria becomes more complex
>>> * the user might care more about audio (or video) quality then
>>> video (or
>>>  audio)
>>>
>>> implementing the part for this on the user app side is trivial
>>> (basically
>>> using eval.c with a user supplied scoring function for which
>>>> 0 means always get the stream and if none has a score >0 then the
>>>> stream
>>> with the highest score would be choosen) that of course could also
>>> be done
>>> in the mms demuxer but then one string for eval.c would have to be
>>> passed
>>> from the user app to the demuxer ...
>>> but maybe iam missing some detail why this isnt possible?
>>
>> Those are valid points, but I'm not sure if MMS can stream more than
>> one video stream at a time.  I don't think it was architected for the
>> features you have suggested- I think it is dumber than that, and
>> mainly designed for bitrate selection for throughput, not for screen
>> size or any of the other things you suggested.  Although I can
>> certainly check (if I had an mms stream with multiple encodings in
>> it, which unfortunately I don't).
>>
>> Currently, it somewhat works as you described; the headers for all
>> streams are setup, and the AVStreams are setup to properly handle the
>> data, but then depending on what I tell the server, only certain
>> streams receive packets.
>>
>> As for having it use eval.c or passing in a scoring function, that
>> sounds like the proper way to go, but I don't know how that gets
>> added into the AVInputFormat architecture.  I have to tell it which
>> streams to send me during av_open_stream().
>
> well i thought about this a little and IMHO the decission of which  
> streams
> to receive must be done in the user application not the AVInputFormat
> all demuxers in ffmpeg i know behave this way and ffmpeg would  
> break if this
> where changed (a user specifies input file:stream pairs which she  
> wants
> in the output not some bitrate or other selection criteria)
>
> a bitrate based or other selection criterium would certainly be a nice
> feature but it belongs to the user app (ffmpeg/ffplay.c) not the  
> demuxer
>
>
> if its inpossible to "activate" all streams then just set their  
> bitrate
> if thats everything you know and wait with the activation until
> AVStream.discard has been set by the user app, also the user app might
> wish to switch to a different stream at runtime (changed network
> conditions, or user/app missestimated the ideal bitrate)
> so just activating stream #1 and then switching would be an option
> (such a a switch should always be possible by reconnecting if mms  
> doesnt
> directly support it)

Hmmm.....

I agree that those features need to be in the application (ffmpeg/ 
ffplay), not the library or AVInputFormat.

I can turn on all the streams (that's not a problem).  Turning them  
off appears to require a resend of the ASFHeader (from the server).   
The documentation for MMS isn't open, so I'm using the specifications  
that have been reverse engineered, and what your're asking for hasn't  
really been researched (since WMP doesn't do it).

Connecting again isn't actually always possible; I connect to a  
tokenized Akamai stream, and the token is only valid for about 5  
seconds.  If I reconnect to the exact same URL after the token has  
expired, I get a permission denied.  Requerying for a new token is  
possible, but not quite as simple as just reconnecting.

The way that the rtsp does this is with:

extern int rtsp_default_protocols;
extern int rtsp_rtp_port_min;
extern int rtsp_rtp_port_max;

which can be set by the application (ffmpeg/ffplay).

So would something like an:

extern uint32_t mms_parameters;

with the bitrate in k in the lower 16 bits, and flags in the upper 16  
bits (Enable audio, enable video, enable all streams),

with the default being enable all streams, disregarding bitrate work?

Thanks!
-Ryan