[Ffmpeg-devel] [RFC/Patch] native mms code...
Sat Jan 6 01:04:18 CET 2007
On Jan 5, 2007, at 5:38 PM, Michael Niedermayer wrote:
> 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
>>>>> How would i get the bandwidth input from the user? I know we
>>>>> want to add new AVOptions that aren't globally useful. Also, I
>>>>> 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
> want and the mms demuxer would tell the server not to send anything
> 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
> implementing the part for this on the user app side is trivial
> 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
> 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
> 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).
More information about the ffmpeg-devel