PTS Fix beim Schneiden (bitte mal testen)

kls · 19. Oktober 2012

Nachdem verschiedentlich (wohl zu Recht) moniert wurde, daß das Schnittergebnis von VDR nicht optimal ist, habe ich mich mal mit einer Möglichkeit befaßt, die Timestamps beim Schneiden zu korrigieren. Herausgekommen ist dabei beiliegender Patch, den ich euch mal bitten würde, auszuprobieren. Er macht noch einige Debug-Ausgaben und ist insgesamt noch sehr roh. Insbesondere funktioniert er nur für TS-Aufnahmen, nicht für PES!
Dabei passiert folgendes:

- es wird der höchste zuletzt gesehene Wert des PTS für die Video-PID gemerkt
- am Beginn jeder Sequenz wird ein Offset berechnet, der dann von allen künftigen PTS-Werten abgezogen wird (der Einfachheit halber ist der Offset negativ und wird addiert, damit kann der 33-Bit-Überlauf einfacher gehandhabt werden)
- mit diesem Offset werden auch die DTS- und ESCR-Werte aller PIDs beaufschlagt
- funktioniert auch mit Untertiteln

Nach ersten Tests scheint beim Abspielen mit Kaffeine und auch der TT S2-6400 der Übergang an den Schnittstellen etwas "sanfter" zu sein. Eine kurze Klötzchenbildung gibt es aber immer noch. Beim Abspielen einer geschnittenen Aufnahme auf einem Mac mini kommt dieser nach der ersten Schnittstelle allerdings nach wie vor total außer Tritt.

Für mich ergeben sich momentan folgende Fragen:

- In der vorletzten Spalte der Debug-Ausgaben wird die Differenz zwischen den PTS-Werten je zweier aufeinanderfolgender I-Frames aufgelistet. An der Schnittstelle weicht dieser Wert vom Normalwert ab, wie etwa in

Code

PID   255 C0 PTS  271520114 last  271509314 DTS  271509314 ESCR         -1          0  271520114      43200       3600
PID   255 C0 PTS  271563314 last  271552514 DTS  271552514 ESCR         -1          0  271563314      43200       3600
PID   255 C0 PTS  272124914 last  271595714 DTS  272114114 ESCR         -1 8589408992  271599314      36000       3600
PID   255 C0 PTS  272168114 last  272157314 DTS  272157314 ESCR         -1 8589408992  271642514      43200       3600
PID   255 C0 PTS  272211314 last  272200514 DTS  272200514 ESCR         -1 8589408992  271685714      43200       3600

Leider finde ich nicht heraus, woran das liegt. Vielleicht ein Denkfehler bei der Offset-Berechnung?

- Zuerst hatte ich nur die PTS-Werte korrigiert, und als damit das Außer-Tritt-geraten auf dem Mac immer noch auftrat, habe ich die DTS-Werte auch noch korrigiert, was aber keinen Unterschied gemacht hat. Schließlich habe ich noch Code für die ESCR-Werte eingebaut, aber in den Aufnahmen, mit denen ich getestet habe, kommt dieser Wert nicht vor.
Gibt es evtl. noch andere Timestamps, die korrigiert werden müssten?

Bitte schaut euch das mal genau an und laßt mich wissen, ob dieser Ansatz überhaupt Sinn macht, wo Fehler stecken könnten, und was evtl. noch berücksichtigt werden müsste.

Klaus

johns · 19. Oktober 2012

Also ich würde die PCR vermuten (http://en.wikipedia.org/wiki/MPEG_transport_stream).
Ich verwende die zwar nicht, steht aber irgendwo im TODO.

Ansonsten ist PTS und DTS richtig, da dies von verschiedenen Software decodern unterschiedlich
beides ausgewertet wird.

Johns

kls · 19. Oktober 2012

Zitat von johns

Also ich würde die PCR vermuten (http://en.wikipedia.org/wiki/MPEG_transport_stream).
Ich verwende die zwar nicht, steht aber irgendwo im TODO.

Danke - das war schonmal ein großer Schritt in die richtige Richtung!
In beliegender Version habe ich das Anpassen der PCR-Daten eingebaut. Damit spielt jetzt auch der Mac mini eine geschnittene Aufnahme über die Schnittstellen hinweg ab (von der kurzen Verpixelung mal abgesehen, aber das hat vermutlich andere Gründe, denen ich später nachgehen werde).
Je weiter die Wiedergabe auf dem Mac aber fortschreitet, um so "instabiler" wird es. Zum Beispiel kann ich in den Bereichen mit korrigierten Timestamps nur schlecht vorwärts bzw. zurück spulen. Da kommt es dann wieder irgendwie außer Tritt, manchmal wird das Bild noch abgespielt und es kommt kein Ton, ein andermal steht das Bild und der Ton läuft weiter.

Bei der Anpassung des PCR-Werte habe ich nur die "base" berücksichtigt, da diese ja synchron zum 90kHz-Takt ist, den auch die anderen Timestamps benutzen. Ist das evtl. eine falsche Annahme und müsste ich auch die "extension" mit einbeziehen? Wenn ja, wie?

Es wird also immer besser, aber so ganz astrein ist es noch nicht. Aber vielleicht fällt dir oder jemand anderem noch irgend etwas auf...

Klaus

geronimo · 19. Oktober 2012

Whow! Klaus ich bin ja so begeistert, dass Du das Thema anpackst!
Jo is denn scho Weihnachten?

Neben der Zeitstempelproblematik habe ich bei einigen Aufnahmen bei Verarbeitungstests die Fehlermeldung bekommen, dass ein PES-Paket unvollständig wäre.
Die Fehlermeldung kam genau so oft, wie es cutouts gab.

Bei meinem Medienserver habe ich es jetzt mal genauso umgesetzt, wie ich vermute, dass es der VDR auch macht.
Ich liefere die Daten bis zum Fileoffset der Eingangsschnittmarke und mache dann beim Fileoffset der Ausgangsschnittmarke weiter.
Visuell sieht das schon mal nicht schlecht aus.

Könnte es sein, dass der Fileoffset eines IFrames nicht die PES-Paket-Grenze darstellt?
Müsste man da evtl. noch was auffüllen, oder patchen?
Könnte es sein, dass der IFrame zu Beginn des cutouts einen anderen Offset innerhalb des PES-Paketes hat, als der IFrame nach dem Ende des cutouts?
Das könnte dann dazu führen, dass das PES-Paket nach dem Schnitt eine andere Länge hat, als im Header angegeben.
Keine Ahnung - ist nur eine Vermutung.

Gruß Gero

kls · 19. Oktober 2012

Zitat von geronimo

Könnte es sein, dass der Fileoffset eines IFrames nicht die PES-Paket-Grenze darstellt?
Müsste man da evtl. noch was auffüllen, oder patchen?
Könnte es sein, dass der IFrame zu Beginn des cutouts einen anderen Offset innerhalb des PES-Paketes hat, als der IFrame nach dem Ende des cutouts?
Das könnte dann dazu führen, dass das PES-Paket nach dem Schnitt eine andere Länge hat, als im Header angegeben.
Keine Ahnung - ist nur eine Vermutung.

Alles anzeigen

Tja, "können" tut so manches
Ich vermute auch, daß da noch irgendwo was im Argen ist.
Aber erstmal möchte ich die Timestamp-Problematik erledigen, denn das macht momentan die größten Schwierigkeiten (zumindest bei der Wiedergabe auf einem Mac, der wahrscheinlich die Daten etwas "genauer" anschaut - Kaffeine und andere Player scheinen da "großzügiger" zu sein).

Klaus

geronimo · 19. Oktober 2012

Zitat

Aber erstmal möchte ich die Timestamp-Problematik erledigen, denn das macht momentan die größten Schwierigkeiten

Schon klar.

Nur auf Bitebene kann ich nicht helfen.
Deshalb habe ich versucht, via Brainstorming zu helfen.

Zitat

Kaffeine und andere Player scheinen da "großzügiger" zu sein

bei den scheinbar großzügigen Playern kommt es leicht vor, dass die nach dem Schnitt völlig aus dem Konzept geraten und die Synchronität von Bild und Ton völlig aus dem Ruder läuft. Die fangen sich dann auch nimmer. MPlayer und xmbc verhalten sich ähnlich.

Wenn Du einen Linux-Player suchst, mit dem Du Deine Arbeit verifizieren kannst, dann empfehle ich Dir ffplay aus dem ffmpeg-Paket.
Ist der einzige Player, der sich wirklich um Synchronität Sorgen macht und der nicht nur die Zeitstempel berücksichtigt, sondern auch die Verarbeitungszeit des Rechners, die für die Aufbereitung eines Bildes (incl. aller Filter) benötigt wird (das scheint ansonsten kein anderer Player zu berücksichtigen).
Jedenfalls kann ffplay auch in "schrägen" Systemen wie meinem Setup Videos korrekt abspielen.

Wenn Du ffplay aus der Konsole startest, kannst Du auch die Fehlermeldungen rund um die Schnittstelle beobachten.
So kann man schnell rausfinden, ob der Fehler per DVB gesendet wurde, oder durch das Schneiden entstand.

Gruß Gero

mini73 · 19. Oktober 2012

Moin!

Sollte die PCR nicht als Basis für den Offset benutzt werden? PTS und DTS sind ja relativ zur PCR.
Was für Werte genau in der PCR extension drin stehen, weiß ich auch nicht. All zu intensiv hab ich mich mit diesen Feldern noch nicht beschäftigt.
Ich weiß nur noch, dass ich die Streams von pvrinput erst dann richtig mit vlc o.ä. abspielen konnte, als ich PCR und PCR-ext. aus dem PS in den TS übernommen habe.

Und den PCR-Wrap darf man nicht vernachlässigen, der kommt häufiger vor, als man denkt. Deshalb kann man nicht einfach den höchsten Wert vor der Schnittmarke nehmen, sondern muss sich die letzten Werte angucken, ob sie plausibel sind, und die dann für die Berechnung nehmen.

Hast du auch den TS continuity counter berücksichtigt? Der muss auch angepasst werden.
Hab heute leider keine Zeit, um in den Patch reinzusehen...

Lars.

kls · 20. Oktober 2012

Zitat von mini73

Moin!

Sollte die PCR nicht als Basis für den Offset benutzt werden? PTS und DTS sind ja relativ zur PCR.

Die PCR kommt aber viel seltener als die PTS - und letztlich sollte es egal sein, wie rum man es macht, denn zusammenpassen müssen sie sowieso.

Zitat

Was für Werte genau in der PCR extension drin stehen, weiß ich auch nicht. All zu intensiv hab ich mich mit diesen Feldern noch nicht beschäftigt.

"PCR base" ist ein 90kHz Takt, und "PCR extension" ein 27kHz Takt.
In meinem letzten Patch habe ich mich anscheinend bei der Ermittlung der PCR base um ein Byte beim Offset verzählt. Eine korrigierte Version folgt in Kürze...

Zitat

Und den PCR-Wrap darf man nicht vernachlässigen, der kommt häufiger vor, als man denkt. Deshalb kann man nicht einfach den höchsten Wert vor der Schnittmarke nehmen, sondern muss sich die letzten Werte angucken, ob sie plausibel sind, und die dann für die Berechnung nehmen.

Das sollte mein Patch eigentlich tun.

Zitat

Hast du auch den TS continuity counter berücksichtigt? Der muss auch angepasst werden.

Der dürfte allerdings deutlich weniger kritisch sein als die ganzen Timestamps. Insbesondere wenn man in einen geschnittenen Bereich direkt hineinspringt, dann weiß der Player ja nichts von einer eventuellen TS discontinuity, die viel weiter vorne mal passiert ist.

Klaus

kls · 20. Oktober 2012

Zitat von kls

In meinem letzten Patch habe ich mich anscheinend bei der Ermittlung der PCR base um ein Byte beim Offset verzählt. Eine korrigierte Version folgt in Kürze...

So, anbei eine korrigierte Version des Patches.

Mit der TT S2-6400 spielt sowohl eine geschnittene SD- als auch eine HD-Aufnahme problemlos (Klötzchen bleiben nach wie vor außen vor).
Kaffeine und der Mac spielen zwar zunächst auch noch, aber wenn man versucht, in der geschnittenen Aufnahme vor- oder zurückzuspulen, dann kommt es recht schnell zum "Festfressen". Auf dem Mac habe ich bei einer HD-Aufnahme auch manchmal in den geschnittenen Passagen einen "Hall" auf dem Ton, der in der Originalaufnahme nicht drin ist.
Irgendwo hakt's also noch.
Bitte schaut euch mal den Code kritisch an und sagt Bescheid, wenn ihr was fehlerhaftes findet. Vielleicht hab' ich mich ja durchaus nochmal irgendwo verzählt...

Klaus

S:oren · 20. Oktober 2012

Zitat von kls

"PCR base" ist ein 90kHz Takt, und "PCR extension" ein 27kHz Takt.

27 MHz?

Zitat von kls

Der dürfte allerdings deutlich weniger kritisch sein als die ganzen Timestamps

In dem 1.7.31-Thread hatten wir letzte Nacht auch die Timestamps diskutiert. Die Vermutung hier war, dass an der Schnittstelle B-Fames weggeworfen werden (wofuer ja das BrokenLink-Flag im MPEG2-GOP-Header gesetzt wird). Da der GOP dadurch quasi 2(?) Frames kuerzer wird, muessten vermutlich auch die Timestamps entsprechend angepasst werden. Bei H.264 mag es noch etwas komplizierter sein.

Gruss,
S:oren

kls · 20. Oktober 2012

Zitat von S:oren

27 MHz?

Oh ja, stimmt!
Also

Code

offset27 = (offset27 + o * 27000 / 90) & MAX9BIT;

Zitat

In dem 1.7.31-Thread hatten wir letzte Nacht auch die Timestamps diskutiert. Die Vermutung hier war, dass an der Schnittstelle B-Fames weggeworfen werden (wofuer ja das BrokenLink-Flag im MPEG2-GOP-Header gesetzt wird). Da der GOP dadurch quasi 2(?) Frames kuerzer wird, muessten vermutlich auch die Timestamps entsprechend angepasst werden. Bei H.264 mag es noch etwas komplizierter sein.

Hmmmm....

Klaus

S:oren · 20. Oktober 2012

Zitat von kls

So, anbei eine korrigierte Version des Patches.

Habe den Patch mal ausprobiert (mit SD-Material), gibt immer noch Tonprobleme. Da ich aber ohne diesen Patch mit alten vdr-Versionen schon mal besseres Verhalten hatte (siehe anderen Thread, Luecken und Knackser), macht es vermutlich wenig Sinn, mit dem neuen Patch weiter zu experimentieren.
Habe auf meinem Testsystem leider keine aelteren Versionen als 1.7.28, die hat die Schnittprobleme schon. Ein probehalber uebersetzter 1.7.22 startet nicht, muss ich weitersehen...

Gruss,
S:oren

johns · 20. Oktober 2012

Bin leider noch nicht zum testen gekommen.

Zumindest habe ich mal gesucht, womit man sich die Aufnahmen angucken kann, ohne etwas Eigenes zuschreiben.

Code

dvbsnoop -s ts -tsraw -tssubdecode -ph 0 -nohexdumpbuffer  -if <nnnn.ts>

Dump den TS Stream mit allen PCR/PTS/DTS da kann man mal gucken ob etwas negatives auffällt.

Code

dvbsnoop -s ts -tsraw  -tssubdecode -ph 0 -nohexdumpbuffer -if 00001.ts  | grep -i timestamp | less

Johns

mini73 · 21. Oktober 2012

Moin!

Ich glaube, in deiner Hilfsfunktion ist ein kleiner Fehler:

Code

void TsSetPcr(uchar *p, int64_t Pcr)
 {
   if (TsHasAdaptationField(p)) {
      if (p[4] >= 8 && (p[5] & TS_ADAPT_PCR)) {
         p[ 6] =  Pcr >> 25;
         p[ 7] =  Pcr >> 17;
         p[ 8] =  Pcr >>  9;
-        p[ 9] =  Pcr >>  8;
+        p[ 9] =  Pcr >>  1;
         p[10] = (Pcr <<  7) | (p[10] & 0x7F);
         }
      }
 }

Alles anzeigen

Diese Bitschiebereien sind aber auch schwer zu überblicken.
Oder hab ich da einen Denkfehler?

Lars.

kls · 21. Oktober 2012

Zitat von mini73

Ich glaube, in deiner Hilfsfunktion ist ein kleiner Fehler:
...

Stimmt! In der TsGetPcr() war's noch richtig, aber an der Ecke habe ich einige Male gedreht.
Danke - vier Augen sehen halt doch mehr als zwei

Damit ist es jetzt gleich ein ganzes Stück besser geworden, aber immer noch nicht optimal.
Aus dem "Hall" wurde jetzt teilweise ein "Echo".
Ich werde weiterforschen und bin nach wie vor für jeden Hinweis dankbar.

Klaus

kls · 21. Oktober 2012

Hab' gerade noch was entdeckt: In Ts[GS]etPcr[Ext]() muß es heißen

if (p[4] >= 7 && (p[5] & TS_ADAPT_PCR)) {

(7 statt 8).

Klaus

kls · 21. Oktober 2012

Zitat von johns
Dump den TS Stream mit allen PCR/PTS/DTS da kann man mal gucken ob etwas negatives auffällt.
Code
dvbsnoop -s ts -tsraw  -tssubdecode -ph 0 -nohexdumpbuffer -if 00001.ts  | grep -i timestamp | less

Danke, das ist sehr hilfreich.

Klaus

kls · 21. Oktober 2012

Damit kann ich sehen, daß die PCR offensichtlich aus "base" und "extension" zusammengesetzt wird

Code

program_clock_reference:
            baseH: 0 (0x00)
            baseL: 268600117 (0x10028335)
            reserved: 0 (0x00)
            extension: 98 (0x0062)
             ==> program_clock_reference: 80580035198 (0x12c2f1c27e)  [= PCR-Timestamp: 0:49:44.445748]

und zwar als

PCR = base * 300 + extension

also konkret

268600117 * 300 + 98 = 80580035198

wobei sich 300 aus 27000000 / 90000 ergibt.
Wenn ich da jetzt einen Offset dazuzähle, den ich wohl entsprechend auch mit 300 multiplizieren muß, dann frage ich mich, wie da der Überlauf gehandhabt werden soll. "* 300" ist ja keine Zweierpotenz.

Weiß da jemand mehr?

Klaus

Joe_D · 21. Oktober 2012

Hallo Klaus,

kennst Du diese Seite (3. Adaptionsfeld), evtl. hilft das ja...

Gruß

Joe_D

mini73 · 21. Oktober 2012

Moin!

Ist das zurückrechnen nicht einfach Division mit Rest?
neueGesamtPcr = altePcr * 300 + altePcrExt + gesamtOffsetIn27MHz (Überlauf beachten)
neuePcr = neueGesamtPcr / 300 (ganzzahlig)
neuePcrExt= neueGesamtPcr - neuePcr*300

Oder denke ich zu einfach?

Lars

PTS Fix beim Schneiden (bitte mal testen)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema