GNOME Bugzilla – Bug 620390
rtph264pay doesn't understand short startcodes
Last modified: 2010-06-08 10:11:14 UTC
Created attachment 162567 [details] [review] Understand short startcodes A nal unit can be started with either 3 0 bytes and a 0x1 or 2 0x0 bytes and a 0x1. gsth264pay currently only understands the longer variation, attached patch adds supports for the longer variation. Strictly speaking a NAL unit ends with either a sequence of 3 0x0 bytes or 0x00, 0x00, 0x01. To keep the changes to a minimum i made next_start_code look for a the short variation and on the second pass trim the subnals if they're not the last one. This does mean we don't catch the case where there is a trailing series of 0x0 at the end of the buffer, but i doubt that will ever occur and be meaningful (famous last words?).
Ideally, you should work with every possible case... ...
It works, we just might payload some trailing 0x00 which is valid afaik
I am not sure if it is needed (or ok) to strip all trailing 0x0, stripping (at most) one 0x0 should suffice to match previous behaviour. AFAIK, it is always safe to add 0x0, but whether conversely any trailing 0x0 can be discarded?
an Annex B Nal unit ends on a sequence of 0.0.0 or a 0.0.1. The remainder untill the first sequence of 0.0.1 are trailing 0x0 that aren't considered part of the unit. Given that we know that the sequence behind what we consider the end is 0.0.1 all 0 bytes before it are trailing and can be discarded.. Or at least that's my reading That said i don't mind removing that part of the patch and just discarding final 0 byte if there is one, to minimize behavioural changes.
Ah, I did run across the 0.0.0 part now (spec- and other-wise), so it should be ok then.
commit c39e82a1ce8fee32381f102bc0c6bcf9384c24a8 Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Date: Wed Jun 2 19:16:20 2010 +0100 Cope with short startcodes in the h264 bytestream
*** Bug 612338 has been marked as a duplicate of this bug. ***