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