TSDoctor für VDR? - Filler Data Entfernen

So ein NALU Filter als kompaktes Open Source Programm ist definitiv dringend mal nötig. Am besten standalone und/oder als Filter schon bei der Aufnahme. Ich hab ja schon überlegt, ob ich mich in das Thema mal rein arbeite, aber das wird sicher einiges an Zeit kosten, sich so tief in die h.264-Formatstruktur einzuarbeiten. Und Zeit fehlt ja immer chronisch...

Gruß,

Udo

Bei der Aufnahme nicht, da dabei das System sowenig wie möglich belastet werden sollte. Ich hatte aber schon mal die Idee es in der Schnittfunktion (notfalls als zuschaltbare Option) unter zu bringen. Beim Schneiden muss die Datei sowieso neu geschrieben und ein neuer Index angelegt (?) werden und das kann problemlos mit niedrigster Priorität erfolgen.

So wie ich das verstanden habe sind Filler NALU Pakete mit der Nummer 12 (also 0x00 0x00 0x00 0x01 0x12), die könnten IMHO schon während der Aufnahme einfach weggelassen werden...

Gruß

Joe_D

Hallo,

Das mit den NALU 12 wußte ich noch gar nicht.
Ich habe mir mal die h264 spec angeschaut.
Alles was es braucht ist ein NALU Parser. (siehe 47 (65) ff
Die NALU selbst sind der oberste Level im h264 stream und leicht zu parsen, dass sollte kaum performance Probleme bei der Aufnahme geben. Im Moment parsed der vdr Teile der Nalus im Framedetector.

Das einzige Problem was ich sehe, ist wenn die PesPacket Länge im Pespacket gesetzt ist und nicht über den TS Strom kontrolliert wird, dann müßte man das ganze Pes Packet zwischenspeichern.

Ansonsten muß nur der Contiuity Counter im TS Strom des Videos noch angepasst werden.

Ich finde wir sollten den vdr entwickler fragen ob er das einbauen kann und insbesondere wo das eingebaut werden soll.

Marten

Das Thema hatten wir hier schonmal ... leider ohne Ergebnis

Zitat

Original von Urig
So ein NALU Filter als kompaktes Open Source Programm ist definitiv dringend mal nötig. Am besten standalone und/oder als Filter schon bei der Aufnahme. Ich hab ja schon überlegt, ob ich mich in das Thema mal rein arbeite, aber das wird sicher einiges an Zeit kosten, sich so tief in die h.264-Formatstruktur einzuarbeiten. Und Zeit fehlt ja immer chronisch...

Da geht es mir leider genauso ....

Ich denke, das femon-Plugin ist eine gute Quelle für das Parsen, denn da wird der Stream schon leicht analysiert.

Zitat

Original von MartenR
Ich finde wir sollten den vdr entwickler fragen ob er das einbauen kann und insbesondere wo das eingebaut werden soll.

Du meinst kls? Ich fürchte er wird ablehnen, denn mit dem TS-Format soll genau das Parsen des Streams nicht mehr notwendig sein, so dass VDR beliebige Videoformate unterstützt. Du kannst aber trotzdem mal fragen.
So wie ich das sehe, gibt es bisher keine Filter-Schnittstelle im VDR, wo man so etwas reinklinken könnte, weshalb das auf einen Patch hinauslaufen würde.

Wow, hier kommt ja viel mehr Leben rein, als ich erwartet hatte...

Zitat

Bei der Aufnahme nicht, da dabei das System sowenig wie möglich belastet werden sollte.

Da stimme ich nicht zu. Die Fülldaten müssen auch durch den Speicher gewälzt werden und belasten die Festplattenbandbreite. Je früher die Daten fallen gelassen werden können, desto besser. Und beim Schneiden bevorzuge ich das 1:1 Kopieren, damit hard link cutter wirken kann. Ich werde jedenfalls nicht wieder minutenlang auf das Schneiden warten.

Zitat

Alles was es braucht ist ein NALU Parser. (siehe 47 (65) ff
Die NALU selbst sind der oberste Level im h264 stream und leicht zu parsen, dass sollte kaum performance Probleme bei der Aufnahme geben. Im Moment parsed der vdr Teile der Nalus im Framedetector.

Das einzige Problem was ich sehe, ist wenn die PesPacket Länge im Pespacket gesetzt ist und nicht über den TS Strom kontrolliert wird, dann müßte man das ganze Pes Packet zwischenspeichern.

Ansonsten muß nur der Contiuity Counter im TS Strom des Videos noch angepasst werden.

Das klingt doch schon mal nach einem ganz guten Ansatz. Da werd ich mich wohl doch mal in die Doku zu h.264 einarbeiten müssen...

Zitat

So wie ich das sehe, gibt es bisher keine Filter-Schnittstelle im VDR, wo man so etwas reinklinken könnte, weshalb das auf einen Patch hinauslaufen würde.

Erst mal wäre ein Patch die beste Strategie, aber ein standalone Tool zum Testen / Aufnahmen nachbearbeiten wird auch hilfreich sein. Später können wir ja vielleicht kls eine Filter-Plugin Schnittstelle aus den Rippen leiern...

Gruß,

Udo

Zitat

Das klingt doch schon mal nach einem ganz guten Ansatz. Da werd ich mich wohl doch mal in die Doku zu h.264 einarbeiten müssen...

Es reichen eigentlich die Seiten die zitiert habe.
Im Prinzip kann relativ schnell ein Objekt schreiben indem man ein Video TS Paket reinschickt und gefilterte TS Paket herausbekommt.
(Ich arbeite zur Zeit an einem Plugin das auch TS, PES und Videodaten braucht insofern bin ich da eingearbeitet...)

Mein Problem ist das ich noch für ein Jahr von meinem VDR mit Aufnahmekarten getrennt bin, also brauche ich Leute die ein bischen entwickeln und testen können, dann würde ich mich am Nachmittag an einen patch oder so ein Klasse machen.

Edit: Ich denke im cDevice Action könnte man das ohne Probleme einbauen, das bringt allerdings nichts bei alten Aufnahmen.

Marten

Das es nicht auf alte Aufnahmen anwendbar ist, wäre Schade.

Ok, ich habe mich mal rangesetzt so einen Nalu 12 stripper zu schreiben.
Die angehängte Datei enthält den Entwurf von ein paar Filterklassen, die wir so in das Device object einbauen könnten.

Man kann das ganze mit:

g++ -O2 -o nalustripper nalustripper.c

kompilieren.

Die Syntax lautet:

nalustripper input.ts output.ts

Danach muß man natürlich die index datei löschen, die stimmt dann ja nicht.
Da ich keinen vdr mit Ausgabedevice zur Hand habe, konnte ich es nur mit vlc testen und einer alten HD Testaufnahme. Da konnte aber nur wenig gespart werden statt 96 MB sind es nun 76 MB. Bei meinem Beispielfile war das nicht so eindrucksvoll.

Wichtig, da habe ich schnell in ein paar Stunden zusammengeschrieben, da können viele Fehler enthalten, also bitte nur am Backup verwenden und erstmal testen. Beim Debuggen hatte ich viele kleine Bildstörungen am Rand (sind jetzt natürlich weg), die nur bei genauen Hinschauen zu erkennen waren.

Sollten Fehler auftreten, bitte die entsprechende Stelle mit vdr herausschneiden (an der Ausgangsdatei) und ein 50-100 MB Testfile erstellen, schauen ob der Fehler auch dort auftritt und es mir irgendwie zur Verfügung stellen.

Wenn es stabil ist versuche ich einen patch zu erstellen.

Marten

Zitat

Original von Copperhead
Das es nicht auf alte Aufnahmen anwendbar ist, wäre Schade.

Wäre es problemlos wenn man es in die Schnittfunktion anstatt in de Aufnahmefunktion einbaut.

MartenR: Hey, das hört sich vielversprechend an!

Hast Du das Ergebnis auch mal mit TSDoctor überprüft? Oder gibts eine andere Möglichkeit die Gültigkeit des TS-Streams zu überprüfen?

Die NALU-Filler-Ignore-Funktionalität sollte direkt in cFrameDetector::Analyze vom VDR eingebaut werden und bitte nicht in die Schnittfunktion oder ins Device (NALU-Filler sind unabhängig vom Device). Ich verwende (und viele andere wohl auch) den Hardlinkcutter (http://www.vdr-wiki.de/wiki/index.php/HLCutter-patch) und der wäre durch sowas unbrauchbar

Für "alte" Aufnahmen kann man ja ein externes Programm wie das von MartenR's verwenden.

Nur so am Rande:
Juhuu! Endlich kommt mal so richtig Schwung in die Sache!
So riesige HD-Aufnahmen archivieren ist ein ebenso riesiges Ärgernis (zumindest für mich).

Danke und viel Glück! Ich freue mich schon darauf!

Lieben Gruß,
Sandy

Ein erster Test von Arte HD:

-rw-r--r-- 1 root root 2097925088 18. Dez 2009  00001-1.ts
-rw-r--r-- 1 root root 1046631532 22. Aug 14:31 00001.ts
-rw-r--r-- 1 root root 2097543260 18. Dez 2009  00002-1.ts
-rw-r--r-- 1 root root 1053470596 22. Aug 14:33 00002.ts
-rw-r--r-- 1 root root 1320054032 18. Dez 2009  00003-1.ts
-rw-r--r-- 1 root root  707345112 22. Aug 14:34 00003.ts

Die Dateien mit -1 sind die Originale.

Vorher 5,386,252K
Nachher 2,741,648K

Die index-Datei hatte ich renamed, sie wird dann neu angelegt.

Jetzt müsste man nur noch nen Sript schreiben, der das Ganze automatisiert.

MfG,

jsffm

hi,

habe es mal mit einer bbc hd aufnahme und einer von arte hd versucht (je nur ein 2GB file)
bei bbc hd ließ sich nichts sparen bei artehd ging es auf 810MB runter, das gleiche ergebnis wurde auch mit tsdoctor erzielt und sowohl das ergebnis von nalustripper als auch von tsdoctor ließen sich genauso mit vdr abspielen wir das original
tsdoctor hatte an dem ergebnis vom nalustripper auch nichts auszusetzen
sieht so aus als wäre der erste versuch ein voller erfolg, lässt sich imho also sofort in die reccmds.conf von vdr integrieren um vorhandene aufnahmen zu verschlanken

Zitat

Original von Joe_D
Die NALU-Filler-Ignore-Funktionalität sollte direkt in cFrameDetector::Analyze vom VDR eingebaut werden

So wie ich damals die Begründung für den Umstieg von PES auf TS verstanden habe, wird das nicht passieren, zumindest nicht im offiziellen vdr.

Zitat

Ich verwende (und viele andere wohl auch) den Hardlinkcutter und der wäre durch sowas unbrauchbar

Auf Einzelschicksale Rücksicht nehmen und dadurch auf leistungsschwächeren Systemen Aufnahmen gefährden? Lieber nicht, wer das möchte sollte patchen.