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 &quot;fix&quot; it was to re-encode the edited recording with &#39;mencoder -ovc copy -oac copy -of mpeg -mpegopts format=pes2 -o new/001.vdr old/001.vdr&#39;<br>
<br>I would see frames being skipped when it reaches where the cut took place...<br><br>I&#39;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> &lt;<a href="mailto:emme@emmes-world.de">emme@emmes-world.de</a>&gt; 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> &gt; On 23 Jul 2008, at 23:06, Martin Emrich wrote:<br> &gt;<br> &gt;&gt;&nbsp;&nbsp;(I wonder why there&#39;s no simple &quot;TV simulator&quot; that upmixes 50<br> &gt;&gt; fields/s to 50 frames/s just like a CRT TV?).<br>
 &gt;<br> &gt;<br> &gt; It&#39;s very hard to simulate this &#39;upmix&#39;. A CRT TV actually moves the<br> &gt; electron beam across the screen and the phosphor has some time it<br> &gt; stays illuminated after being hit by the beam. This is very hard to<br>
 &gt; simulate with a digital screen which is either on or off, or has some<br> &gt; 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&#39;s assume we have two frames to be played back, which each consists<br> of two fields:&nbsp;&nbsp;{1,2} and {3,4}.<br> <br> I don&#39;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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333<br> 22222&nbsp;&nbsp;...1/25th sec. later:&nbsp;&nbsp; 44444<br> 11111&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333<br>
 22222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;44444<br> <br> As field 3 is a 1/50th second &quot;older&quot; 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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11111&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333<br> .....&nbsp;&nbsp;1/50th s.&nbsp;&nbsp;22222&nbsp;&nbsp;1/50s 22222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;44444<br> 11111&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11111&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;33333<br> .....&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 22222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;22222&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;44444<br> <br> So each field ist still being shown for a 1/25th of a second, but for<br>
 the &quot;right&quot; 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> &gt; The dscaler project has implemented some of the best deinterlacing<br> &gt; algorithms and most of the tvtime algorithms are implemented (to my<br> &gt; knowledge) with basis in dscaler source / ideas. See http://<br>
 &gt; <a href="http://dscaler.org/">dscaler.org/</a> . dscaler basically is a deinterlace and display program<br> &gt; that takes input from bt8x8 based capture cards.<br> <br> I assume these are the &quot;tvtime&quot; 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> &gt; Someone on that project had an idea to create a setup where the<br> &gt; display hardware was synced to the input clock of the capture card,<br> &gt; but I&#39;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&#39;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>