[Live-devel] Support for VP8 packetization

Morten S. Laursen morten at softwarehuset.dk
Wed Feb 19 04:41:19 PST 2014


Okay, that makes more sense, it was the partition boundary splitting which
I was referring to and not the blocks, please excuse my misuse of terms.

I assume the codec on the receiving end would be able to handle the missing
partitions using the error concealment method already built into the codec,
and the client therefore would not have to adapt to the new behavior other
than to enable error concealment.

However if there exists no information of the partition boundaries, it
makes sense that it is not possible to implement.
Thank you for taking the time to answer
Kind regards
Morten S. Laursen


2014-02-19 12:48 GMT+01:00 Ross Finlayson <finlayson at live555.com>:

> Yes I was referring to the packing of VP8 payloads as done in the
> referenced draft. If that is already implemented and used automatically the
> problem must lie elsewhere as I am using the VP8VideoRTPSink class as you
> are referring to.
> As I understand the payload packing it should split the frames on image
> block boundaries and therefore a failed packet should only result in that
> block failing.
>
>
> No, not in our implementation.  If a frame is fragmented over multiple RTP
> packets, then the loss of *any* of these packets will cause the whole frame
> to be discarded by the receiver.
>
> The VP8 RTP payload format specification does, however, allow for VP8
> frames to be split on 'partition' boundaries when packed into RTP packets,
> in such a way that a receiver *could*, conceivably, receive just some
> partitions of a VP8 frame if packets are lost.  We don't implement this,
> however (because we don't parse VP8 frames at all, and therefore can't know
> where 'partitions' start and end within frames).  (In any case, this would
> be useful only if your decoder were able to handle incomplete frames
> (consisting of some, but not all, 'partitions').)
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140219/c3a43db6/attachment.html>


More information about the live-devel mailing list