[FFmpeg-devel] [RFC] Google Summer of Code 2013

[Reimar Döffinger]

On Thu, Mar 07, 2013 at 10:42:01AM +0000, Kieran Kunhya wrote:
> On Thu, Mar 7, 2013 at 9:23 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > So in other words it's completely useless because it won't actually work?
> > Splitting it at the decoder sure is a possibility of you can't be bothered to come up with a proper solution that actually is convenient and fits into the API.
> > Of course it means only programs that add special code for our will support it.
> > And WTV will end up giving you the same subtitle stream twice.
> 
> I don't see at all how you are going to get captioning in the current
> API. It is impossible without horrible hacks (calling the cc decoder
> from mpeg-2/h264?).

What? It is a bit ugly and a good bit of code but I don't see the huge
issue.
First you'd have to extract the reordering logic from the decoders (or
instantiate a reorder-only decoder or something like that).
Then you'd extend the MPEG-ES demuxer to extract the CC packets into
a separate stream and reorder them using that logic.
As a final step, other demuxers that process MPEG video streams would
run it through a MPEG-ES subdemuxer to do the extraction.
There are most likely also less ugly solutions.

> I have no idea why WTV sees the need to make an
> additional stream

Because it makes sense? Not to mention that e.g. searching the
subtitle text is much less of a pain and processing intensive,
just as an example.
Btw. MOV/MP4 does the same thing actually, at least optionally.

> - seems odd to me unless they want to avoid the same
> issues as FFmpeg. VLC adds special code for captioning because you
> have no choice because it's impossible to do in the lavf/lavc
> paradigm.

I still don't see why it should be even remotely "impossible".

> >>Teletext is a lot of work; one might be able to get just the subtitles
> >>part working I guess.
> >
> > Uh, what part of it is a lot of work?
> > The format is not that complex, less than ATSC captions.
> > Selecting a page could be done as a decoder option at first.
> > Supporting analog teletext could also be separate.
> 
> Oh you just want teletext subtitling - that'll fit in the current API
> I suppose but the pages themselves won't.

No, I want teletext decoding. Subtitle pages are specially marked
pages with special behaviour.
I just recognize that things like figuring out how to dynamically
select a page is a bit too difficult.
Though it would be possible (though ugly) to just return all pages
in one single AVSubtitle struct on every decode call and add to
those subtitle rect a new field to indicate the teletext page.
But I'd be wary to seriously suggest implementing the first best
hack I can think of, especially when it does involve a bit of API change.