GNOME Bugzilla – Bug 665584
[h264parse] Reduce latency and cpu usage for packetized input
Last modified: 2011-12-06 12:11:21 UTC
When the input is packetized (stream-format=avc), we know the size of the NALU. We can therefore avoid: * Expensive code for looking for the next start code (we already know the size) * Extra latency (we don't need to wait for the next packet)
Created attachment 202818 [details] [review] codecparsers: Variant of _identify_nalu without checks This is useful for cases where the caller *knows* that the provided input contains a whole NALU and can therefore avoid: * the expensive checks for the next start code (which won't be present) * delaying the input parsing (since we would need the next incoming NALU in order for the parsing code to detect the next start code)
Created attachment 202819 [details] [review] h264parse: Use faster parsing variant when input is packetized Reduces latency and cpu usage
Will remote the MEMDUMP and switch _nocheck to _unchecked
commit 1c50dab50c069c4d559921648c92c3ccc7d13dcd Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Dec 5 11:50:17 2011 +0100 h264parse: Use faster parsing variant when input is packetized Reduces latency and cpu usage https://bugzilla.gnome.org/show_bug.cgi?id=665584 commit c4d987b6d391a7fc8c32f6abea819452b4dd9882 Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Dec 5 11:47:57 2011 +0100 codecparsers: Variant of _identify_nalu without checks This is useful for cases where the caller *knows* that the provided input contains a whole NALU and can therefore avoid: * the expensive checks for the next start code (which won't be present) * delaying the input parsing (since we would need the next incoming NALU in order for the parsing code to detect the next start code) https://bugzilla.gnome.org/show_bug.cgi?id=665584