RE: [xine-devel] demuxing a transport stream and teletext

[Christian K. <s3...@st...>]

> Xine works by getting input data from the input plugin, demuxing it and
> then placing it on video or audio fifo queues and tagging it with a
> BUFFER_TYPE.
> So, demux_ts.c would need to place the teletext source data from the PES
> packets onto the video_fifo with a newly defined buffer type.
> I have not read the standards document you talk about, but if it is
> anything like the old PAL analogue teletext in the UK, each section of
> teletext data is one line of text on the screen, together with a
> page/subpage number, then a line number within the page. On the analogue
> system, line 21 is used to hold the teletext data, but in mpeg2 stream,
> it would have to be put in separate digital substream. So, if there are
> 100 teletext pages, the first bit of data is line 1 of page 1, and this
> carries on until line 24 of page 99. The sequence then repeats. The
> receiving unit will then take input from the user as to the page number
> needed to be displayed, and the recieving unit then just waits for the
> correct data with the correct page number in it, and then displays it.
>

The mpeg file I am using actually originates from a satelite dvb stream
and as I have been told by the creator of the file, the teletext is just
"subtitle" like data and/or program information like start and end times
of the current and following TV program.

> The problem I see is that the teletext data is a new type of decoder, it
> is not a video decoder, it is not a SPU decoder, but a new type, and
> there could be a situation where one would need Video, SPU and Teletext
> decoders all active at the same time, and then the teletext data
> overlayed onto the video frame.

See the way I want to do it is actually different, I only want to have the
text as raw data, i.e. as a character string and not displayed on a video
frame.
I don't know if that makes it any easier. SO when you get a packet of
teletext one has to store it in a character string and that has to be
somehow accessible
so that it can be called from the GUI and the string be displayed.

> So one would then need a new class of plugin, maybe an extra-data plugin
> class.
> So we would then have audio, video, SPU, extra-data plugin classes.
>
> As a test, you could probably implement the teletext part as a video
> decoder, and then later implement teletext/video overlay.
> In the teletext video decoder plugin, it would take the teletext source
> data and then render it using the teletext control character set into a
> video image. Implementing the rendering might take some time unless
> someone has already implemented the teletext character set under linux
> already.
>

So you think I should handle the teletext as and image and not characters.
I thought it might be easier handling it as text.
I guess if I want to handle it as text I somehow have to create a new method
hierarchy so that I can access the text from the video output.
So how does the picture actually get to the "GUI"?
Do I have to create/use a video output and make a call on a method from the
video decoder plugin?
I assume so.

Thanks for the help.

Cheers,

Christian