[Bug 669310] dvbsuboverlay: some subpictures not rendered (missing end-of-display markers)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=669310
  GStreamer | gst-plugins-bad | git

Mart Raudsepp <leio> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leio at gentoo.org

--- Comment #8 from Mart Raudsepp <leio at gentoo.org> 2012-02-07 00:45:22 UTC ---
Quotes from spec:

"display set: set of subtitle segments of a specific subtitle service to which
the same PTS value is associated"

"end of display set segment; the end of display set segment contains no
internal information, but is used to signal explicitly that no more segments
need to be received before the decoding of the current display set can
commence."

"The end_of_display_set_segment provides an explicit indication to the decoder
that transmission of a display set is complete. The end_of_display_set_segment
shall be inserted into the stream immediately after the last
object_data_segment for each display set. It shall be present for each subtitle
service in a subtitle stream, although decoders need not take advantage of this
segment and may apply other strategies to determine when they have sufficient
information from a display set to commence decoding."

I think there could be one problem with the patch: I don't think that one
GstBuffer that is passed to libdvbsub from gst_dvbsub_overlay_process_text is
guaranteed to be the only PES packet for that PTS (but of course usually it is
as it seems). Perhaps there's another packet with the same PTS, that continues
with more object or other data?
But perhaps the MPEG-TS spec says that it has to be increasing, and can't be
the same as continued data? Not sure offhand.
If we don't have a guarantee, at the very least we could send the previous off
once a different (presumably increased) PTS hits us. Then we'd have them all
also displayed, but the very last would be problematic, or perhaps others too
if the following one is in the far future. Perhaps we can do something better
after some thinking. Or perhaps it's not a problem at all, we need to check the
PES packet related spec sections.

Looking at that, I started to think about the dependencies on how the demuxer
gives us subtitle GstBuffers, and it seems that it expects a non-split PES
packet, so that is probably fine. However feed_with_pts only consumes one PES
packet, so if the demuxer could give multiple in one GstBuffer, we may lose the
data from the other ones, as the caller doesn't currently really look at the
return value that signifies the position or an error (if position isn't end,
there may be more PES packets).

Hope this quick pre-sleep rambling helps

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.