Xine support regular closed captioning if present in DVDs, however it
does not support the EIA-608/708 closed captioning stream as provided
by the ATSC standard (ATSC standard a/53 Part 4 Section 188.8.131.52).
I got it to decode the information and announce to the CC decoder (at
least for EIA-608), but the information is rendering out of order
because the frames announced to the SPU are in transport order but the
CC decoder expects them in picture frame order.
On Sun, Jul 13, 2008 at 6:07 AM, James Courtier-Dutton
> Devin Heitmueller wrote:
>> I am doing some work on libspucc to get ATSC closed captioning
>> working. I have it rendering content on the screen, but the content
>> is arriving out of order (based on the pts values being sent, older
>> entries are arriving after newer entries in some cases).
>> I can appreciate the notion that the transport order does not
>> necessarily match the presentation order (which is why the pts is
>> provided). In fact, the ATSC specification mentions specifically the
>> need to reorder the frames by PTS before announcing them to the CC
>> My question is, the diagram below suggests that the video frames have
>> already been reordered in the video FIFO block:
>> Are SPU decoders supposed to receive the content in transport order?
>> If so, does Xine provide any infrastructure for buffering that I can
>> use to reorder the frames?
>> I can certainly write a simple buffer mechanism inside the SPU decoder
>> (in fact, I started to already), but I didn't want to write my own
>> buffer mechanism if there is some existing infrastructure to put the
>> frames into order by PTS. In fact, since my goal is to submit the
>> changes upstream, I would expect the patch to be rejected if I
>> "reinvented my own buffering" when there was already some existing
>> mechanism to do this.
>> Any suggestions that can be offered would be greatly appreciated.
> But xine already supports CC, what do you need to add?
Devin J. Heitmueller