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

[s.huelswitt@gmx.de (Stefan Huelswitt)]

On 17 Apr 2003 "Dr. Werner Fink" <werner@suse.de> wrote:

[...]
> IMHO a simple approach would be something like
> 
>           cutAssoc   cutOut        cutIn
>             ^          ^            ^ 
> video  -----&----------%************%-----------------
> audio  -----&----------%--|*********%**|--------------
> 
>                        ^^^^
>                        PTS offset between video and audio
[...]

Man, this is getting far to complicated for me (not only in ways
of programming). And I think this doesn't leads in the right
direction.

Let's go one step back and see what we have.

With cutter2 patch (only setting broken link flag) we have a
perfect video stream (no artifacts). This has confirmed by
Werner, Oliver & Tobias.

I agree with Oliver that the cutter2 patch gives better results
than cutter2-exp. With the last, the cutting point looks somewhat
jumpy (difficult to explain).

So for me, the cutter2 patch is the way to got. Unfortunaly in
some cases a short audio sequence from before the cutIn leaks
over. But why?

Normaly we would say, that the decoder drops audio packets with a
PTS which doesn't match any video packet (and the leaking audio
packets have PTS<cutInPTS).

I looked at the output of the cutter2-exp patch and found that
there are two types of cutting points:

The first one:

cutInPTS=2149248509 0x0801aedfd
type=0xc0 packetPTS=2149212236 0x0801a604c dropped
**
type=0xc0 packetPTS=0 0x000000000 dropped
**
type=0xc0 packetPTS=0 0x000000000 dropped
**
**

You see that the cutIn video packet is immediately followed by a
audio packet with PTS.

The second one:

cutInPTS=2137051709 0x07f60d23d
type=0xc0 packetPTS=0 0x000000000 dropped
**
type=0xc0 packetPTS=0 0x000000000 dropped
**
**
type=0xc0 packetPTS=2137029836 0x07f607ccc dropped
**
**

As not all audio packets carry PTS, in this case the cutIn video
packet is followed by two audio packets without PTS.

My theory: in the first case, the decoder immediately notices the
non-matching PTS. In the second case, the two PTS-less packets
are played before the decoder notice the PTS jump.

I have modified the cutter2-exp patch with

diff -u vdr-1.1.27-cutter/cutter.c vdr-1.1.27-cutter/cutter.c
--- vdr-1.1.27-cutter/cutter.c	2003-04-16 15:32:24.000000000 +0200
+++ vdr-1.1.27-cutter/cutter.c	2003-04-17 16:11:47.000000000 +0200
@@ -181,9 +181,9 @@
                    printf("type=0x%02x packetPTS=%llu 0x%09llx",type,pts,pts);
                    if(!pts || pts<cutInPTS) { // drop packet
                      printf(" dropped\n");
-                     Length-=len;
-                     memmove(buffer+index,buffer+index+len,Length-index);
-                     len=0;
+                     //Length-=len;
+                     //memmove(buffer+index,buffer+index+len,Length-index);
+                     //len=0;
                      }
                    else {
                      printf(" keeped, missing audio d-pts=%lld\n",pts-cutInPTS);

This disables dropping of packets, but keeps the output.

Could you please try to verify with this modifications, if the
leaking audio only appears with the second type of cutting
points? Werner, you seems to have a test case for this.

-- 
Stefan Huelswitt
huels@iname.com  | http://home.pages.de/~nathan


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