[FFmpeg-devel] [RFC] Add a demuxer directly handling rtp:// URLs by inspecting their content
Sat Oct 16 11:25:14 CEST 2010
On Mon, 11 Oct 2010, Martin Storsj? wrote:
> 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
I did some tests with VLC, and it was able to play back mulaw pcm with
only a rtp:// url. The weird thing was that VLC/Live555 seemed to guess it
as 4 kHz, not 8 kHz which would be the obvious guess.
> 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.
Updated patch attached, with more verbose warning messages. For
mpegts/rtp, no warning is issued, for audio/video that is guessed, we give
a warning saying that we're not sure about the content and may need an
SDP. For other payloads not recognized, we say explicitly that we need an
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5341 bytes
More information about the ffmpeg-devel