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

[Oliver Endriss <o.endriss@gmx.de>]

Stefan Huelswitt wrote:
> On 16 Apr 2003 Oliver Endriss <o.endriss@gmx.de> wrote:
> > Stefan Huelswitt wrote:
> >> On 16 Apr 2003 "Dr. Werner Fink" <werner@suse.de> wrote:
> >> > ... whats about the audio/dd frames between cutOut mark
> >> > upto the point where the video PTS at cutOut reach the
> >> > audio/dd PTS?  Shouldn't those ones be included or
> >> > replaced with silence:
> >> >
> >> >                            commercial
> >> >   video  ----------------%************%-----------------
> >> >   audio  ----------------%--|*********%**|--------------
> >> >                          ^            ^
> >> >                        cutOut       cutIn
> >> >                          ^^^^
> >> >                          audio PTS delay
> >> >
> >> > ?
> >>
> >> Any packets behind cutOut are removed anyways (just as in plain
> >> vdr). I can only guess that the driver will replace the missing
> >> packets with silence.
> >>
> >> For a completely correct cut, these packets have to be recovered
> >> and must be muxed into the packets after cutIn. This is not easy.
> >
> > What about a simplified approach: Audio cutting could be based on
> > the PTS of the video, i.e.
> > - delay audio cutOut until audio_PTS > video_PTS(CutOut)
> > - delay audio cutIn until audio_PTS > video_PTS(cutIn)
> > Maybe this would work *without* remuxing.
>
> The current patch only does the second one.

Yes, and might introduce some audio silence (400ms).
I'll test the new patch asap.

> I think, the first one cannot work without muxing.
> I done as you suggested, we will end with a sequence like this:
>
> VVVAVVAVVVA%AAA%VVVVVVVVVVAVVAVVAVVA
>
>            ^   ^
>
>       cutOut   cutIn
>
> Before the cutOut is the original muxed stream. After the cutOut,
> all audio packets according to rule 1 follow. After the cutIn, we
> have only video packets (according to rule 2).

Correct. I simply hope that the decoder has enough buffer capacity for 
the AAA sequence. I think it's worth a try.

> Don't know if the decoder can buffer up so much audio packets. I
> think the audio packets between the cutting points have to be
> muxed with the video packets following the cutIn.

Interleaving them with the video is not enough. You have to fix the PTS 
of the audio packets, too.

> > Silence is bad[tm]. With the old solution, you could very often
> > find a good cutting point, because some channels repeat a some
> > seconds of a movie after the commercial break. If you simply
> > discard audio frames this will not work anymore.
>
> 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.

Oliver


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