[vlc-devel] [PATCH] kate decoder: track and use basic formatting

[ogg.k.ogg.k at googlemail.com]

> We have a trick for this I believe...
> In the demux (ogg in this case), you set
> fmt.subs.spu.i_original_frame_width to the width of the video stream.
> Then in your codec you read this information back and you use it:
>
> p_spu->i_original_picture_width =
>          p_dec->fmt_in.subs.spu.i_original_frame_width;
>
> This was originally intended for vobsub/DVD subtitles, but it might
> work here as well.

It probably would, as this is the typical use (images from DVD subtitles),
and the very one for the streams I was testing with.

> VLC has no active coupling between these after they leave the demuxer.
> A decoder does not have/nor should have any active dependence on
> another codec or the displaying core while it is running. It should be
> able to function on its own.

A use case (actually something I use in some of the test streams) is
a scrolling text that would work on any sized video: the text goes from
just beyond the right edge to just beyond the left edge. This cannot
be done without knowing the size of the video the stream is being
overlayed on.

Actually, thinking about it, for a display that can have coordinates in
relative units (as I think VLC can do), I could fake a, eg, 1000x1000
display, let the kate_tracker work out the timed motions, then feed them
to VLC as relative. This wouldn't work for scaling the images though,
as I think the relative/absolute flag is global for the SPU, not for each
part.

> I think the above method is preferred. it does not introduce ugly
> locking requirements etc.

OK, I'll look into changing the code to use this.

> Doesn't matter, VLC defines it's own asprintf if a platform does not
> support it.

Oh, didn't know, I'll change it to use asprintf.

> I think the point is that care is required (and comments don't hurt
> here either)

Sure, will make it clear.

Thanks