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

[Michael Niedermayer]

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)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070107/5decce45/attachment.pgp>