[FFmpeg-devel] problem with receiving rtp streams

[V0id]

? ??, 2009-03-23 ? 18:35 +0100, Luca Abeni ????:
> Hi,
> 
> I think this is more an ffmpeg-user question... Anyway:
> V0id wrote:
> > I'm trying to use libavcodec to receive RTP stream from network
> > (MPEG2-TS (MPEG-2 and MPEG audio)) and I'm getting kinda bad quality
> > with ffplay and with my test program, but mplayer and vlc are able to
> > play the same stream almost perfectly. If I use mplayer with -dumpstream
> > switch and then trying to play dumped stream with ffplay than quality is
> > very good.
> 
>  From the description, this could be due to UDP packets received in the 
> wrong order (vlc and mplayer can reorder the packets, libavformat does 
> not perform any reordering).
> Or it could be due to a wrong ffmpeg usage (as in the example below).

  I'll try to check it soon, but it's likely that you are right. Is
there any plans to add packet reordering support in near future? If I
have such problems on local interface, then situation could be much
worse on the large networks, where packets can be delivered through
different routes and probability of reordering is very high.

> > Also, I have tried to play with ffplay rtp streams generated by ffmpeg
> > and vlc on my local machine. ffplay and ffmpeg pair had worst quality.
> 
> If you stream with ffmpeg, you perform a completely different test and 
> the errors you see are surely due to wrong ffmpeg/ffplay usage:
> [...]
>  > ffplay rtp://225.0.0.17:1414/
> 
> This is wrong: you have to use "ffplay file.sdp", where file.sdp 
> contains the SDP description generated by the ffmpeg instance you ran to 
> stream.

  I made the test this way because there is no way for my project to get
SDP file for the stream. I'm sorry, if it a completely different test.
But when I tried to use SDP file for ffplay, then it just waits for
something and no streams are reproduced. But it seems than this issues
should be discussed in different mailing list.