[FFmpeg-soc] RTP packetizers

[Martin Storsjö]

On Mon, 9 Aug 2010, Luca Abeni wrote:

> On 09/08/10 19:02, Martin Storsjö wrote:
> > Btw, didn't know if you got this one, I just sent it to ffmpeg-soc and not
> > cc:ed to you personally - don't know if you read that list regularly...
> Thanks for forwarding this... No, I am not subscribed to ffmpeg-soc
> (ffmpeg-devel, ffmpeg-cvslog, and libav-user are already generating enough
> traffic for me... :)
> So, please cc: me on future emails.
> 
> [...]
> > > Sorry, I do not know the theora terminology too well... Is a "theora
> > > packet"
> > > a frame? Or is it some smaller entity (such as a NAL for H.264)?
> > > In the first case, this requirement seems a little bit strange... Maybe
> > > someone knows why the draft is written in this way?
> > 
> > As far as I know, a theora packet is a complete frame. I guess Luca B can
> > shed some light on this issue?
> Ok, I read the various emails on the ffmpeg-soc archives... If the draft is
> suggesting this funny default, let's use it.
> 
> [...]
> > > > It shouldn't ever be larger - personally I prefer this code style since
> > > > it's more robust to unforseen issues.
> > > I agree it's a matter of personal preferences...
> > > But if something unforseen happens, I'd like to be notified (so, I'd
> > > change it to "s->num_frames == s->max_frames_per_packet", and add an
> > > "assert(s->num_frames<= s->max_frames_per_packet)" just in case...).
> > 
> > True... Something like the attached, then?
> I read the patch on the ffmpeg-soc archives. I think it's an improvement (it
> makes the code more obvious and readable, in my opinion). If you agree, commit
> it :)

Committed

> [...]
> > > > Yes, it just splits packets at random points, I don't see anything else
> > > > mentioned in the RFC.
> > > If a "theora packet" is something smaller than a video frame (see above),
> > > I
> > > think this makes sense.
> Reading the ffmpeg-soc archives, I see this is the expected behaviour. I think
> the draft is not too wise, but we cannot do anything about it... So, the code
> is OK.
> 
> But I see that the "VP8 in RTP" draft is still under development... It would
> be nice if someone with some knowledge of the VP8 bitstream and a good RTP
> understanding tries to make it smarter than the theora draft (by suggesting to
> fragment frames in appropriate points, so that the effect of lost packets can
> be minimised).

Well, the issue there seems to be that you can't decode anything from the 
rest of the GOP if you miss the first data partition of any frame, so 
things are a bit more complicated - the actual point at where frames are 
split into packets doesn't matter that much afaik.

> [...]
> > > mpeg4 video is currently handled in a suboptimal (and non standard) way.
> > > AFAIR, the RFC requires to properly split a frame according to some
> > > headers,
> > > but we currently use rtp_send_raw(). A proper rtp_send_mpeg4v() needs to
> > > be
> > > implemented, to increase error resilience and to be fully RFC-compliant...
> > > If noone does this, I'll have a look in the next weeks.
> > 
> > Oh, I never looked that far on this issue. Yes, it would be very much
> > appreciated if you'd improve this, don't think I'll have the time to look
> > into it.
> Ok; I'll look at it in the next weeks.

Great, thanks!

// Martin