3 ms·
I wrote one of the first de/packetizers for VP8 RTP back when the spec was released. My impression was that the codec isn't really designed for network transmis
by jallmann 13y ago
I wrote one of the first de/packetizers for VP8 RTP back when the spec was released. My impression was that the codec isn't really designed for network transmission. The probability table for the entire frame is sent up-front, so any loss of that makes the entire frame undecodable, and there's no slicing/IDR or NAL-like layer. It's fairly unworkable without a reliability or error-correction layer on top.
More competition in the codec space is a very good thing, but VP8 is a relatively weak entry IMO.
- ZeroGravitas 13y ago> My impression was that the codec isn't really designed for network transmission That seems unlikely since the major user of its predecessor VP7 was Skype (and before that VP6 was the "web codec" in Flash for a while). Maybe you could make a case that it has flaws that could make it better for this, but it seems silly to claim it was designed for a different use-case.
- jallmann 13y agoVP6 in Flash was always delivered losslessly over TCP, and never used for video capture in Flash. Skype is what makes VP8's shortcomings (for video chat) even more interesting, but On2's codecs show a very clear evolutionary path even from VP3. My guess is they didn't want to deviate too much from what was tried-and-true. Doesn't change my opinion, though -- I think it's more the case of "Well, this works well enough for video chat, if you also do this and that" rather than "We designed this from the ground-up for low-latency, unreliable operation."