[vdr] Re: vdr cuts recordings with ugly artifacts at cutting-points

["Dr. Werner Fink" <werner@suse.de>]

On Thu, Apr 17, 2003 at 02:47:54AM +0200, Oliver Endriss wrote:
> Stefan Huelswitt wrote:
> > On 16 Apr 2003 Oliver Endriss <o.endriss@gmx.de> wrote:
> > > I'll test the new patch asap.
> > Yes, please. We continue the discussion after this.
> 
> Ok, I cut a recording using
> (1) patch cutter2
> (2) patch cutter2-exp
> 
> The recording  had some overlap before/after the commercials.
> I used the same cutting marks for both tests.
> 
> (1) produced slightly better results. As I suspected in my previous 
> post, silence is more disturbing than wrong sound.
> 
> > > Interleaving them with the video is not enough. You have to fix the
> > > PTS of the audio packets, too.
> >
> > Sure? I think the deocder will notice the PTS jump in the video
> > stream and select the right audio packets.
> 
> I was referring to the audio packets at the beginning of the commercial 
> break. They belong to the first video packets after the break, but 
> their PTS does not match the PTS of these video packets.
> 
> Meanwhile, Werner posted the offset which has to be added to the PTS of 
> these audio packets. (Another solution might be to completely remove 
> the PTS from these audio packets.)

... with one further boundary condition: the audio packages between
cutAssoc and cutOut may not belong to the video packages after cutIn.
Therefore the PTS + (PTS_cutIn - PTS_cut_out) of the audio packages
should be near by the PTS of the video packages - PTS_delay.  This
seems to lead a complicted algorithm.  To solve this problem an
index may used with two informations: a) the offset of the I-frame
_and_ b) the offset (400ms back) of the corresponding first audio frame.

> > >> I'm not sure if this really worked, as the PTS of the (exccess)
> > >> audio packets after the cutIn doesn't match the PTS of the video
> > >> packets before the cutOut.
> > >
> > > If it does not work, I don't understand why I got some clean cuts
> > > in the past. Anyway, your patch is a great improvement already.
> > > Thx.
> >
> > Well, above you said that we have to fix the PTS and now you say
> > that it works even if the PTS doesn't match. What?
> 
> For a *clean* solution we had to fix the PTS (and remux around the cut). 

Yep ... is there a open source tool know which are able to do so.

> But I *hope* that the dirty solution works (because the decoder is 
> well-behaving). If it works I don't ask why :-)



         Werner


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.