Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: vdr cuts recordings with ugly artifacts at cutting-points
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.
Home |
Main Index |
Thread Index