Neue Schnittfunktion in VDR 1.7.32

kls · 25. November 2012

Zitat von S:oren

Das scheint noch nicht alles zu sein, es gibt noch ein kurzes Stocken in der Wiedergabe nach der Schnittstelle.
Eine weitere Idee: Beim Cut-In werden ja die B-Frames nach dem I-Frame "rausgeschossen". Fuer den PTS macht das nichts, weil der ja auch im rausgeschnittenen Bereich liegt. Der DTS der rausgeschossenen Frames liegt aber nach dem DTS des I-Frame, somit muss der DTS des ersten nicht geloeschten Frames auf den Wert des ersten rausgeschossenen B-Frames gepatcht werden. Ohne diese Korrektur kann es im Extremfall sogar soweit kommen, dass der DTS eines Frames nach seinem PTS liegt, worauf - wie ich gehoert habe - insbesondere Macs extrem allergisch reagieren.

Es werden aber doch alle PTS-, DTS- und PCR-Werte um den berechneten Offset verschoben. Somit kann es doch gar nicht vorkommen, daß der DTS eines Frames nach seinem PTS liegt, denn wenn DTS < PTS gilt, dann gilt auch DTS + x < PTS + x.
Oder übersehe ich da was?

Klaus

kls · 25. November 2012

Zitat von Copperhead

@Klaus: Liegt bei Sigi. Der Film heißt "The Warrior's Way"

Hab's mir geholt.
Die Artefakte an der Schnittstelle sehe ich hier auch, trotz der jüngsten Änderung, daß keine Video-Pakete am Schnitt-Ende reingezogen werden (siehe hier).
Momentan habe ich leider keine Idee, woran das liegen könnte...

Klaus

S:oren · 25. November 2012

Zitat von kls

Es werden aber doch alle PTS-, DTS- und PCR-Werte um den berechneten Offset verschoben. Somit kann es doch gar nicht vorkommen, daß der DTS eines Frames nach seinem PTS liegt, denn wenn DTS < PTS gilt, dann gilt auch DTS + x < PTS + x.
Oder übersehe ich da was?

OK, meine erste Diagnose war wohl nicht ganz richtig. Aber es gibt doch ein Problem, siehe folgendes Beispiel:

Code

Sequenz: P   B   B [Cut]  I   B   B   P   B   B
DTS      0   1   2       101 102 103 104 105 106
PTS      4   2   3       105 103 104 108 106 107
nach dem Schneiden mit Korrektur (X: geloeschte Frames):
DTS      0   1   2        1   X   X   4   5   6
PTS      4   2   3        5   X   X   8   6   7

Der DTS des I-Frames beim Cut-In laeuft rueckwaerts, liegt also einen Timer-Wrap-Around in der Zukunft.

Edit: Es muss also der DTS des I-Frames um die Dauer der herausgeschnittenen B-Frames korrigiert werden, im Beispiel also auf 3. Dann stimmt alles.

Die Anzahl der B-Frames ist nur als Beispiel zu verstehen, ebenso die Anzahl der herausgeschnittenen Frames. Die Timestamps sind natuerlich als Vielfache der Frame-Zeit zu verstehen, mit beliebigem Offset.

Gruss,
S:oren

kls · 26. November 2012

Zitat von kls

Hab's mir geholt.
Die Artefakte an der Schnittstelle sehe ich hier auch, trotz der jüngsten Änderung, daß keine Video-Pakete am Schnitt-Ende reingezogen werden (siehe hier).
Momentan habe ich leider keine Idee, woran das liegen könnte...

Auf einen Fehler in cMarks::GetNumSequences() bin ich bei den Untersuchungen gestoßen:

Diff

--- recording.c 2012/11/19 10:01:01     2.74
+++ recording.c 2012/11/26 09:39:59     2.75
@@ -1498,8 +1498,11 @@
            NumSequences++;
            BeginMark = GetNextBegin(EndMark);
            }
-     if (NumSequences == 0 && BeginMark->Position() > 0)
-        NumSequences = 1; // there is only one actual "begin" mark at a non-zero offset, and no actual "end" mark
+     if (BeginMark) {
+        NumSequences++; // the last sequence had no actual "end" mark
+        if (NumSequences == 1 && BeginMark->Position() == 0)
+           NumSequences = 0; // there is only one actual "begin" mark at offset zero, and no actual "end" mark
+        }
      }
   return NumSequences;
 }

Alles anzeigen

Bei "offenem Ende" wurde die Zahl der Sequenzen nicht richtig berechnet.
Diese Änderung behebt allerdings noch nicht das eigentliche Problem - aber da verfolge ich jetzt den Hinweis von "S:oren" aus Posting 43...

Klaus

nvertigo · 26. November 2012

Hallo,

ich finde die neue Schnittfunktion inf Bezug auf Artefakte merkbar besser, als die alte.

Ich habe hier aber ein kleines Problem, vieleicht hift das ja:

Ich wandele HD-Aufnahmen mit Handbrake für mein tf101. Aufruf:

Code

Wenn ich jedoch mit der neuen Schnittfunktion eine ZDF HD (also 720p) so schneide, dass nicht nur am Anfang und am Ende etwas weggeschnitten wird, sondern auch Werbung in der Mitte entferne, dann erzeugt Hanbrake eine Ausgabe, die ab dem Schnitt unbrauchbar ist (die unteren 2/3 des Bildes sind verzerrt und verpixelt). Schneide ich nur Am Anfang und am Ende funktioniert es gut. Handbrake erzeugt dabi folgen Fehler:

Code

[13:39:10] hb_init: starting libhb thread
HandBrake rev0 (2012112499) - Linux x86_64 - http://handbrake.fr
8 CPUs detected
Opening /mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts...
[13:39:10] hb_scan: path=/mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts, title_index=1
libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts/BDMV/index.bdmv
libbluray/bdnav/index_parse.c:162: indx_parse(): error opening /mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts/BDMV/BACKUP/index.bdmv
libbluray/bluray.c:1725: nav_get_title_list(/mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts) failed (0x7f9c2c000900)
[13:39:10] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 4.1.3
libdvdread: Using libdvdcss version 1.2.12 for DVD access
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdnav:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[13:39:10] dvd: not a dvd - trying as a stream/file instead
[13:39:10] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[13:39:10] Found the following PIDS
[13:39:10]     Video PIDS :
[13:39:10]       0x17de type H.264 (0x1b) (PCR)
[13:39:10]     Audio PIDS :
[13:39:10]       0x17e8 type MPEG1 (0x3)
[13:39:10]       0x17e9 type MPEG1 (0x3)
[13:39:10]       0x17eb type MPEG1 (0x3)
[13:39:10]       0x17ea type AC3 (0x81)
[13:39:10]     Subtitle PIDS :
[13:39:10]     Other PIDS :
[13:39:10]       0x17f3 type DVB Subtitling (0x0)
[13:39:10] stream id 0x17e8 (type 0x3 substream 0x0) audio 0x17e8
[13:39:10] stream id 0x17e9 (type 0x3 substream 0x0) audio 0x17e9
[13:39:10] stream id 0x17eb (type 0x3 substream 0x0) audio 0x17eb
[13:39:10] stream id 0x17ea (type 0x81 substream 0x0) audio 0x17ea
[13:39:12] scan: decoding previews for title 1
[13:39:12] scan: audio 0x17e9: mp2, rate=48000Hz, bitrate=192000 Unknown (MPEG1) (2.0 ch)
[13:39:12] scan: audio 0x17eb: mp2, rate=48000Hz, bitrate=192000 Unknown (MPEG1) (2.0 ch)
[13:39:12] scan: audio 0x17e8: mp2, rate=48000Hz, bitrate=256000 Deutsch (MPEG1) (2.0 ch)
[13:39:12] scan: audio 0x17ea: AC-3, rate=48000Hz, bitrate=448000 Deutsch (AC3) (2.0 ch)
Scanning title 1...
[13:39:12] stream: error near frame 1: continuity error: got 1 expected 0
[13:39:12] stream: error near frame 4: continuity error: got 5 expected 4
[13:39:12] stream: error near frame 1: continuity error: got 2 expected 1
[13:39:12] stream: error near frame 3: continuity error: got 15 expected 14
[13:39:12] stream: error near frame 4: continuity error: got 15 expected 14
[13:39:12] stream: error near frame 3: continuity error: got 7 expected 6
Scanning title 1...
[13:39:12] scan: 10 previews, 1280x720, 50.000 fps, autocrop = 2/0/0/0, aspect 16:9, PAR 1:1
[13:39:12] stream: 21 good frames, 8 errors (38%)
[13:39:12] libhb: scan thread found 1 valid title(s)
+ title 1:
  + stream: /mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts
  + duration: 00:02:04
  + size: 1280x720, pixel aspect: 1/1, display aspect: 1.78, 50.000 fps
  + autocrop: 2/0/0/0
  + chapters:
    + 1: cells 0->0, 0 blocks, duration 00:02:04
  + audio tracks:
    + 1, Deutsch (MPEG1) (2.0 ch) (iso639-2: deu)
    + 2, Unknown (MPEG1) (2.0 ch) (iso639-2: und)
    + 3, Unknown (MPEG1) (2.0 ch) (iso639-2: und)
    + 4, Deutsch (AC3) (2.0 ch) (iso639-2: deu), 48000Hz, 448000bps
  + subtitle tracks:
[13:39:12] 1 job(s) to process
[13:39:12] starting job
[13:39:12] sync: expecting 6203 video frames
[13:39:12] work: only 1 chapter, disabling chapter markers
[13:39:12] job configuration:
[13:39:12]  * source
[13:39:12]    + /mnt/rock//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.ts
[13:39:12]    + title 1, chapter(s) 1 to 1
[13:39:12]  * destination
[13:39:12]    + /mnt/export/video/tf101-transcoded//video/SOKO_Wien/sache/2012-10-05.18.05.2-0.rec/00001.m4v
[13:39:12]    + container: MPEG-4 (.mp4 and .m4v)
[13:39:12]      + 64-bit formatting
[13:39:12]  * video track
[13:39:12]    + decoder: h264
[13:39:12]      + bitrate 200 kbps
[13:39:12]    + frame rate: 50.000 fps -> constant 25.000 fps
[13:39:12]    + filters
[13:39:12]      + Framerate Shaper (1:27000000:1080000)
[13:39:12]        + frame rate: 25.000 fps -> constant 25.000 fps
[13:39:12]      + Crop and Scale (1280:720:0:0:0:0)
[13:39:12]        + source: 1280 * 720, crop (0/0/0/0): 1280 * 720, scale: 1280 * 720
[13:39:12]    + loose anamorphic
[13:39:12]      + storage dimensions: 1280 * 720, mod 16
[13:39:12]      + pixel aspect ratio: 1 / 1
[13:39:12]      + display dimensions: 1280 * 720
[13:39:12]    + encoder: H.264 (x264)
[13:39:12]      + options: cabac=0:bframes=0:weightp=0:8x8dct=0:ref=4:deblock=-2,-1:mixed-refs=0:analyse=some:trellis=1:subq=7
[13:39:12]      + quality: 22.00 (RF)
[13:39:12]  * audio track 1
[13:39:12]    + decoder: Deutsch (MPEG1) (2.0 ch) (track 1, id 0x17e8)
[13:39:12]      + bitrate: 256 kbps, samplerate: 48000 Hz
[13:39:12]    + mixdown: Stereo
[13:39:12]    + encoder: AAC (faac)
[13:39:12]      + bitrate: 128 kbps, samplerate: 44100 Hz
[13:39:12] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[13:39:12] reader: first SCR 5406195530 id 0x17de DTS 5406237784
[13:39:12] encx264: encoding with stored aspect 1/1
[13:39:12] encx264: Encoding at constant RF 22.000000
x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX XOP FMA4 SSEMisalign LZCNT
x264 [info]: profile Constrained Baseline, level 3.1
[13:39:13] h264: Chapter 1 at frame 0 time 3600
[13:39:13] sync: first pts is 3600
[13:39:13] sync: adding 70 ms of silence to audio 0x17e8  start 8438, next 2065
Encoding: task 1 of 1, 27.29 % (184.08 fps, avg 183.20 fps, ETA 00h00m25s)[13:39:22] stream: error near frame 1763: continuity error: got 14 expected 13
[h264 @ 0x7f9c1c0c8120] left block unavailable for requested intra4x4 mode -1 at 0 28
[h264 @ 0x7f9c1c0c8120] error while decoding MB 0 28, bytestream (-1)
[h264 @ 0x7f9c1c0c8120] concealing 1409 DC, 1409 AC, 1409 MV errors
Encoding: task 1 of 1, 28.94 % (183.73 fps, avg 183.19 fps, ETA 00h00m24s)[13:39:22] sync: video time didn't advance - dropped 6 frames (delta 100 ms, current 3243600, next 3245399, dur 1799)
Encoding: task 1 of 1, 30.65 % (183.73 fps, avg 183.19 fps, ETA 00h00m24s)[h264 @ 0x7f9c1c0c8120] concealing 3489 DC, 3489 AC, 3489 MV errors
Encoding: task 1 of 1, 31.37 % (176.51 fps, avg 182.20 fps, ETA 00h00m23s)[h264 @ 0x7f9c1c06e680] left block unavailable for requested intra4x4 mode -1 at 0 4
[h264 @ 0x7f9c1c06e680] error while decoding MB 0 4, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 3329 DC, 3329 AC, 3329 MV errors
Encoding: task 1 of 1, 32.10 % (176.51 fps, avg 182.20 fps, ETA 00h00m23s)[h264 @ 0x7f9c1c06e680] cabac decode of qscale diff failed at 32 16
[h264 @ 0x7f9c1c06e680] error while decoding MB 32 16, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 2337 DC, 2337 AC, 2337 MV errors
[h264 @ 0x7f9c1c06e680] left block unavailable for requested intra mode at 0 29
[h264 @ 0x7f9c1c06e680] error while decoding MB 0 29, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 1329 DC, 1329 AC, 1329 MV errors
[h264 @ 0x7f9c1c06e680] left block unavailable for requested intra mode at 0 22
[h264 @ 0x7f9c1c06e680] error while decoding MB 0 22, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 1889 DC, 1889 AC, 1889 MV errors
Encoding: task 1 of 1, 34.27 % (166.99 fps, avg 178.78 fps, ETA 00h00m23s)[h264 @ 0x7f9c1c17b7a0] left block unavailable for requested intra mode at 0 17
[h264 @ 0x7f9c1c17b7a0] error while decoding MB 0 17, bytestream (-1)
[h264 @ 0x7f9c1c17b7a0] concealing 2289 DC, 2289 AC, 2289 MV errors
[h264 @ 0x7f9c1c06e140] cabac decode of qscale diff failed at 19 2
[h264 @ 0x7f9c1c06e140] error while decoding MB 19 2, bytestream (-1)
[h264 @ 0x7f9c1c06e140] concealing 3470 DC, 3470 AC, 3470 MV errors
[h264 @ 0x7f9c1c06e680] cabac decode of qscale diff failed at 9 36
[h264 @ 0x7f9c1c06e680] error while decoding MB 9 36, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 760 DC, 760 AC, 760 MV errors
[h264 @ 0x7f9c1c17b7a0] concealing 228 DC, 228 AC, 228 MV errors
Encoding: task 1 of 1, 35.00 % (166.99 fps, avg 178.78 fps, ETA 00h00m23s)[h264 @ 0x7f9c1c17b7a0] cabac decode of qscale diff failed at 20 34
[h264 @ 0x7f9c1c17b7a0] error while decoding MB 20 34, bytestream (-1)
[h264 @ 0x7f9c1c17b7a0] concealing 909 DC, 909 AC, 909 MV errors
Encoding: task 1 of 1, 39.35 % (150.85 fps, avg 174.88 fps, ETA 00h00m21s)[h264 @ 0x7f9c1c0c8120] concealing 3150 DC, 3150 AC, 3150 MV errors
Encoding: task 1 of 1, 40.08 % (150.85 fps, avg 174.88 fps, ETA 00h00m21s)[h264 @ 0x7f9c1c06e140] concealing 1899 DC, 1899 AC, 1899 MV errors
Encoding: task 1 of 1, 40.80 % (150.85 fps, avg 174.88 fps, ETA 00h00m21s)[h264 @ 0x7f9c1c17b7a0] concealing 1866 DC, 1866 AC, 1866 MV errors
[h264 @ 0x7f9c1c121c60] concealing 450 DC, 450 AC, 450 MV errors
Encoding: task 1 of 1, 41.53 % (151.09 fps, avg 172.77 fps, ETA 00h00m21s)[h264 @ 0x7f9c1c17b7a0] cabac decode of qscale diff failed at 53 30
[h264 @ 0x7f9c1c17b7a0] error while decoding MB 53 30, bytestream (-1)
[h264 @ 0x7f9c1c17b7a0] concealing 1196 DC, 1196 AC, 1196 MV errors
Encoding: task 1 of 1, 45.40 % (151.32 fps, avg 171.56 fps, ETA 00h00m20s)[h264 @ 0x7f9c1c06e680] left block unavailable for requested intra4x4 mode -1 at 0 18
[h264 @ 0x7f9c1c06e680] error while decoding MB 0 18, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 2209 DC, 2209 AC, 2209 MV errors
Encoding: task 1 of 1, 45.88 % (151.32 fps, avg 171.56 fps, ETA 00h00m20s)[h264 @ 0x7f9c1c17b7a0] concealing 2209 DC, 2209 AC, 2209 MV errors
[h264 @ 0x7f9c1c06e140] cabac decode of qscale diff failed at 37 20
[h264 @ 0x7f9c1c06e140] error while decoding MB 37 20, bytestream (-1)
[h264 @ 0x7f9c1c06e140] concealing 2012 DC, 2012 AC, 2012 MV errors
[h264 @ 0x7f9c1c06e680] cabac decode of qscale diff failed at 51 18
[h264 @ 0x7f9c1c06e680] error while decoding MB 51 18, bytestream (-1)
[h264 @ 0x7f9c1c06e680] concealing 2158 DC, 2158 AC, 2158 MV errors
Encoding: task 1 of 1, 47.57 % (151.47 fps, avg 170.46 fps, ETA 00h00m19s)[h264 @ 0x7f9c1c121c60] concealing 1809 DC, 1809 AC, 1809 MV errors
Encoding: task 1 of 1, 49.02 % (151.66 fps, avg 169.02 fps, ETA 00h00m18s)[h264 @ 0x7f9c1c17b7a0] left block unavailable for requested intra mode at 0 23
[h264 @ 0x7f9c1c17b7a0] error while decoding MB 0 23, bytestream (0)
[h264 @ 0x7f9c1c17b7a0] concealing 1809 DC, 1809 AC, 1809 MV errors

Alles anzeigen

Ich denke, das Muster der Fehler ist erkennbar, Ich kann bei Bedarf noch megabyteweise mehr davon liefern ( ), denn das geht bis zum Ende so weiter. Hoffe es hilft.

Gruß, Ingo

kls · 26. November 2012

Zitat von nvertigo
Hallo,

ich finde die neue Schnittfunktion inf Bezug auf Artefakte merkbar besser, als die alte.

Ich habe hier aber ein kleines Problem, vieleicht hift das ja:

Ich wandele HD-Aufnahmen mit Handbrake für mein tf101. Aufruf:
Code
Alles anzeigen

Was vergessen?

Zitat

Wenn ich jedoch mit der neuen Schnittfunktion eine ZDF HD (also 720p) so schneide, dass nicht nur am Anfang und am Ende etwas weggeschnitten wird, sondern auch Werbung in der Mitte entferne, dann erzeugt Hanbrake eine Ausgabe, die ab dem Schnitt unbrauchbar ist (die unteren 2/3 des Bildes sind verzerrt und verpixelt). Schneide ich nur Am Anfang und am Ende funktioniert es gut.

Wenn nur am Anfang und/oder Ende was weggeschnitten wird, dann fasst VDR die Timestamps etc. nicht an, daher gibt es in dem Fall kein Problem.

Zitat

Handbrake erzeugt dabi folgen Fehler:

Code

[13:39:10]...
[13:39:12] stream: error near frame 1: continuity error: got 1 expected 0
[13:39:12] stream: error near frame 4: continuity error: got 5 expected 4
[13:39:12] stream: error near frame 1: continuity error: got 2 expected 1
[13:39:12] stream: error near frame 3: continuity error: got 15 expected 14
[13:39:12] stream: error near frame 4: continuity error: got 15 expected 14
[13:39:12] stream: error near frame 3: continuity error: got 7 expected 6

Probier's bitte mal hiermit:

Diff

--- cutter.c    2012/11/25 13:59:07     2.18
+++ cutter.c    2012/11/26 17:21:14
@@ -210,7 +210,8 @@
            }
         // Adjust the TS continuity counter:
         if (fixCounters) {
-           counter[Pid] = (counter[Pid] + 1) & TS_CONT_CNT_MASK;
+           if (TsHasPayload(p))
+              counter[Pid] = (counter[Pid] + 1) & TS_CONT_CNT_MASK;
            TsSetContinuityCounter(p, counter[Pid]);
            }
         else

Alles anzeigen

Zitat

Code

[13:39:22] stream: error near frame 1763: continuity error: got 14 expected 13
[h264 @ 0x7f9c1c0c8120] left block unavailable for requested intra4x4 mode -1 at 0 28
[h264 @ 0x7f9c1c0c8120] error while decoding MB 0 28, bytestream (-1)
[h264 @ 0x7f9c1c0c8120] concealing 1409 DC, 1409 AC, 1409 MV errors
...

Woher diese Fehler kommen, kann ich mir nicht erklären. Vielleicht eine Folge des continuity errors?
Probier mal den Patch und sag Bescheid, ob damit auch die anderen Fehlermeldungen weg sind.

Klaus

nvertigo · 26. November 2012

...ja, da war das Sende-Fingerchen schneller als der Kopf...

Code

HandBrakeCLI -i $i  -o $DESTDIR/$(basename $i ts)m4v  -e x264 -q 22.0 -a 1 -E faac -B 128 -6 stereo -R 44.1 -D 2.8 -f mp4 --loose-anamorphic --modulus 16 -m -x cabac=0:bframes=0:weightp=0:8x8dct=0:ref=4:deblock=-2,-1:mixed-refs=0:analyse=some:trellis=1:subq=7 -r 25 -w 1280 -X 1280 -Y 720 --crop autocrop --large-file

$i kommt aus einer Schleife - das sind die .ts Dateien.

Vielen Dank für den Patch - nach einem ersten schnellen Test scheint es zu funtionieren. Und Du hattest Recht: der Rest sind Folgefehler. Der Schnelltest ist ohne Fehler durchgelaufen, und das Ergebnis sieht wieder schick aus.

Gruß, Ingo

kls · 29. November 2012

Zitat von S:oren
...Aber es gibt doch ein Problem, siehe folgendes Beispiel:
Code
Sequenz: P   B   B [Cut]  I   B   B   P   B   B
DTS      0   1   2       101 102 103 104 105 106
PTS      4   2   3       105 103 104 108 106 107
nach dem Schneiden mit Korrektur (X: geloeschte Frames):
DTS      0   1   2        1   X   X   4   5   6
PTS      4   2   3        5   X   X   8   6   7
Der DTS des I-Frames beim Cut-In laeuft rueckwaerts, liegt also einen Timer-Wrap-Around in der Zukunft.

Edit: Es muss also der DTS des I-Frames um die Dauer der herausgeschnittenen B-Frames korrigiert werden, im Beispiel also auf 3. Dann stimmt alles.

Die Anzahl der B-Frames ist nur als Beispiel zu verstehen, ebenso die Anzahl der herausgeschnittenen Frames. Die Timestamps sind natuerlich als Vielfache der Frame-Zeit zu verstehen, mit beliebigem Offset.
Alles anzeigen

Der beiliegende Patch (gegen die Version 1.7.32, enthält auch einige andere notwendige Fixes) sollte jetzt die DTS-Werte richtig setzen.
Wenn ich eine damit geschnittene Aufnahme mit Kaffeine abspiele, dann bekomme ich absolut saubere Schnittstellen (weder Video- noch Audio-Artefakte, sowohl SD als auch HD 720p).
Mit der TT S2-6400 gibt es in der HD-Aufnahme an der Schnittstelle noch Verpixelungen, der Ton ist OK. Die SD-Aufnahme wird auch auf der 6400 störungsfrei abgespielt.
Der Mac-Player macht es jetzt in beiden Fällen gefühlt etwas besser, stottert und verschluckt sich aber immer noch heftig, und bleibt manchmal ganz hängen.

Bitte schau dir das mal an und laß mich wissen, ob dir sonst noch was an den Schnittergebnissen auffällt, das für die Störungen verantwortlich sein könnte. Mein nächster Verdacht ist ja, daß die PCR-Werte noch nicht ganz astrein sind...

Klaus

S:oren · 29. November 2012

Zitat von kls

Bitte schau dir das mal an und laß mich wissen, ob dir sonst noch was an den Schnittergebnissen auffällt, das für die Störungen verantwortlich sein könnte. Mein nächster Verdacht ist ja, daß die PCR-Werte noch nicht ganz astrein sind...

Habe es mal schnell ausprobiert, nur mit MPEG-2-Material. Das ist auf jeden Fall ein gigantischer Fortschritt, auf der S2-6400 komplett ohne Artefakte. Ich bin begeistert!!
Ich schau nochmal weiter, ob mir irgendwas auffaellt...
Gruss,
S:oren

jsffm · 30. November 2012

Habe gerade eine Aufzeichnung von RTL HD geschnitten, die ich vor dem Patch aufgezeichnet hatte. Markierungen, die vor dem Patch gesetzt waren müssen neu gesetzt werden bzw. neu verschoben werden. Das Ergebnis sieht sehr gut aus, aber das war es teilweise auch vorher, daher müssen weitere Tests folgen.

jsffm · 30. November 2012

Ich habe mal gerade eine ältere Aufzeichnung von RTL II HD genommen, die schlechte Schnittübergänge hatte, Marken jeweils mal zur Seite und wieder hingeschoben, Schnitt neu gestartet, Ergebnis: deutlich sauberere Schnitte.

jsffm · 30. November 2012

Zitat von jsffm

Ich habe mal gerade eine ältere Aufzeichnung von RTL II HD genommen, die schlechte Schnittübergänge hatte, Marken jeweils mal zur Seite und wieder hingeschoben, Schnitt neu gestartet, Ergebnis: deutlich sauberere Schnitte.

funktioniert leider nicht immer, aber immer öfter auch index neu generieren hilft hier nicht immer.

Dirk · 30. November 2012

Falls jemand hier Beiträge vermisst, die sind jetzt dort -> Plugin-Patches für vdr-1.7.32

jsffm · 30. November 2012

gelöscht.

Dirk · 30. November 2012

war ein versehen! habs zurück verschoben

S:oren · 2. Dezember 2012

Zitat von kls

Mein nächster Verdacht ist ja, daß die PCR-Werte noch nicht ganz astrein sind...

Hatte leider wenig Zeit, mir das alles im Detail anzusehen. Bisher ist mir nur das hier aufgefallen

Diff

--- cutter.c.orig	2012-12-01 22:28:05.000000000 +0100
+++ cutter.c	2012-12-01 23:15:19.000000000 +0100
@@ -262,7 +262,7 @@ void cPtsFixer::Fix(uchar *Data, int Len
            int64_t Pcr = TsGetPcr(p);
            if (Pcr >= 0) {
               int64_t NewPcr = Pcr + offset * PCRFACTOR;
-              if (NewPcr >= MAX27MHZ)
+              if (NewPcr > MAX27MHZ)
                  NewPcr -= MAX27MHZ + 1;
               TsSetPcr(p, NewPcr);
               }

Alles anzeigen

Allerdings bin ich mir nicht sicher, ob der 90kHz-Offset so einfach auf den 27MHz-Offset umgerechnet werden sollte. Waere es nicht besser, den PCR-Offset direkt in voller Genauigkeit zu berechnen?

Den PTS-Offset wuerde ich etwas uebersichtlicher so bestimmen, ist aber nur Kosmetik mit gleichem Ergebnis

Diff

--- cutter.c.orig	2012-12-01 22:28:05.000000000 +0100
+++ cutter.c	2012-12-01 23:39:13.000000000 +0100
@@ -194,11 +194,7 @@ void cPtsFixer::Fix(uchar *Data, int Len
      int64_t Pts = TsGetPts(Data, Length);
      if (Pts >= 0) {
         // offset is calculated so that Pts + offset results in lastPts + delta:
-        offset = Pts - PtsAdd(lastPts, delta);
-        if (offset <= 0)
-           offset = -offset;
-        else
-           offset = MAX33BIT + 1 - offset;
+        offset = (lastPts + delta - Pts) & MAX33BIT;
         }
      fixCounters = true;
      }

Alles anzeigen

Vielleicht waere es aber insgesamt besser, den PTS- und PCR-Offset direkt aus der Differenz der Werte des I-Frames beim Cut-In und des I-Frames nach dem Cut-Out zu berechnen (ohne delta), dann hat man erstens den exakten 27MHz-Wert fuer PCR und zweitens keine Probleme, wenn nicht jeder Frame einen eigenen PTS im Datenstrom hat. Z.B. auf WDR ueber DVB-T habe ich schon gesehen, dass eine ganze GOP in einem einzigen PES-Paket steckt und deshalb auch nur einen PTS fuer den I-Frame hat - dann klappt es ja mit der Berechnung des lastPts im bisherigen Code nicht so recht. In diesem Fall waere natuerlich auch das Herausschneiden der B-Frames beim Cut-In nicht (so einfach) moeglich, dann sollte man wenigstens (bei MPEG-2) das BrokenLink-Flag setzen. Oder habe ich nur uebersehen, wie der vdr so eine Single-PES-GOP auseinander nimmt?

Edit: Fuer den PTS-Offset klappt es bei geloeschten B-Frames nicht so ganz mit der direkten I-Frame-Differenz, der erste geloeschte B-Frame hat den richtigen Wert. Fuer den PCR-Offeset sollte es aber mit den I-Frames stimmen. Diese unterschiedlichen Offsets bringen vielleicht den Mac-Player durcheinander (bisher wars ja der gleiche Offset).

Gruss,
S:oren

kls · 2. Dezember 2012

Zitat von S:oren

Hatte leider wenig Zeit, mir das alles im Detail anzusehen. Bisher ist mir nur das hier aufgefallen

Diff

--- cutter.c.orig	2012-12-01 22:28:05.000000000 +0100
+++ cutter.c	2012-12-01 23:15:19.000000000 +0100
@@ -262,7 +262,7 @@ void cPtsFixer::Fix(uchar *Data, int Len
            int64_t Pcr = TsGetPcr(p);
            if (Pcr >= 0) {
               int64_t NewPcr = Pcr + offset * PCRFACTOR;
-              if (NewPcr >= MAX27MHZ)
+              if (NewPcr > MAX27MHZ)
                  NewPcr -= MAX27MHZ + 1;
               TsSetPcr(p, NewPcr);
               }

Alles anzeigen

Ein Überlauf hat ja erst dann stattgefunden, wenn NewPcr größer als der maximal mögliche Wert ist. MAX27MHZ ist ja noch ein gültiger Wert.

Zitat

Allerdings bin ich mir nicht sicher, ob der 90kHz-Offset so einfach auf den 27MHz-Offset umgerechnet werden sollte. Waere es nicht besser, den PCR-Offset direkt in voller Genauigkeit zu berechnen?

Der Offset ist ja in ganzzahligen Vielfachen des 90kHz-Taktes, und der wiederum besteht aus Einheiten zu je 300 27MHz-Takten. Also müsste Pcr + offset * PCRFACTOR doch eigentlich genau sein, oder?

Zitat

Den PTS-Offset wuerde ich etwas uebersichtlicher so bestimmen, ist aber nur Kosmetik mit gleichem Ergebnis

Diff

--- cutter.c.orig	2012-12-01 22:28:05.000000000 +0100
+++ cutter.c	2012-12-01 23:39:13.000000000 +0100
@@ -194,11 +194,7 @@ void cPtsFixer::Fix(uchar *Data, int Len
      int64_t Pts = TsGetPts(Data, Length);
      if (Pts >= 0) {
         // offset is calculated so that Pts + offset results in lastPts + delta:
-        offset = Pts - PtsAdd(lastPts, delta);
-        if (offset <= 0)
-           offset = -offset;
-        else
-           offset = MAX33BIT + 1 - offset;
+        offset = (lastPts + delta - Pts) & MAX33BIT;
         }
      fixCounters = true;
      }

Alles anzeigen

Bist du dir da ganz sicher, daß da in allen Fällen das gleiche rauskommt? Das sieht mir fast etwas zu einfach aus (obwohl ich nichts dagegen hätte ;-).

Zitat

Vielleicht waere es aber insgesamt besser, den PTS- und PCR-Offset direkt aus der Differenz der Werte des I-Frames beim Cut-In und des I-Frames nach dem Cut-Out zu berechnen (ohne delta), dann hat man erstens den exakten 27MHz-Wert fuer PCR und zweitens keine Probleme, wenn nicht jeder Frame einen eigenen PTS im Datenstrom hat. Z.B. auf WDR ueber DVB-T habe ich schon gesehen, dass eine ganze GOP in einem einzigen PES-Paket steckt und deshalb auch nur einen PTS fuer den I-Frame hat - dann klappt es ja mit der Berechnung des lastPts im bisherigen Code nicht so recht. In diesem Fall waere natuerlich auch das Herausschneiden der B-Frames beim Cut-In nicht (so einfach) moeglich, dann sollte man wenigstens (bei MPEG-2) das BrokenLink-Flag setzen. Oder habe ich nur uebersehen, wie der vdr so eine Single-PES-GOP auseinander nimmt?

Da hast du nichts übersehen, diesen Fall habe ich noch nicht behandelt (kommt zum Glück eher selten vor, zumindest bei den Kanälen, die ich so schaue).

Zitat

Edit: Fuer den PTS-Offset klappt es bei geloeschten B-Frames nicht so ganz mit der direkten I-Frame-Differenz, der erste geloeschte B-Frame hat den richtigen Wert. Fuer den PCR-Offeset sollte es aber mit den I-Frames stimmen. Diese unterschiedlichen Offsets bringen vielleicht den Mac-Player durcheinander (bisher wars ja der gleiche Offset).

Ich bin momentan am experimentieren mit dem PCR-Offset. Da war auf jeden Fall der gleiche Fehler drin, wie bei den DTS-Werten, daß es eine negative Differenz gab.

Klaus

nvertigo · 2. Dezember 2012

Habe seit Freitag viel mit dem neuen Patch geschnitten. Gefällt mir sehr gut und ich habe kaum noch gepixel. Selbstbwenn es pixelt, tuts das nur noch max. 1.5 Sekunden und nicht bis zu 6 Sekunden mit Einblenden alter Bilder von vor dem Scnitt. Ich galube folgendes beobachtet zu haben, die Verpixlungen treten dann verstärkt auf, wenn es keine Überlappung gibt, und dr Sender an den Schnittstellen das Tonformat ändert - kann aber auch Zufall sein. Ich habe nur mit "frischem" - also mit Patch aufgezeichnetem - Material von 1024i und 720p Kanälen getestet. Bei 720p habe ich keine einzige Verpixlung gehabt (aber da war der Ton auch immer durchgehend Dolby stereo). Bin sehr Zufrieden mit den neuen Schnitten!

Frage: Ich habe hier markad laufen und bearbeite die Schnitte per Hand nach, so dass für die Tests jede einzelne mark min. hin- und her verschoben wurde. Könnte man die markad marks auch direkt vrwenden, oder hebeln die dann die neue Schnitt- und marks-Mimik aus?

Gruß, Ingo

S:oren · 2. Dezember 2012

Zitat von kls

Ein Überlauf hat ja erst dann stattgefunden, wenn NewPcr größer als der maximal mögliche Wert ist. MAX27MHZ ist ja noch ein gültiger Wert.

Ja, deshalb ist >= ja auch falsch und > richtig.

Zitat von kls

Der Offset ist ja in ganzzahligen Vielfachen des 90kHz-Taktes

Gilt das auch bei NTSC-artigen Bildwiederholraten von 60Hz*1000/1001 ?

Zitat von kls

Bist du dir da ganz sicher, daß da in allen Fällen das gleiche rauskommt?

Ja, Zweierkomplement-Additionen und -Subtraktionen gehen mit beliebiger Bitbreite, solange das Ergebnis die gleiche Bitbreite wie die Summanden hat. Beim PCR-Offset ist es schwieriger, da die Bits dort ja nicht "vollstaendig" benutzt werden.

Zitat von kls

Da hast du nichts übersehen, diesen Fall habe ich noch nicht behandelt (kommt zum Glück eher selten vor, zumindest bei den Kanälen, die ich so schaue).

Ja, schon daemlich, aber WDR ueber DVB-T macht sowas (hat zumindest, hab nicht nochmal aktuell getestet).

Zitat von kls

Ich bin momentan am experimentieren mit dem PCR-Offset. Da war auf jeden Fall der gleiche Fehler drin, wie bei den DTS-Werten, daß es eine negative Differenz gab.

Das bringt wahrscheinlich den Mac durcheinander, "normale" Player duerften sich eher selten fuer PCR interessieren...

Gruss,
S:oren

kls · 2. Dezember 2012

Zitat von S:oren

Ja, deshalb ist >= ja auch falsch und > richtig.

O, sorry, ich dachte, du hättest aus meinem Patch zitiert (irgendwie war ich der Meinung, das schon geändert zu haben ;-).
Aber möglicherweise werde ich an der Stelle sowieso noch einiges ändern müssen...

Zitat

Gilt das auch bei NTSC-artigen Bildwiederholraten von 60Hz*1000/1001 ?

Mir ist zumindest nichts anderes bekannt.

Zitat

Ja, Zweierkomplement-Additionen und -Subtraktionen gehen mit beliebiger Bitbreite, solange das Ergebnis die gleiche Bitbreite wie die Summanden hat.

OK, dann werde ich das so ändern.

Zitat

Beim PCR-Offset ist es schwieriger, da die Bits dort ja nicht "vollstaendig" benutzt werden.

Da muß man halt mit Division und Rest arbeiten...

Klaus

Neue Schnittfunktion in VDR 1.7.32

Jetzt mitmachen!

Teilen