[MPlayer-cvslog] r23530 - in trunk: Changelog DOCS/man/en/mplayer.1 DOCS/tech/MAINTAINERS DOCS/tech/slave.txt cfg-common.h command.c configure input/input.c input/input.h libvo/sub.c libvo/sub.h mpcommon.c mplayer.c spudec.c spudec.h stream/Makef

[Vladimir Voroshilov]

Hi, Michael
2007/6/11, Michael Niedermayer <michaelni at gmx.at>:
> Hi
>
> On Mon, Jun 11, 2007 at 04:19:49PM +0700, Vladimir Voroshilov wrote:
> > 2007/6/11, Michael Niedermayer <michaelni at gmx.at>:
> > > Hi
> > >
> > > On Mon, Jun 11, 2007 at 10:31:19AM +0700, Vladimir Voroshilov wrote:
> > > > 2007/6/11, Michael Niedermayer <michaelni at gmx.at>:
> > > > > Hi
> > > > >
> > > > > ive not really looked at the patch/commit but 77k for teletext decoding
> > > > > with some external lib .... hmm
> > > > > ive written a teletext decoder in 1999 and that was <22k including
> > > > > demodulation, error correcting, color, caching of pages and subpages
> > > > Main code is about 30k (without comments). 10k - rendering, other 30k
> > > > is properties/slave commands implementation/configure/interface with
> > > > mplayer internals.
> > > >
> > > > Is it to possible integrate your implementation
> > >
> > > my code is not related to mplayer and is a huge mess. ive just written
> > > it for fun in 98 or 99 or so. writing clean or portable code was not my
> > > goal when i wrote it, just getting it well working was enough ...
> > >
> > > either way ive attached the relevant files, feel free to use anything from
> > > it under LGPL or GPL if you like but i doubt theres much directly useable
> > Seems like my knowledge is not enough to unsestand this code after quick look.
> >
> > > > (i'll prefer solution
> > > > without external lib)?
> > >
> > > me too but i dont know if its possible with v4l*, can it portably capture
> > > the lines which contain teletext?
> > >
> > v4l2 contains "Raw VBI Data interface" and "Sliced VBI Data interface"
> > Is that what you are asking about ?
> > Used in teletext patch zvbi library works with v4l,v4l2 or bktr
>
> so v4l* has everything that we need, no external libs needed
>
> the modulation
> used by teletext is as simple as one could modulate the data, sample > 50%
> brightness its a 1 bit otherwise its a 0 bit, the error correction is a
> 8,4 hamming code for control and 1 parity bit to 7 bit for text you dont need
> an external lib for doing these, also the apparent lack of subpage support
> is scaring me, theres nothing special or tricky about subpages

I've tried your code. Unfortunately i could'nt get it working
(something wrong at sync stage or i didn't undestand correclty how
your code is working), thus i have got that part of code from MythTV
project (it does not use sin() and cos(), and works only with help of
fixed point operations). XawTV has even non-standard latin1->koi8-r
renderer.

Now i have working version of teletext grabber (for packets 0,1-23
only, no graphics or color).
Unfortunately, i don't know how to implement renderer, even text-only
render is non-trivial.

> also looking at zvbis upcomming features
> * Multi-station Teletext page cache
> that one my code supported 8 years ago already ...

I can't get it caching all teletext pages, so i've made my own trivial
array-based cache.

> * Teletext and CC caption/subtitle recording in formats like MPSub,
>   QuickTime Text, SAMI or SubViewer, with color, styles and position
>   preserved as far as possible
> that one qualifies the lib as something i will never ever install on
> any system i own
This library also has nice debug fprintf(stderr,...) for about four
years long ;)

> PS: and yes i do vote for reverting the patch and i vote against any
> patch using an external lib for teletext decoding theres no need for
> this, teletext is very simple
If i undestand you right, your main objections is
unnessary extra functionality of zvbi and unrealistic future plans?

Advantages of lzvbi are support for teletext and closed captions for
v4l,v4l2 and bktr and good teletext->rgba renderer.

What about keeping zvbi as-is untill native grabber/renderer will be
implemented (i'm afraid this will take a looong time)?

-- 
Regards,
Vladimir Voroshilov     mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719