Skip to content

tttocea608: refactor to fit more scenarios

Mathieu Duponchelle requested to merge meh/gst-plugins-rs:tttocea608-refactoring into master

  • Report a latency: By design, tttocea608 will output buffers in the "past" when receiving an input buffer: we want the second to last buffer in the buffer list that we output to have the same pts as the input buffer, as it contains the end_of_caption control code which determines when the current closed caption actually gets displayed in pop_on mode. The previous buffers have timestamps decreasing as a function of the framerate, for up to potentially 74 byte pairs (the breakdown is detailed in a comment).

    The element thus has to report a latency, at 30 frames per second it represents around 2.5 seconds.

  • Refactor timestamping: Stop using a frame duration, but rather base our timestamps on a scaled frame index. This is to avoid rounding errors, and allow for exactly one byte pair per buffer if the proper framerate is set on the closed caption branch, and the video branch has perfect timestamps, eg videorate. In practice, that one byte pair per frame requirement should only matter for line 21 encoding, but we have to think about this use case too.

  • Splice in erase_display_memory: When there is a gap between the end of a buffer and the start of the next one, we want to erase the display memory (this is unnecessary otherwise, as the end_of_caption control code will in effect ensure that the display is erased when the new caption is displayed). The previous implementation only supported this imperfectly, as it could cause timestamps to go backwards.

  • Output last erase_display_memory: The previous implementation was missing the final erase_display_memory on EOS

  • Output gaps

  • Write more tests

Merge request reports