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

[Ryan Martell]

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().

Also, be aware I'm working with sketchy documentation, so I'm trying  
to keep it as simple as possible to work with the largest number of  
mms servers.  I can internally test playback of files, as well as  
playback of live streams, and they behave differently with pausing  
(which could cause problems) (it resends the header after a pause is  
restarted on the live stream).

Thanks,
-Ryan