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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4