[vdr] OT: Deinterlacing algorithms [WAS:Re: [PATCH] RGB/PAL over VGA at variable frame rate]

Theunis Potgieter theunis.potgieter at gmail.com
Wed Jul 23 22:38:52 CEST 2008


I notice a AV desync after 5 minutes, it definitely happens when it reaches
an advertisement that was cut out, or when I jump to a advertisement. :(

the only way I could "fix" it was to re-encode the edited recording with
'mencoder -ovc copy -oac copy -of mpeg -mpegopts format=pes2 -o new/001.vdr
old/001.vdr'

I would see frames being skipped when it reaches where the cut took place...

I'm using vdr 1.6.0_p1

Theunis

On 23/07/2008, Martin Emrich <emme at emmes-world.de> wrote:
>
> Hi!
>
> Torgeir Veimo schrieb:
> > On 23 Jul 2008, at 23:06, Martin Emrich wrote:
> >
> >>  (I wonder why there's no simple "TV simulator" that upmixes 50
> >> fields/s to 50 frames/s just like a CRT TV?).
> >
> >
> > It's very hard to simulate this 'upmix'. A CRT TV actually moves the
> > electron beam across the screen and the phosphor has some time it
> > stays illuminated after being hit by the beam. This is very hard to
> > simulate with a digital screen which is either on or off, or has some
> > slowness by itself which is different from how a CRT screen works.
>
> I did not mean to actually simulate the brightness decay in the
> phosphors, just the points in time where the fields are presented.
>
> Let's assume we have two frames to be played back, which each consists
> of two fields:  {1,2} and {3,4}.
>
> I don't know if it actually works this way, but as far as I know,
> playing back interlaced content with 25 frames/s on a progressive
> display looks this way:
>
> 11111                          33333
> 22222  ...1/25th sec. later:   44444
> 11111                          33333
> 22222                          44444
>
> As field 3 is a 1/50th second "older" than field 4, there are jaggies in
> moving scenes.
>
> What I am looking for would be this, with 50 frames/s:
>
> 11111             11111        33333      33333
> .....  1/50th s.  22222  1/50s 22222      44444
> 11111             11111        33333      33333
> .....             22222        22222      44444
>
> So each field ist still being shown for a 1/25th of a second, but for
> the "right" 1/25th second. The output then no longer serves 25fps but
> 50fps to XVideo, DirectFB or whatever.
>
> All of this of course makes only sense for PAL content when the TV can
> do 50Hz, not 60Hz.
>
> > The dscaler project has implemented some of the best deinterlacing
> > algorithms and most of the tvtime algorithms are implemented (to my
> > knowledge) with basis in dscaler source / ideas. See http://
> > dscaler.org/ . dscaler basically is a deinterlace and display program
> > that takes input from bt8x8 based capture cards.
>
> I assume these are the "tvtime" deinterlacers in the libxineoutput
> plugin. I played around with them, but none of them resultet in a
> picture as sharp and contrasty as without any deinterlacer. So I have to
> choose between sharpness and clean motions. And even during the EURO
> 2008, I chose the first.
>
> > Someone on that project had an idea to create a setup where the
> > display hardware was synced to the input clock of the capture card,
> > but I'm not sure if anything ever came out of that idea.
>
> I also thought of that. One then would have to sync to the soundcard's
> buffer, too, and remove/duplicate samples as necessary, to keep the
> audio synchronized.
>
> BTW: How does libxineoutput synchronize? I noticed a slight AV desync
> growing over ca. 5 minutes, the the audio jumps once and the desync
> jumps into the right position (Digital output to AV receiver).
>
> Ciao
>
> Martin
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20080723/bd9a0f35/attachment.htm 


More information about the vdr mailing list