Richtiger Endpunkt berücksichtigt? ("Schnitt oder Schnit"?)

  • Über das letzte Jahr hatte ich Gelegenheit, die verschiedensten VDR-Versionen zu testen und etwa 100 GB zu schneiden - aktuell verwende ich HelAu's Gen2VDR-1.0-rc3.

    Immer wieder fällt mir schon seit einigen VDR-Versionen beim Schneiden folgendes auf:

    Markiert man nach Druck auf OK während der Wiedergabe einen Schnittbereich mit der Taste 0 und schiebt die Start- und Endmarken mit 4&6 an die richtige Stelle, so wird nach Start des Schneidens mit 2 die Aufnahme oft so geschnitten, daß ein am Ende abhacktes Resultat entsteht, obwohl in der Quelldatei das als Endpunkt des Schnittbereichs ausgewählte Bild völlig korrekt bereits unmittelbar nach dem Ende der zu erhaltenden Aufnahme liegt.

    Mir fehlt jetzt die Codekenntnis, um das in den VDR-Sourcen nachzuvollziehen, aber anhand des Effekts vermute ich mal, daß folgendes passiert und zu berichtigen wäre:

    Wahrscheinlich ist die Schrittweite für die Markierung mit 4&6 jeweils 1 I-Frame (?)
    Dann darf der Schnitt aber nicht einen I-Frame vor dem markierten Frame enden, sondern muß entweder (sozusagen als "Hotfix") bis zum markierten I-Frame (also "1 Bild zu weit") gehen oder aber (ganz korrekt) nicht den als Ende markierten I-Frame selbst, aber alle ihm vorangehenden P-, B- (und theoretisch auch D-)Frames mit in die Zieldatei übernehmen.

    Wer hat ebenfalls den beschriebenen "Abhack-Effekt" beobachtet - und liegt hier in der Tat der vermutete (und im einfachsten Fall wahrscheinlich schon durch eine schlichte Inkrementierung des Endframes bei Aufruf der Schnittroutine zu vermeidende) Bug vor? :rolleyes:

    4 Mal editiert, zuletzt von TEN (13. August 2005 um 17:27)

  • Hi,

    mir ist das auch schon öfter aufgefallen, dass es an den Schnittstellen oft zur "Klötzchenbildung" kommt.
    MPEG2 wird ja normalerweise so enkodiert

    Code
    00000000011111111112222222
    12345678901234567892123456
    IBBPBBPBBPBBibbpbbpbbpbbIBB...

    Die B-Frames an der Stelle 11 und 12 werden ja aus dem P und I Frame an den Stellen 10 und 13 berechnet. schneidet man jetzt alle Kleinbuchstaben raus, so würde in die Berechnung anstatt Frame 13 der Frame 25 verwendet. Nach dem Schnitt müssten praktisch an der Schnittstelle 2 I-Frames aufeinanderfolgen, also;
    IBBPBBPBBPBBiIBB...
    Ob das VDR richtig macht weiß ich nicht. Ich denke aber dass dann wieder neue Probleme auftreten (vdrconvert etc) wenn die Abfolge der Frames plötzlich nicht mehr passt. Was man aber auch berücksichtigen muss, dass AFAIK die P-Frames vor den B-Frames gesendet werden. Gesendet wird z.B. IPBB und angezeigt wird IBBP.

    Gruß
    Roland

    Software: VDR 1.4.3, mp3, osdpip, streamdev-server, femon, wapd, X11, Wireless Keyboard Kernel: 2.6.18
    Hardware: 1x DVB-S v 1.3, 1x Skystar 2, Celeron@2GHz, 256 MB RAM, 4 HDs Raid1/5, Total: 600 GB, Asus P4S533 cmi8738 & LAN on board 6 PCI
    40" Sammelbestellungs-LCD an ATI Radeon 9550 DVI-Out + tvtime, 70 cm TV an J2-RGB-Out
    Organisator der ersten und zweiten VDR-Sanitizer Sammelbestellung.
    In progress: POV-ION 330 - MediaPointer MP-S2 - vdr 1.7.9 - vdr-xine(vdpau)

  • Wenn zwei aufeinanderfolgende I-Frames zulässig sind (wohl von der Streamstruktur und auch der Peak-Datenrate her), wäre ja jedenfalls die einfache Lösung möglich, schlicht bis einschließlich zu genau dem I-Frame zu schneiden, der als "cut-out point" markiert ist, und eben nicht (wie wohl bisher, und daher wahrscheinlich mit derselben Folge zweier aufeinanderfolgender I-Frames) bereits einen I-Frame zuvor aufzuhören.

    Andernfalls lässt man den Schnitt eben am B- oder P-Frame direkt vor dem markierten I-Frame enden, dann gibt es bei Struktur und Datenrate überhaupt keine Zweifel, weil man sie ja aus dem Originalstream übernimmt.

    So oder so reden wir von einigen Frames (also ca. 0,5 Sekunden) mehr - die nie wesentlich stören können, wenn sie zusätzlich vorhanden sind - aber auffällig vermisst werden, wenn sie (entgegen der gesetzten Schnittmarkierung!) z.B. als letzter Takt einer Abspannmusik fehlen.

    Einmal editiert, zuletzt von TEN (13. August 2005 um 21:08)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!