[Bug 784329] h264parse: should not always add latency

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Paolo Pr <paolo_pr at yahoo.com> ---
(In reply to Olivier Crête from comment #5)
> (In reply to Paolo Pr from comment #4)
> > As said in IRC-freenode, tsdemux doesn't have au-alignment caps even if it
> > produces an au-aligned stream.
> 
> I'm not sure why you think that tsdemux can frame a whole access unit? Even
> using the data_alignment flag and data_stream_alignment type of access unit,
> all we can know is that the first byte of the PES marks the start of the a
> AU. We can't know where the NAL or AU ends without parsing the stream (which
> is what h264parse does).
> 
> Also, tsdemux currently doesn't handle any of those alignments markers.
> 
> So I think it's largely a conceptual problem with tsdemux as it requires
> parsing the ES stream to do the actual framing.
> 
> I also wonder if we should add a alignment=none to the video/x-h26[45] caps
> in tsdemux to reflect that.

I clarify what I meant. It's not tsdemux alone which frames a whole access
unit. It's a tsdemux with other elements at its left, in the pipeline. For
example, a souphttpsrc which receives one complete frame per time and pipes it
to tsdemux. So, in this case, the output of tsdemux is a complete au per time
(that is what I meant when I said "it produces an au-aligned stream"). I agree
that it's a conceptual problem, and I agree too that video/x-h264[5] of tsdemux
should not have a precise alignment cap for its output.

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