[Bug 784329] h264parse: should not always add latency

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=784329

--- Comment #2 from Paolo Pr <paolo_pr at yahoo.com> ---
As said in the other post, this 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, then a complete frame is already received.
However, before sending the patch, it's important to decide if the property
must be included only into h264parse module, or in all the modules that can be
output frames to h264parse too (i.e: tsdemux). This is a conceptual problem.

Let's clarify.

tsdemux has src caps for h264 with nal-alignment only. Then, I see two choices:

1) add an au-alignment src cap for tsdemux and check this alignment in
h264parse before deciding to drain the data or to buffer it.

2) add a "framed-source" property to h264parse, and check it before deciding to
drain the data or to buffer it.

The first choice means that multiple files have to be patched, with the result
that tsdemux is coupled to h264 codec (which is bad, IMHO).

The second choice simply tells to the parser that we are parsing a complete
frame, for each cycle; and it requires to patch only h264parse.c

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.