On Aug 3, 2010, at 10:04 AM, Martin Storsjö <[email protected]> wrote:
On Mon, 2 Aug 2010, Josh Allmann wrote:
On 2 August 2010 16:51, Ronald S. Bultje <[email protected]> wrote:
Hi Josh,
On Mon, Aug 2, 2010 at 7:46 PM, Josh Allmann <[email protected]
> wrote:
Also, I talked to the dev responsible for gstreamer's vp8 RTP.
Apparently gstreamer's implementation is made up, so we're going
to be
incompatible with them until a more official spec is published.
No surprise there. OK, feel free to apply whenever people stop
giving
comments then.
+ int is_keyframe; // this is rather unused
That's not good, it should set PKT_FLAG_KEY.
Done. This also fixed stream copying on the receiver side; I didn't
realize that was a bug.
Also added doxy to the depacketizer, and a comment in the packetizer
indicating where to locate the spec.
Unless I've mis-counted my marker bits yet again, we are in full
compliance with the spec, except for the parts that are undefined --
the "VP8" encoding name in particular.
One issue in the proposal that I don't think we comply to (and that I
think should be changed before it is finalized, is this:
3.3 Lost VP8 RTP packets
If a lost packet is detected in the RTP stream, the transport layer
MUST throw out the current partial VP8 frame (if there is one) and
all subsequent RTP packets until a VP8 payload descriptor with the
key-frame bit is set.
Not returning a single packet up until the next keyframe, if a single
packet is lost, feels quite horrible to me. Even though it may not
look
good if some data is lost, it's still better than not getting any
data at
all up until the next keyframe.
VP8's probability contexts and segment map aren't reset between
interframes, so if an entire frame is lost the rest of the GOP will
likely decode to total junk.
If you want to do better than the proposal, you can read the vp8 frame
header and ignore the rfc if the first data partition is intact;
that's the only guarantee that arithmetic probabilities and the
segment map remain correct.
_______________________________________________
FFmpeg-soc mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
