[MPlayer-dev-eng] More subtitles: mencoder with DVD subtitles,

[Arpi]

Hi,

> > - render subtitles
> > - crop/expand
> > - colorspace conversion (to yv12, requires for scaling)
> > - scaling
> > - colorspace conversion (to encoder's accepted format)
> >
> > this way subtitles will be scaled.
> 
> That's exactly what the patch does: render subtitles after the image
> has been decoded.  But the scaling takes place as the image is decoded
I know. But this is what i want to see chanegd: separate scaling from
decoding in mencoder. Maybe we should implement some filter queue for
mencoder, similar thing to libao2's filter plugins.
We could chain various filters, even multiple times if someone want.
Then we could implement simple filters, like:
- crop
- expand
- scale
- render subtitles
- postprocessing (note: it's now handled by decoders)
- colorspace conversions (to allow coding fli to avi with vivo codec etc;))
- wrapper for virtualdub filters [using the DLL stuff]
MEncoder with such features would kick ass...

I think it should go with surfaces, similar thing as planned for libvo2.
Surface in my mind: a structure, wiht pointers to planes (yuv), containing
visible image position and dimension, and real image dimension (stride).
So simple filters, like expand and crop don't have top copy the image, just
change the real image dimensions. It also should contain a flag, showing if
writting to buffer (rendering subtitles, postprocess etc) is allowed, or we
should copy the image first (if the image pointers point to codec's internal
buffers)

later we could append this filter layer to mplayer as well.
and build libvo2 over it...

> so it takes place before.  Regarding scaling, I had to implement it
> for VobSub, so it was my next planned move because it is now easy.
> I'll put it on hold until you say start...
What does your 'antialiasing' do? It mean only linear interpolation, or
something special math to improve quality of scaled subtitles?
I'm also thinking about some spu sub filters. We have some great filters in
the text-based sub font generator. They do some real antialiasing, build
shadows etc. It could improve a lot the quality of the poor 4-color
low-resolution dvd subtitles.

> >> Preliminary support for VobSub subtitles.  Use the -vobsub option.
> > few questions:
> > - why is it in mplayer only?
> 
> I had no time to include it in mencoder & test it.  And furthemore it
ok

> is not as much needed in the encoder (I believe it is better to have the
> subtitles in a separate file).
hmm. i can more like imagine users ripping dvd with audio and subtitles to
avi, instead of someone re-encoding his avi file and text sub to another avi.

hmm. maybe you're right... it depends on dvdsub are supported in mencoder :)
i always think dvdsub==vobsub

> > - why is palette NULL? the included vobsub code requires IFO file as well.
> 
> This was introduced because some patch decided to call spudec_new
> regardles of the user's choice of displaying subtitle.  So I had to
> take care of this.  The original code from mplayer.c looked like:
> 
>     if (dvdsub_id >= 0) vo_spudec=spudec_new(stream->priv);
> 
> but now as I only take the palette as input, I have to copy it, and
> check for the NULL case.
and where do you get the IFO palette for vobsub case from?

> > - why you need external mpg demuxer code (vobsub.c) ? isn't libmpdemux ok?
> >   (not a big prob, i just want to minimalize redundant code)
> 
> I wanted to use libmpdemux, but could not make it work with a stream
> that does not contain audio & video (see some of my previous questions
> to the list).  I feared that hacking demux_mpg.c would introduce bugs
> about everywhere so I went the redudant way.  But I would also prefer
> to use the same code...  I just can't see how.
Ok. I'll look at it. I want to remove audio/video dependency from all the
demuxers. In theory they don't need them, but when implementing, we always
knew there must be video, so no checks were added.
(or checks kill the demuxer and exit with no-video error)

> > - why did you add new render entry to libvo's sub.c ? i think as dvd sub and
> >   vobsub are very similar things, they should be handled by the same code.
> 
> So that you can display two subtitles at once: the ones from your DVD
> and the one from your VobSub file...  Very useful isn't it ;-) More
:)))

> seriously, Vobsub subtitles have to be scaled.  So they are handled a
> bit differntly.
maybe scaling is usefull for normal subs too. imagine -vo x11 -zoom -fs
afair it renders subtitles after scaling.

> >> Opacity is not yet correct with antialiasing.
> 
> I think I corrected that one now.
> 
> >> Seeking backward is not possible.  When seeking forward or when
> >> selecting a subtitle that is not the first in the file, subtitles
> >> take a very long time to catchup.
> >
> > maybe we should go through the vob, and read all subtitles to memory.
> > then we could freely seek. i don't think it needs too much memory. if yes,
> > we can only keep the indices of file, and read it runtime.
> 
> Mmm, possible.  It would also help when subtitle are on the same cdrom
> as the movie: with my system, reading from two files at the same time
> caused wreackage in the streaming of the movie.  Copying the subtitles
> on my hard drive solved it.  Now the VobSub file I have is around 5M.
in average, vob format adds ~10% extra 'shit' to the data, in form of
various sync bytes, headers, padding. and as spu packets are very small,
usually around 1-3 kb each, it decreases effective data ratio to ~ 50%.
i didn't checked, just ran some calculations in my mind, but i think it's real.

and we should keep the assembled spu packets in memory.
maybe even more: do the spudec_control stuff offline, and only leave RLE
decoding and rendering to runtime.

> Is that ok?
imho yes

systems with divx/dvd playback ability are big enough for keeping ~5mb extra
data in memory... (especially as divx audio codec eats ~9mb of memory itself)


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu