[FFmpeg-devel] [RFC] Add a demuxer directly handling rtp:// URLs by inspecting their content

[Martin Storsjö]

On Mon, 11 Oct 2010, Luca Abeni wrote:

> On 10/10/2010 08:23 PM, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Sun, Oct 10, 2010 at 12:37 PM, Luca Abeni<lucabe72 at email.it>  wrote:
> > > I now see a bug on roundup asking for this, but... Is this really a good
> > > idea? AFAIK, "rtp://..." URLs are not standardised in any way, and the
> > > only
> > > standard way to identify an RTP session is an SDP. I think that something
> > > like this patch can work in some cases, but will fail in some other cases
> > > (I
> > > believe there are a lot of them - basically, the only case in which this
> > > can
> > > work reliably is TS over RTP...) and will end up confusing the users even
> > > more...
> > 
> > J-B, how does VLC deal with this? VLC accepts rtp:// URIs afaics.

I'm not sure if VLC has code of its own for that, or if all of that is 
handled within Live555.

> I might be wrong, but I think it only works with TS in RTP...
> Double thinking about it, this might be a reasonable solution (see my
> previous email).

Hmm, what about all the static payload types, e.g. audio? Or is the sample 
rate freely choosable for them, even if they're using a static payload 
type?

On the other hand, with something like this in place, it's quite easy to 
add an error message telling the user that the input is ambiguous and an 
explicit SDP description is needed, for all the cases that we don't want 
to handle this way.

// Martin