[MPlayer-G2-dev] Re: Subtitles demuxer

[Alban Bedel]

Hi Arpi,

on Thu, 10 Jul 2003 14:41:40 +0200 you wrote:

> Hi,
> 
> > I started to do some g2 hacking with $SUBJ. I added subtitles stream
> > to the demux_find_streams function and wrote a simple mpsub demuxer.
> > 
> > To test that i added a quick hack to test-play to show the subs on the
> > terminal. Sadly i have atm no good movie / subtitle combination
> > to do proper test about the sync but it seems to be ok.
> > 
> > The demuxer don't do autodetection atm so you have to force it :
> > test-play -sub subfile -subdemuxer txtsub
> 
> the patch looks ok, i'll apply
> 
> > Now this is only a quick hack to have some thing comming out of the
> > demuxer level. I'd like to know what are the plans for the subtitles
> > decoding/filtering/output. If there are any ;)
> 
> plans: not really, i have only ideas.
> someone really should sit down and design the API for subtitle/osd
> stuff. maybe these 2 (osd and subs) shouldnt be mixed (keep them as 2
> independent layer).
I think so too.

> what do we need:
> - define subtitle stream formats (like ascii, html?, spu etc)
Yes. Most text stuff won't need much info,but stuff like spu need
resolution, colorspace, extra header and so on. While looking at
sh_video i think 90% of the fields present there might be useful
for subtitles too.

> - maybe define subtitles decoder/filter/encoder layer (like vd/vf/ve in
> video/)
>   sub filters may do things like subdelay/fps change, codepage
>   conversion, word-wrapping etc. en/decoders may do spu<->bitmap
>   conversion, text->bitmap->spu, spu->ocr->text :)
Ok glad to see that we are thinking about the same thing :)
Beeing able to use standard vf would be nice, alpha would be nice too.

> we also need to define the OSD api. it is harder.
> wanted features, ideas:
> - allow several independent osd "zones".
>   for example it could allow putting osd (including subs) bellow & above
>   the video image, but not over it, thus allowing full DR.
>   or it could allow OSD to external LCD device or second display (for
>   example playback video to TVout but display OSD on monitor/gui/lcd)
>   or it could define osd zone over the image, and another bellow the
>   image, so the over-image one will be scaled by BES (it could be used
>   to display progress bar/volume symbols etc) the bellow one (unscaled)
>   could be used for nice subtitles.
With LCD do you mean the graphic or text devices ?

> - it should support differential remove/draw, like in g1, so devices
> with
>   hardware osd but slow osd-ram access (like DVB or PVR-350) could
>   benefit.
> - it should allow full control over osd to the UI, so UI can put its own
>   messages. it would be better if the UI moves the subtitle osd to the
>   osd engine, maybe via setting a callback.
> - support for direct rendering compressed subs, ie. direct dvd->dxr3 spu
>   transfer without decoding spu, osd engine, encoding. maybe it doesnt
>   worth the extra complexity?
Plain text is also usable for aa lib :) So this would mean that the
subtiles chain must be able to output to the osd engine or the vo.
	Albeu

-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.