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

[Björn Axelsson]

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().

> > 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.

-- 
Bj?rn Axelsson                    Phone: +46-(0)90-18 98 97
Intinor AB                          Fax: +46-(0)920-757 10
www.intinor.se
Interactive Television & Digital Media Distribution