[FFmpeg-devel] [RFC] native MMS as URLProtocol

[Michael Niedermayer]

Hi

On Tue, Aug 28, 2007 at 04:46:43PM +0200, Bj?rn Axelsson wrote:
> On Tue, 2007-08-28 at 16:12 +0200, Luca Barbato wrote:
> > Bj?rn Axelsson wrote:
> > > Another unsolved interface issue is pausing. Since MMS (and also RTSP)
> > > pauses at the server end, an application must not try to read data from
> > > a paused stream. Not a big deal, but there's no way for an application
> > > to know whether it is safe or not to read when paused. See the temporary
> > > hack to ffplay.c for how to _not_ solve this...
> > 
> > Well you have to send the pause command AND quit decoding at the same
> > time, once you issue a new play you just start from that point (nearest
> > I frame) as you don't have any context (so you reset the decoders),
> > what's the problem? (consider return from pause a seek).
> 
> Consider ffplay: normally it constantly reads as fast as it can to fill
> a certain amount of frame buffers. When the user pauses the display, it
> calls av_read_pause() but continues to read packets and fill its frame
> buffers.
> As a special case for RTSP it also pauses reading into the buffer when
> the display is paused, something that also needs to be done for MMS.
> 
> Now, this _can_ be handled with special cases on the application side,
> but it would be better to have a generic way to indicate whether it is
> ok or not to read data after an av_read_pause().

av_read_frame() could simply return AVERROR(EAGAIN) or some other "i have
no packet ATM try again later" return code
we need this or something else for grabing from X11 at non random framerate
as well ...


> 
> > > The final(?) interface issue is stream selection. For now, I just hacked
> > > in a way to pass an AVFormatContext to the protocol which then reads the
> > > AVDiscard values from there. This must be done efter open, but before
> > > the first read past the header (or play() call). (In MMS, we are given
> > > the header for free, but have to select streams before we can receive
> > > any non-header data.)
> > 
> > select all of them if isn't otherwised specified?
> 
> Yes, this what the current code does. 
> 
> What I am unsure about is the best way to pass the information to the
> protocol from the layer above. The current implementation where the ASF
> demuxer uses a private call to pass its own data structures to the
> protocol as soon as they are available is probably enough for most
> use-cases and a first implementation.
> 
> But if the layer above the protocol isn't the ASF demuxer, e.g. a player
> with its own demuxer or an archival program, a private function call
> isn't a good interface.

agree, a clean and simple API to pass this info to the protocol would
be nice ...
i dont know if some protocols support it but it would be nice if the
application could say "dont send me B frames" if its too far behind
instead of droping the bframes after the protocol

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070829/0f4c9ed0/attachment.pgp>