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

Michael Niedermayer michaelni
Sat Jan 6 00:38:40 CET 2007


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?

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- 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/20070106/dd53ae1b/attachment.pgp>



More information about the ffmpeg-devel mailing list