[FFmpeg-devel] drop entire frame when RTP packets are lost

Michael Niedermayer michaelni at gmx.at
Mon Jul 2 18:28:46 CEST 2012


Hi Martin

On Mon, Jul 02, 2012 at 09:36:07AM -0400, Martin Carroll wrote:
> Hi Michael,
> 
> > I am interested in investigating what goes wrong in the decoder and
> > error concealment code that makes it look better with less data.
> 
> I conjecture that at least part of the visual improvement that results from
> dropping entire frames (when RTP packets are lost) is the fact that
> by dropping
> entire frames, ffplay has a better chance of catching up with the
> RTP stream.
> There may be other factors at work as well.
> 
> > so i would need something that i can feed into the decoder to
> reproduce this difference
> 
> I presume that you have your favorite way of generating an RTP stream.  If
> so, then I suggest that you just send it your favorite video and watch what
> happens with and without my patch.   (My favorite video is glxgears.)

just tried, no corruption here with rtp, so i would assume your
patches wont make a difference


> 
> And regarding my patch: Given that I am new to this list, I did not want to
> be presumptuous and send my patches up.  Shall I do that now?

your patches are welcome!

though for this issue here, fixing it will require us to be able to
reproduce & analyze it. Droping frames sounds quite wrong.

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120702/4a9c7333/attachment.asc>


More information about the ffmpeg-devel mailing list