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
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.
Home |
Main Index |
Thread Index