Probleme mit Schnittmarken

geronimo · 14. Oktober 2012

Hallo,

kam seit längerem sporadisch vor, in letzter Zeit fällt es mir vermehrt auf:
Wenn ich ne Aufnahme das erste Mal anschaue, kann es sein, dass es mehrere Schnittmarken gibt, die manchmal nicht ganz passen.
Es ist also angesagt, Schnittmarken zu ändern, zu löschen und/oder neue hinzuzufügen.

Nicht immer, aber immer öfter kommt es vor, dass sich Schnittmarken nicht löschen lassen.
Zuerst hatte ich die Kommentare in Verdacht (markad vermerkt wohl, warum es dort eine Schnittmarke gibt).
Aber das Löschen der Kommentare brachte keine Besserung. Es liegt auch definitiv kein Berechtigungsproblem vor.

Abhilfe schafft nur das manuelle Löschen. Sinnvollerweise sollte die resume-Marke in der Nähe der zu löschenden Schnittmarke liegen, damit man die auch wieder findet.
Schnittmarken die im VDR (manuell) erzeugt werden, lassen sich immer verschieben oder löschen.

Könnte es sein, dass markad gelegentlich die Schnittmarke an einer Stelle setzt, die der VDR nicht als Schnittmarken-Position akzeptiert?
Es würde vermutlich schon reichen, wenn die Marke einen Frame daneben liegt. Vielleicht führt das ja dazu, dass der VDR die Marke nicht löschen kann?
Dummerweise kann man die Schnittmarke auch nicht überspringen mit Sprungbefehl zu nächster Marke.
Manchmal hilft ein Zeitsprung (F3) weiter, aber manchmal klappt nicht mal der.

Kann jemand den Effekt bestätigen und/oder weiß vielleicht sogar, was man dagegen tun könnte?

Gruß Gero

anbr · 14. Oktober 2012

Hi,

ja, ist hier auch so, wenn die Schnittmarke nicht auf einem I-Frame liegt, lässt sie sich nicht verschieben.

Das Problem ist aber schon alt, unter vdr 1.6 hatte ich mir mit folgenden Perl Script geholfen.

Er verschiebt alle Marken auf das nächste I-Frame. (Aber kann halt nur das alte VDR-Format fixen)
# cat /opt/vdr/bin/fixmarks.pl

Perl

#!/usr/bin/perl


use strict;
use warnings;


my $debug = 0;
my $recording;
my $marks;
my %Iframes;


sub read_marks_file {
	my $marks_file = shift;
	open MFH, "$marks_file" || die "Could not open marks.vdr";
    @{$marks} = ();
    my @raw_marks = <MFH>;
	foreach (@raw_marks) {
		chomp $_;
        $_ = (split /\s/, $_)[0];
        if ($_ !~ /^\d{1,2}:\d{1,2}:\d{1,2}\.\d{1,2}$/) {
            print("Could not read mark $_, skipping\n");
            next;
        }
		my ($h,$m,$s,$f) = split /[:.]/,$_;
		my $frame = ($h * 3600 + $m * 60 + $s)* 25 + $f;
		my $real_frame = (find_realframe($frame))[0];
		my $real_mark = frames2mark($real_frame);
        if ($real_mark ne "-1") {
            push @{$marks}, $real_mark;
        }
	}
}


sub find_realframe{
	my $frame = int (shift);
	#print "got frame $frame\n";
	if ($Iframes{$frame}) {
		return ($frame, $Iframes{$frame});
	}
	my $return_frame = 0;
	my $i = 1;
	while ((! $return_frame) && ($i < 10)) {
		if ($Iframes{$frame - $i}) {
			print( "Frame $i frames before $frame is an I-Frame.\n");
			print( "Returning " . ($frame - $i) . " " .$Iframes{$frame - $i} . "\n") if $debug;
			return ($frame - $i , $Iframes{$frame - $i});
		}
		elsif ($Iframes{$frame + $i}) {
			print( "Frame $i frames behind $frame is an I-Frame\n");
			print( "Returning " . ($frame + $i) . " " .$Iframes{$frame + $i} . "\n") if $debug;
			return ($frame + $i , $Iframes{$frame + $i});
		}
		else {
			print( "no iframe found in $i frame distance\n") if $debug;
			$i++;
		}
	}
	die "could not find a reasonably positioned iframe, exiting\n";
};


sub save_marks_file {
  	my $marks_file = shift;


    if (-e "$marks_file") {
        my $err = system (sprintf("mv '%s' '%s~'",$marks_file,$marks_file));
        if ($err) {die "Something happend while backing up original mark file: $!...\n";}
    }


    my @newmarks;


    @newmarks = sort(@{$marks});
    open OFH, ">$marks_file" or die "$!\n";
    binmode OFH;
    print OFH (join"\n",@newmarks) ."\n";
    close OFH;
}


sub read_index_file{
	my $index_file = shift;

	open FH,"$index_file" or die "Can not open File: $!\n";

	my $buffer;
	my $bytesread = sysread (FH, $buffer, 10000000);


	my $offset = 0;
	my $I_counter = 0;

	while ($offset < $bytesread) {
		my ($c, $Ptype, $number, $reserved) = unpack ("I C C S", substr($buffer, $offset, 8));
		#print "Got $c, $Ptype, $number, $reserved\n";
		$offset += 8;
		#print "offset is $offset\n";
		$I_counter++;
		$Iframes{$I_counter} = "$c : $number" if ($Ptype == 1);
		#push @{$Iframe_list},$I_counter if ($Ptype == 1);

	}
	print("Got " . (scalar(keys(%Iframes))) . " I-Frames in this index file...\n") if $debug;
#	$total_frames = $I_counter;
	return ;
};


sub frames2mark {
	my $frame = shift;


	my $rest = $frame  % 25;
	my $full_secs = int ($frame  * 0.04);

	my $h = int($full_secs/3600);
	my $min = int(($full_secs - (3600 * $h)) / 60);
	my $sec = $full_secs - (3600 * $h + 60 * $min);
	return sprintf "%1u:%02u:%02u.%02u", $h, $min, $sec, $rest;
};


sub mark2frames{
	my $mark = shift;
	my($h, $m, $s, $f) = split /[:.]/, $mark;
	my $frame = (3600 * $h + 60 * $m + $s) * 25 + $f ;
	return $frame;
};






sub usage {
  die 'fixmarks.pl -r /video/recording/...rec';
};


sub parse_options {
    my @params = @_;

    while ($params[0]) {

        my $parm = shift @params;
        if ($parm eq "-r") {
            if (! $params[0])  {
                die "You must supply a recording to the -r option!\n";
            }
            $recording = shift @params;
        } elsif ($parm eq "-d") {
            $debug = 1;
        } 
        else {
            print "Unknown Option: $parm\n";
            usage();
        }
    }

}










parse_options(@ARGV);


read_index_file($recording . "/index.vdr");
read_marks_file($recording . "/marks.vdr");
save_marks_file($recording . "/marks.vdr");

Alles anzeigen

geronimo · 14. Oktober 2012

Hi,

danke für die Bestätigung.

Zitat

Das Problem ist aber schon alt, unter vdr 1.6 hatte ich mir mit folgenden Perl Script geholfen.

Hm, würde es nicht mehr Sinn machen, einen Patch für markad zu schreiben?
Wenn der VDR nur Schnittmarken auf I-Frames behandeln kann, dann dürften auch keine anderen erstellt werden. Oder?

Ich mein ja nur. Was helfen framegenaue Schnittmarken, wenn niemand damit umgehen kann?
Ist nicht die Index-Datei dafür da, um solche "Probleme" zu vermeiden?

... oder gibt es etwa ein Schnittprogramm, das framegenau schneiden kann (und welches ich noch nicht kenne)?
Ok, aber selbst dann wäre es fragwürdig, Schnittmarken in VDR-Dateien abzulegen, mit denen der VDR nicht umgehen kann.

Gruß Gero

Joe_D · 14. Oktober 2012

Zitat von geronimo

Könnte es sein, dass markad gelegentlich die Schnittmarke an einer Stelle setzt, die der VDR nicht als Schnittmarken-Position akzeptiert?

Welche markad-Version verwendest Du? Eigentlich steht im Log genau drin, wenn markad Schnittmarken nicht an I-Frames gesetzt hat.

Gruß

Joe_D

geronimo · 14. Oktober 2012

Zitat

... wenn markad Schnittmarken nicht an I-Frames gesetzt hat.

Wieso lässt Du das überhaupt zu?

Gibt es eine Option, mit der man das unterbinden kann?
Falls nicht, könntest Du da was schnitzen?
Vielleicht die /etc/defaults/vdr auslesen?

Code

dpkg -l 
ii  vdr-markad                         0.1.3-1                            amd64        Tool to mark advertisements in VDR recordings
ii  vdr-plugin-markad                  0.1.3-1                            amd64        Plugin for VDR to mark advertisements in recordings

log-Auszug:

Code

Oct 14 05:06:18 vdrdev markad: [3006] assuming stop (329986)
Oct 14 05:06:18 vdr markad: [3006] index doesn't match marks, sorry you're lost
Oct 14 05:06:18 vdr markad: [3006] 2nd pass
Oct 14 05:06:18 vdr markad: [3006] duplicate packet, skipping (0x17de)
Oct 14 05:06:27 vdr markad: [3006] H264 video stream with filler nalu (0x17de)
Oct 14 05:06:27 vdr markad: [3006] H264 video stream with filler nalu (0x17de)
Oct 14 05:06:27 vdr markad: [3006] duplicate packet, skipping (0x17de)
Oct 14 05:06:50 vdr markad: [3006] skipped 52040484 bytes
Oct 14 05:06:50 vdr markad: [3006] processed time 550.18s, 348015/22045 frames, 672.6 fps, 13.5 pps

Also die Position der Marken war an sich nicht schlecht. Nur es waren zuviel und sie ließen sich nicht bearbeiten.
Wenn ich den log anschaue - wäre es möglich, dass die Untersuchung zu früh startet, dass der Index noch nicht fertig geschrieben ist?

Gruß Gero

Joe_D · 14. Oktober 2012

Zitat von geronimo

Wieso lässt Du das überhaupt zu?

markad ist nicht VDR-only. Es setzt Marken in jedem TS-File. Daher verwendet es nicht den index vom VDR sondern zählt selbst die Frames. Bei TS-SD funktioniert das auch zu 100%, bei PES-SD nocht zu 99% aber bei TS-HD ist die VDR Framezählung irgendwie selten dämlich und wurde auch noch zig mal geändert. markad für TS-HD benötigt somit einen vdr >= 1.7.22 damit das annähernd funktioniert...

Welche VDR-Version verwendest Du?

Gruß

Joe_D

geronimo · 14. Oktober 2012

Zitat von Joe_D

markad ist nicht VDR-only.

Hm, ok - das kann ich gelten lassen.

Dann sollte es aber die Option geben, dass im VDR-Betrieb die Schnittmarken via Index verifiziert werden.
Das kann ja in einem eigenen Lauf nach der Erzeugung der Schnittmarken erfolgen.
Zumindest bei mir erfolgen die meisten Aufnahmen nachts, wenn ich eh nix vom VDR will - d.h. ist überhaupt nicht zeitkritisch.

Zitat

Welche VDR-Version verwendest Du?

Code

ii  vdr                                      1.7.28-1                             amd64        Video Disk Recorder for DVB cards

... mal ganz neugierig gefragt:
Wer kann denn mit Schnittmarken umgehen, die nicht auf IFrames liegen?

Gruß Gero

Joe_D · 14. Oktober 2012

Zitat von geronimo

Dann sollte es aber die Option geben, dass im VDR-Betrieb die Schnittmarken via Index verifiziert werden.

Irgendwie will mich keiner verstehen markad zählt intern selbst die Frames, dekodiert mittels libavcodec nur I-Frames und setzt damit automatisch nur an I-Frames die Marken. Nur läuft die interne Zählung bei markad und dem VDR manchmal auseinander (und zwar nur bei HD).

Zitat von geronimo

1.7.28-1

Dann probier bitte die 1.5pre aus dem GIT aus..

Zitat von geronimo

... mal ganz neugierig gefragt:Wer kann denn mit Schnittmarken umgehen, die nicht auf IFrames liegen?

Keine Ahnung, verstehe aber die Frage aber auch nicht...

Gruß

Joe_D

geronimo · 14. Oktober 2012

Zitat

Nur läuft die interne Zählung bei markad und dem VDR manchmal auseinander (und zwar nur bei HD).

... und selbst wenn.
Wenn Du es schaffst, Schnittmarken an den richtigen Stellen zu setzen, dann kostet es Dich doch nicht mal ein Lächeln, die Schnittmarken VDR-/index-kondom zu verändern. Das Format der Index-Datei ist doch wirklich iesie und eine Überprüfung würde auch nicht sonderlich viel CPU-Zeit verbraten.

Zitat

Dann probier bitte die 1.5pre aus dem GIT aus..

Sorry, aber ich verwende den VDR von etobi.
Dafür fang ich jetzt nicht an, nen VDR selbst zu bauen.
Wenn Du das Problem gelöst hast, ist es toll.
Ich kann warten, bis es bei e-tobi zur Verfügung steht.

Zitat

Keine Ahnung, verstehe aber die Frage aber auch nicht...

Na gut - offensichtlich hatte ich das Problem nicht verstanden.
Es liegt also nicht daran, dass Du andere Frames mit Schnittmarken beglückst, sondern dass der VDR andere Frames als IFrames ansieht, als markad.
Ich kann ja verstehen, wenn Du Dich dagegen sträubst, aber ein Kompatibilitätsmodus für den VDR wäre wirklich was feines
... zumindest für so faule Anwender wie mich.

Gruß Gero

kls · 14. Oktober 2012

Zitat von Joe_D

...bei TS-HD ist die VDR Framezählung irgendwie selten dämlich und wurde auch noch zig mal geändert. markad für TS-HD benötigt somit einen vdr >= 1.7.22 damit das annähernd funktioniert...

Was genau ist denn an der VDR Framezählung "selten dämlich"?

Klaus

Joe_D · 14. Oktober 2012

Zitat von kls

Was genau ist denn an der VDR Framezählung "selten dämlich"?

Wenn ich diesen Code verwende der NAL_AUD und NAL_SLICE auswertet

Code

if (nalu==NAL_AUD)
    {
        if (pkt[5]==0x10)
        {
            maContext->Video.Info.Pict_Type=MA_I_TYPE;
            return true;
        }
        else
        {
            if (maContext->Video.Info.Interlaced) {
                if (H264.use_field) return true;
            } else {
                return true;
            }
        }
    }


    if ((nalu==NAL_SLICE) || (nalu==NAL_IDR_SLICE))
    {
        uint8_t *nal_data=(uint8_t*) alloca(len);
        if (!nal_data) return false;
        int nal_len = nalUnescape(nal_data, pkt + 5, len - 5);
        cBitStream bs(nal_data, nal_len);


        bs.skipUeGolomb(); // first_mb_in_slice
        bs.skipUeGolomb(); // slice_type
        bs.skipUeGolomb(); // pic_parameter_set_id
        if (H264.separate_colour_plane_flag)
        {
            bs.skipBits(2); // colour_plane_id
        }
        bs.skipBits(H264.log2_max_frame_num); // frame_num


        if (maContext->Video.Info.Interlaced)
        {
            if (bs.getBit()) // field_pic_flag
            {
                H264.use_field=bs.getBit(); // bottom_field_flag
            } else {
                H264.use_field=true;
            }
        }
    }
    return false;

Alles anzeigen

bekomme ich ausschliesslich bei Interlaced eine unterschiedliche Zahl an Frames als der VDR, wenn ich jedoch diesen Code verwende:

Code

if (nalu==NAL_AUD)
    {
        if (pkt[5]==0x10)
        {
            maContext->Video.Info.Pict_Type=MA_I_TYPE;
            H264.use_field=false;
            return true;
        }
        else
        {
            if (maContext->Video.Info.Interlaced)
            {
                if (H264.use_field) {
                    H264.use_field=false;
                    return true;
                } else {
                    H264.use_field=true;
                }
            } else {
                return true;
            }
        }
    }
    return false;

Alles anzeigen

der nur hin und hertoggled dann passt es bei Interlaced unverständlicherweise besser???

Gruß

Joe_D

geronimo · 14. Oktober 2012

Zitat

bekomme ich ausschliesslich bei Interlaced eine unterschiedliche Zahl an Frames als der VDR

Öhm, also mein aktueller Fall war eine HD-Aufnahme.
Wenn ich mich nicht irre, tritt der Effekt (bei mir) vorwiegend bei HD-Aufnahmen auf.

Gruß Gero

kls · 14. Oktober 2012

Zitat von Joe_D

Wenn ich diesen Code verwende der NAL_AUD und NAL_SLICE auswertet
...
bekomme ich ausschliesslich bei Interlaced eine unterschiedliche Zahl an Frames als der VDR, wenn ich jedoch diesen Code verwende:
...
der nur hin und hertoggled dann passt es bei Interlaced unverständlicherweise besser???

Und das beantwortet jetzt die Frage, was genau an der VDR Framezählung "selten dämlich" ist, in welcher Weise?

Versteh' mich bitte nicht falsch. Ich will nicht behaupten, daß VDR alles richtig macht, was die Frame-Erkennung angeht. Aber es scheint ja (inzwischen) doch recht gut zu funktionieren, und das ohne in die Daten allzu "tief" hineinzuschauen. Insbesondere verwendet VDR keine Library, die das ganze Gedöns total "aufdröselt". Ich bin der Meinung, die Frame-Grenzen müssen auf einer relativ weit "außen" liegenden Ebene erkennbar sein.

Für Vorschläge, wie man die VDR-Frame-Erkennung verbessern kann (ohne die Komplexität unnötig zu vergrößern) bin ich immer offen.

Klaus

Copperhead · 14. Oktober 2012

Naja, gut ist relativ.

Bei 1080i Aufnahmen (speziell HD+) gibt es oft eine ziemlich heftige Klötzchenbildung an den Schnittstellen.

Und bevor es wieder heißt softhddevice ist schuld. Ich hatte das auch schon zu der Zeit, wo ich noch die S2-6400 benutzt habe.

MFG · 14. Oktober 2012

Moin moin geronimo,

ärgere mich auch mit nicht lösch bzw. verschiebbaren Schnittmarken herum.

Mein WorkARound ist an die Stelle der nicht verschiebbaren Schnittstelle springen, mit "0" eine weitere zu setzen, mit "1", "3" oder PLAY dort wech kommen und an gewünschter Stelle mit "0" Marke setzen.
Hiernach manuell in der marks alle nicht gewünschten Marken rauslöschen und "2" für's Schneiden.

Auftreten tut das bei mir primär auf den ÖR HD dvb-c KDG, aber nicht bei allen HD Aufzeichnungen.
Imho sind diese Transponder von KDG neu zusammengestellt und hier kommt meine Vermutung,
dass das Signal nicht gänzlich konform ist - BitFehler.

Indiz, oft ist der index offentsichlich falsch, hier mit 257' in Aufzeichnungen angezeigt, aber in den die marks realen Zeiten sihe unten.

Code

root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec# ls -hal
insgesamt 15G
drwxr-xr-x 2 vdr vdr 4,0K 2012-10-14 14:23 .
drwxr-xr-x 3 vdr vdr 4,0K 2012-10-14 03:09 ..
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 03:26 00001.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 03:43 00002.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 04:00 00003.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 04:18 00004.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 04:36 00005.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 04:54 00006.ts
-rw-r--r-- 1 vdr vdr 2,0G 2012-10-14 05:13 00007.ts
-rw-r--r-- 1 vdr vdr 487M 2012-10-14 05:18 00008.ts
-rw-r--r-- 1 vdr vdr 3,0M 2012-10-14 05:23 index
-rw-r--r-- 1 vdr vdr  852 2012-10-14 03:09 info
-rw-r--r-- 1 vdr vdr 2,1K 2012-10-14 05:23 markad.log
-rw-r--r-- 1 vdr vdr  162 2012-10-14 14:23 marks
-rw-r--r-- 1 vdr vdr    9 2012-10-14 14:30 resume
root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec# cat marks
0:00:23.08 detected logo start (1132)*
0:11:46.24 detected logo stop (35323)
0:12:42.16 detected logo start (38115)*
0:25:24.16
1:45:24.17 assuming stop (316191)
root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec# cat markad.log
Sun Oct 14 03:09:01 [7505] starting v0.1.4pre (32bit)
Sun Oct 14 03:09:01 [7505] on /media/easyvdr01/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec
Sun Oct 14 03:09:11 [7505] broadcast aspectratio 16:9 (from info)
Sun Oct 14 03:09:11 [7505] getting broadcast start from info mtime
Sun Oct 14 03:09:11 [7505] pre-timer 5m
Sun Oct 14 03:09:11 [7505] broadcast length 105m
Sun Oct 14 03:09:11 [7505] found H264-video (0x17de)
Sun Oct 14 03:09:11 [7505] found AC3 (0x17ea)
Sun Oct 14 03:09:11 [7505] using libavcodec.so.53.6.0 with 2 threads
Sun Oct 14 03:09:11 [7505] using codec H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
Sun Oct 14 03:09:11 [7505] channel ZDF_HD
Sun Oct 14 03:09:26 [7505] processing file 00001
Sun Oct 14 03:09:26 [7505] HDTV 1280x720p50
Sun Oct 14 03:10:13 [7505] detected logo start (1132)*
Sun Oct 14 03:17:16 [7505] checking start
Sun Oct 14 03:17:16 [7505] broadcast with 2 audio channels, disabling AC3 decoding
Sun Oct 14 03:17:16 [7505] aspectratio of 16:9 detected.
Sun Oct 14 03:17:16 [7505] using mark on position 1132 as start mark
Sun Oct 14 03:33:15 [7505] detected logo stop (35323)
Sun Oct 14 03:35:05 [7505] detected logo start (38115)*
Sun Oct 14 03:43:43 [7505] processing file 00002
Sun Oct 14 04:17:07 [7505] processing file 00003
Sun Oct 14 04:51:46 [7505] processing file 00004
Sun Oct 14 05:18:40 [7505] processing file 00005
Sun Oct 14 05:20:06 [7505] processing file 00006
Sun Oct 14 05:21:28 [7505] processing file 00007
Sun Oct 14 05:21:56 [7505] checking stop
Sun Oct 14 05:21:56 [7505] assuming stop (316191)
Sun Oct 14 05:22:54 [7505] processing file 00008
Sun Oct 14 05:23:15 [7505] index too short
Sun Oct 14 05:23:15 [7505] recreated index
Sun Oct 14 05:23:15 [7505] writing info file
Sun Oct 14 05:23:15 [7505] 2nd pass
Sun Oct 14 05:23:15 [7505] processing file 00001 (before mark 35323)
Sun Oct 14 05:23:25 [7505] processing file 00001 (after mark 38115)
Sun Oct 14 05:23:46 [7505] processing file 00002 (after mark 38115)
Sun Oct 14 05:23:51 [7505] processed time 654.98s, 386684/22087 frames, 624.1 fps, 12.5 pps
root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec#

Alles anzeigen

Nun den index mal neugemacht - index nach indexorg ge"F6"tet und Abspielen lassen bis index fertig - fast halb so groß ???

Code

-rw-r--r-- 1 vdr vdr 1,5M 2012-10-14 16:21 index
-rw-r--r-- 1 vdr vdr 3,0M 2012-10-14 05:23 indexorg

dann Schnittmarken gesetzt.

Code

root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec# cat marks
0:00:22.17
0:00:23.08 detected logo start (1132)*
0:11:46.13
0:11:46.24 detected logo stop (35323)
0:12:42.16 detected logo start (38115)*
0:25:23.20
0:25:24.16
1:45:23.22
1:45:24.17 assuming stop (316191)
1:59:03.10
root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec#

Alles anzeigen

so nun bis auf 12:42 und 1:59 rauslöschen, Aufzeichnung neu abspielen lassen, die Schnittmarken sollten OK sein und schneiden.

Code

root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec# cat marks
0:12:42.16 detected logo start (38115)*
1:59:03.10
root@easyVDR:/video0/High_Heels_-_Die_Waffen_einer_Frau/2012-10-14.03.09.40-0.rec#

Pascht!.

MfG.
................MFG.

Basis:
easyVDR1.0
vdr (1.7.21/1.7.21) - The Video Disk Recorder
markad (0.1.4pre) - Mark advertisements
Kernel: 3.0.0-19-generic
IP-Adresse: 192.168.178.21
CPU: Pentium(R) Dual-Core CPU E5700 @ 3.00GHz
Speicher: 2061832 kB
Festplatte(n): OCZ-AGILITY3
Grafikkarte: NVIDIA GeForce 210
Soundkarte: Intel 82801G (ICH7 Family) High Definition Audio Controller
TV-Karte(n): Terratec Cinergy C (VP-2033) BT878 BT878 BT878 BT878

kls · 14. Oktober 2012

Zitat von Copperhead

Naja, gut ist relativ.

Bei 1080i Aufnahmen (speziell HD+) gibt es oft eine ziemlich heftige Klötzchenbildung an den Schnittstellen.

Und bevor es wieder heißt softhddevice ist schuld. Ich hatte das auch schon zu der Zeit, wo ich noch die S2-6400 benutzt habe.

Das ist aber ein ganz anderes Thema!
Daß VDR beim Schneiden etwas "brutal" vorgeht und mancher Player dadurch vielleicht etwas durcheinanderkommt, das ist eine Sache.
Hier geht es aber doch darum, die Grenzen zwischen den Video-Frames zu erkennen. Und das geht, finde ich, schon recht gut.
Zumindest sind mir in letzter Zeit keine Streams mehr untergekommen, bei denen kein Index erzeugt werden konnte oder das verschieben der Schnittmarken mit Darstellung des jeweiligen Bildes nicht geklappt hätte.
Einzig bei der Wiedergabe einer Aufnahme von BBC HD läuft die Zeitanzeige etwas zu schnell. Woran das liegt habe ich bisher aber noch nicht herausgefunden....

Klaus

P.S.: ceterum censeo HD+ esse delendam

kls · 14. Oktober 2012

Zitat von MFG

vdr (1.7.21/1.7.21) - The Video Disk Recorder

Da würde ich dir aber dringend empfehlen, erstmal auf die aktuelle Developer-Version zu gehen.
Seit Version 1.7.21 hat es gerade in der Ecke einige Fixes gegeben.

Klaus

geronimo · 14. Oktober 2012

Zitat

Bei 1080i Aufnahmen (speziell HD+) gibt es oft eine ziemlich heftige Klötzchenbildung an den Schnittstellen.

Hm, ich vermute mal, die Artefackte haste nach dem Schnitt.
Das wäre dann aber ein anderes Thema, denn das hat mit den Schnittmarken von markad wenich zu tun.
Das der Schnitt nicht sonderlich gut funzt ist bekannt und darüber gibt es etliche Freds.

Zitat

Indiz, oft ist der index offentsichlich falsch, hier mit 257' in Aufzeichnungen angezeigt, aber in den die marks realen Zeiten sihe unten.

Hm, das waage ich jetzt mal ganz frech zu bestreiten.
Witzigerweise hat mich die von Dir zitierte Aufnahme dazu gebracht, mich zu dem Thema mal zu melden.

Ack ja - warum ich das mit dem Index bezweifle?

Ich schnitze gerade an einem streaming-server, der auch ungeschnittene VDR-Aufnahmen richtig streamt. Dazu muss ich natürlich die Schnittmarken genauso umrechnen, wie es der VDR tut. Jetzt kam es schon öfters bei mir zu Ungereimtheiten, sodass ich den Index neu erzeugen ließ. Ein diff zeigte mir aber jedesmal, dass der neue Index identisch mit dem alten war.
Nach einigem Suchen habe ich dann wieder einen Fehler bei mir gefunden.
Deshalb gehe ich jetzt einfach mal davon aus, dass der Index vom VDR stimmt.

Bei einer geschnittenene Tara-Aufnahme (auch HD) kam ich auch wieder ins Zweifeln.
Bislang hatte ich es so gehalten, dass ich bei Aufnahmen ohne Schnittmarken jeweils die erste und letzte Index-Position als Schnittmarke rausziehe.
Bei der Kontrolle des Streaming-Servers fand ich raus, dass die Schnittmarken von VDR nach dem Schnitt nicht den ersten und letzten Positionen entsprechen. Dachte schon, da wäre was falsch, aber bei der Wiedergabe zeigte sich, dass per Streaming das gleiche abgespielt wurde, wie wenn ich den VDR zum Abspielen verwende.
Sprich - die Schnittmarken haben gepasst - auch wenn die Indexdatei noch weitere Einträge enthielt.

Gruß Gero

Joe_D · 14. Oktober 2012

Zitat von kls

Und das beantwortet jetzt die Frage, was genau an der VDR Framezählung "selten dämlich" ist, in welcher Weise?

Na gut, anders formuliert: Die I-Frames werden durch Daten aus dem Stream erkannt was auch bei mir zu 100% funktioniert:

Code

if (scanner == 0x00000109) { // Access Unit Delimiter
                               scanner = EMPTY_SCANNER;
                               if (synced && !SeenPayloadStart && Processed)
                                  return Processed; // flush everything before this new frame
                               SeenAccessUnitDelimiter = true;
                               }
                            else if (SeenAccessUnitDelimiter && scanner == 0x00000001) { // NALU start
                               SeenAccessUnitDelimiter = false;
                               int FrameTypeOffset = i + 1;
                               if (FrameTypeOffset >= TS_SIZE) // the byte to check is in the next TS packet
                                  i = SkipPackets(Data, Length, Processed, FrameTypeOffset);
                               newFrame = true;
                               uchar FrameType = Data[FrameTypeOffset] & 0x1F;
                               independentFrame = FrameType == 0x07;

Alles anzeigen

Obwohl die Benennung der Variablen nicht passt: FrameTypeOffset zeigt nicht auf FrameType, sondern FrameTypeOffset ist eher ein NextNALUOffset und FrameType müsste NALUType heissen, denn es wird geprüft ob im anschließenden NALU-Paket ein NAL_SPS (Sequence Parameter Set) vorkommt.

Im Anschluss dazu wird dann aber nur hin- und hergetoggled (wozu eigentlich? - warum nicht einfach jeden gefundenen NALU-AUD in den Index schreiben?) ohne Bezug auf irgendwelche Stream-Daten:

Code

if (synced) {
                                  if (framesPerPayloadUnit < 0) {
                                     payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit;
                                     if (payloadUnitOfFrame != 0 && independentFrame)
                                        payloadUnitOfFrame = 0;
                                     if (payloadUnitOfFrame)
                                        newFrame = false;
                                     }
                                  if (framesPerPayloadUnit <= 1)
                                     scanning = false;
                                  }
                               else {
                                  framesInPayloadUnit++;
                                  if (independentFrame)
                                     numIFrames++;
                                  if (numIFrames == 1)
                                     numFrames++;
                                  dbgframes("%02X ", FrameType);
                                  }
                               if (synced)
                                  return Processed + TS_SIZE; // flag this new frame
                               }

Alles anzeigen

Zitat von kls

Versteh' mich bitte nicht falsch. Ich will nicht behaupten, daß VDR alles richtig macht, was die Frame-Erkennung angeht. Aber es scheint ja (inzwischen) doch recht gut zu funktionieren, und das ohne in die Daten allzu "tief" hineinzuschauen. Insbesondere verwendet VDR keine Library, die das ganze Gedöns total "aufdröselt". Ich bin der Meinung, die Frame-Grenzen müssen auf einer relativ weit "außen" liegenden Ebene erkennbar sein.

Ich verwende dazu auch nur eine erweiterte cBitStream-Klasse...

Gruß

Joe_D

MFG · 14. Oktober 2012

Moin moin geronimo,

würde gerne eingrenzen ob es primär ein dvb-c oder gar KDG Problem ist.

Da Usermeldungen zu nicht schieb/löschbaren Schnittmarken sehr rar, im easyVDR-Forum 0 und hier ist dieser der erste Fred der mir auffiel.

MfG.
...............MFG.

Probleme mit Schnittmarken

Jetzt mitmachen!

Teilen