GNOME Bugzilla – Bug 785405
How to avoid one-frame latency in h264parse module
Last modified: 2017-07-25 14:26:33 UTC
Hello, please consider this bug: https://bugzilla.gnome.org/show_bug.cgi?id=784329 It can be easily solved, by only changing (h264parse.c) these lines: case GST_H264_PARSER_NO_NAL_END: GST_DEBUG_OBJECT (h264parse, "not a complete nal found at offset %u", nalu.offset); /* if draining, accept it as complete nal */ if (drain) { nonext = TRUE; with: case GST_H264_PARSER_NO_NAL_END: GST_DEBUG_OBJECT (h264parse, "not a complete nal found at offset %u", nalu.offset); /* if draining, accept it as complete nal */ if (drain || aux_flag) { nonext = TRUE; where "aux_flag" is the result of some property which tells the parser that the stream is au-aligned. However, if we do that, whe should add an "au-alignment" property to elements that output frames to the parser (i.e: tsdemux) as well: then, these elements would be coupled with h264 stuff, which is not good in my opinion. Therefore I suggest to add a "framed-source" property to the parser: when it is set to TRUE, the parser understands that there is a complete frame (-> one au) for each call of gst_h264_parse_handle_frame(), and it sets aux_flag to TRUE, so to avoid the 1-frame latency. Please tell me what you think, so I can add a patch for that...
Let's discuss this in the other bug, there's no need for a new one here. It's covered by the other one. Please also attach a patch there with your idea, so it's clearer what exactly you mean. *** This bug has been marked as a duplicate of bug 784329 ***