You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Friday, August 20th 2010, 9:19pm

TSDoctor für VDR? - Filler Data Entfernen

Hi,

ich habe dank ct nun bis Januar TSDoktor, das Reparieren klappt ja schon ganz gut. Einige Funktionen sind wirklich hervorragend z.B. Entferne Filler Data (NALU12).

Was ich nun aber was ich unbedingt gerne im VDR hätte wäre die Funktion "Entferne Filler Data (NALU12)".

Da die ORF mit konstant 20Mbit/s senden aber die Filme idR nicht so viel brauchen wird der Rest mit unnützen Nullen zugemüllt.

Der Film "Cleaner - Sein Geschäft ist der Tod" z.B. war nach dem Fehler korrigieren schneiden ganze 9,31GB groß. Nach dem entfernen der "Filler Data (NALU12)" waren es "nur" noch 2,45GB.

Gibt es so etwas schon für den VDR oder gibt es einen Grund warum man sich die Platte mit "Filler Data (NALU12)" zu hauen sollte?!


MfG

bbott

VDR-HW

VDR1 - AthlonII X2 240e, Asus M4N78 Pro, 4GB DDR-1066@666, 1TB WD green, Cine S2, KNC One DVB-S2 - Arctic IR Einschalter - gen2vdr V3 beta8
VDR2 - Athlon X2 4200+, Asus M4N78 Pro, 2GB DDR-800, 320GB Seagate, TT S2-3200, HP Nova-S Plus - gen2vdr V3 beta8
VDR3 - Athlon XP-M 1600+, 512MB, ASRock K7S8X, Haupauge Nova-S Plus, KNC One DVB-S


Urig

Professional

Posts: 1,223

Location: Kassel

  • Send private message

2

Saturday, August 21st 2010, 2:42pm

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

3

Saturday, August 21st 2010, 3:37pm

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.

Meine VDR

1. gen2vdr ActivyEdition auf Activy 330, HD WD-10EAVS mit Digitus DS-33151 IDE-SATA Konverter

2. gen2vdr v2 auf Aopen i915GMm-HFS und CeleronM 360J, RAM 1GB, HD Samsung HD401LJ, DVD Pioneer DVR-A05, Funk-Tastatur Cherry mit USB-Empfänger, TT FF 1.5 (System nur noch selten im Einsatz)

3. gen2vdr v3 auf Gigabyte GA-E7AUM-DS2H (NVidia 9400 Onboard-Grafik) mit Core2Duo E8500, RAM 4 GB, SATA-Festplatte im Wechselrahmen, SATA BD-ROM/DVD-Brenner Pioneer, Tastatur, Skystar HD2

4

Saturday, August 21st 2010, 5:21pm

@ halbfertiger

Wäre es evt. sinnvoll bei h264 es automatisch ein zuschalten? Das man es abschalten muss. Vielen würden die Option evt. gar nicht aktivieren aus Unwissenheit.

Soll ich das ganze für die gen2vdr V3 beta vor zuschlagen? Aber eigendlich betrifft das ja alle Distributionen.

Ich finde es nur erschrecken das über 50% überflüssig sind, ich hatte schon aufnahmen neu codiert.

So beleibt die Bildqualität erhalten, es spart Geld (Strom) und belastet weniger die Umwelt. Der Rechner dürfte auch länger leben...

VDR-HW

VDR1 - AthlonII X2 240e, Asus M4N78 Pro, 4GB DDR-1066@666, 1TB WD green, Cine S2, KNC One DVB-S2 - Arctic IR Einschalter - gen2vdr V3 beta8
VDR2 - Athlon X2 4200+, Asus M4N78 Pro, 2GB DDR-800, 320GB Seagate, TT S2-3200, HP Nova-S Plus - gen2vdr V3 beta8
VDR3 - Athlon XP-M 1600+, 512MB, ASRock K7S8X, Haupauge Nova-S Plus, KNC One DVB-S


5

Saturday, August 21st 2010, 5:27pm

Quoted

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...

Gruß,

Udo


Vielleicht könnte man die Entwickler Fragen, ob man die "Filler Data" Code/Funktion vom TSDoctor für den VDR verwenden darf?!
Eigentlich entstand TSDoktor als Freeware, getreu dem Motto Fragen kostet nichts. Außerdem gibt es unter Linux keinen TSDoctor also entfallen auch keine potenziellen Kunden.

VDR-HW

VDR1 - AthlonII X2 240e, Asus M4N78 Pro, 4GB DDR-1066@666, 1TB WD green, Cine S2, KNC One DVB-S2 - Arctic IR Einschalter - gen2vdr V3 beta8
VDR2 - Athlon X2 4200+, Asus M4N78 Pro, 2GB DDR-800, 320GB Seagate, TT S2-3200, HP Nova-S Plus - gen2vdr V3 beta8
VDR3 - Athlon XP-M 1600+, 512MB, ASRock K7S8X, Haupauge Nova-S Plus, KNC One DVB-S


Joe_D

Professional

Posts: 981

Location: Kuchen

  • Send private message

6

Saturday, August 21st 2010, 5:50pm

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

MartenR

Intermediate

Posts: 562

Location: Berlin

  • Send private message

7

Saturday, August 21st 2010, 6:21pm

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
vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

This post has been edited 1 times, last edit by "MartenR" (Aug 21st 2010, 6:26pm)


8

Saturday, August 21st 2010, 7:23pm

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

Quoted

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.

Quoted

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.

Urig

Professional

Posts: 1,223

Location: Kassel

  • Send private message

9

Saturday, August 21st 2010, 8:06pm

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

Quoted

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.

Quoted

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...

Quoted

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

MartenR

Intermediate

Posts: 562

Location: Berlin

  • Send private message

10

Saturday, August 21st 2010, 8:32pm

Quoted

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
vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

This post has been edited 1 times, last edit by "MartenR" (Aug 21st 2010, 8:40pm)


Posts: 6,250

Location: Main-Spessart

  • Send private message

11

Saturday, August 21st 2010, 11:41pm

Das es nicht auf alte Aufnahmen anwendbar ist, wäre Schade.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | Digital Devices Cine S2 V6 | ZOTAC GT630 (Rev. 2) Zone Edition

MartenR

Intermediate

Posts: 562

Location: Berlin

  • Send private message

12

Sunday, August 22nd 2010, 4:46am

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:

Source code

1
g++ -O2 -o nalustripper nalustripper.c

kompilieren.

Die Syntax lautet:

Source code

1
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
MartenR has attached the following file:
vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

13

Sunday, August 22nd 2010, 9:46am

Quoted

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.

Meine VDR

1. gen2vdr ActivyEdition auf Activy 330, HD WD-10EAVS mit Digitus DS-33151 IDE-SATA Konverter

2. gen2vdr v2 auf Aopen i915GMm-HFS und CeleronM 360J, RAM 1GB, HD Samsung HD401LJ, DVD Pioneer DVR-A05, Funk-Tastatur Cherry mit USB-Empfänger, TT FF 1.5 (System nur noch selten im Einsatz)

3. gen2vdr v3 auf Gigabyte GA-E7AUM-DS2H (NVidia 9400 Onboard-Grafik) mit Core2Duo E8500, RAM 4 GB, SATA-Festplatte im Wechselrahmen, SATA BD-ROM/DVD-Brenner Pioneer, Tastatur, Skystar HD2

14

Sunday, August 22nd 2010, 10:20am

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

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?

Joe_D

Professional

Posts: 981

Location: Kuchen

  • Send private message

15

Sunday, August 22nd 2010, 12:29pm

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.

HH_Maus

Professional

Posts: 1,299

Location: Hamburg

  • Send private message

16

Sunday, August 22nd 2010, 1:26pm

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! :) :vdr1

Lieben Gruß,
Sandy
Derzeit: YaVDR 0.4
Hardware: Asus M2NPV-VM, AMD Athlon 64 X2 4600+, 2x512 DDR2, Nvidia G210, 2x Satelco Easywatch Budget, CI, HDD Samsung SJ501, DVD Plextor PX800, Gehäuse/Display Silverstone LC16M

This post has been edited 1 times, last edit by "HH_Maus" (Aug 22nd 2010, 1:26pm)


jsffm

Master

Posts: 2,100

Location: Frankfurt/M

  • Send private message

17

Sunday, August 22nd 2010, 2:48pm

Ein erster Test von Arte HD:

Source code

1
2
3
4
5
6
-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

Mein VDR

VDR1 Mediaportal mit QVT-Board, Intel 810 Chipsatz, Pentium III 1,1 Ghz, 256 Mb Ram, WDC WD5000AAKB, DVB-S TT 1.5, Nova-S, Digidish 33, Gentoo Kernel 2.6.31, VDR 1.4.7
VDR2 Asrock M3N78D, Athlon X2 610e, 8 Gb Ram, Geforce GT 710, SL DVB-T, AirStar 2, MSI DIGIVOX Duo, PVR 350, Gentoo Kernel 4.1.15, VDR 2.2.0, softhddevice
VDR3 MC-1200, GA-B85M-HD3, Celeron G1840, GeForce GT 730. 4G Ram, TOSHIBA DT01ABA300, Mystique SaTiX-S2 Dual (v2), TT Budget S2-1600, Nova-TD Stick, Gentoo Kernel 3.18.12, VDR 2.2.0, softhddevice
TV TX-37LZD85F, AV VSX-S500 - Consono 35


vdr-User-# 755 to_h264 chk_r

18

Sunday, August 22nd 2010, 3:05pm

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

This post has been edited 1 times, last edit by "IG88" (Aug 22nd 2010, 3:06pm)


19

Sunday, August 22nd 2010, 3:25pm

Quoted

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.

Quoted

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.

Meine VDR

1. gen2vdr ActivyEdition auf Activy 330, HD WD-10EAVS mit Digitus DS-33151 IDE-SATA Konverter

2. gen2vdr v2 auf Aopen i915GMm-HFS und CeleronM 360J, RAM 1GB, HD Samsung HD401LJ, DVD Pioneer DVR-A05, Funk-Tastatur Cherry mit USB-Empfänger, TT FF 1.5 (System nur noch selten im Einsatz)

3. gen2vdr v3 auf Gigabyte GA-E7AUM-DS2H (NVidia 9400 Onboard-Grafik) mit Core2Duo E8500, RAM 4 GB, SATA-Festplatte im Wechselrahmen, SATA BD-ROM/DVD-Brenner Pioneer, Tastatur, Skystar HD2

20

Sunday, August 22nd 2010, 4:14pm

Quoted

Original von IG88
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


Das ist doch der Gag, die ORF behaupten 720p sei genauso gut bzw. besser wie 1080i wenn beides @20Mbit/s ausgestrahlt wird. Aber bei 720p werden die 20Mbit nicht wirklich genutzt, bei 1080i (z.B. bbc hd) schon. Leute die jetzt nach 1080p schreien werden mit einem ~40Mbit/s Signal rechnen müssen.


@ halbfertiger
Das weglassen der Filler Data (NALU12), sollte selbst einen Atom nicht überfordern. Warum sollte dies schwache Systeme überfordern? In wie fern? Welche meinst du damit genau?

Eine Option zum ein-/abschalten wäre wohl nicht schlecht um Kritiker/Skeptiker zu beruhigen.

Auch beim Scheiden hat seinen Sinn zu Filtern, es wäre nicht schlecht für Leute dich kein tsDokter nutzen könne/wollen und schon viele Aufzeichnungen haben.

Ich hätte zumindestens bis Jan gerne ein Lösung, wenn meine Kostenlose Version abläuft :) Wobei mir das Filtern gleich beim Aufzeichnen am sinnvollsten erscheint und besten gefällt.


Zum Thema HD Material Korrektur:
Wie sieht es eigendlich aus mit der Korrektur von auf Aufnahmen? Für SD ist ja projectx sehr gut, aber HD geht damit ja nicht. Was freies und Empfehlenswertes in noch nicht in Sicht, oder?

VDR-HW

VDR1 - AthlonII X2 240e, Asus M4N78 Pro, 4GB DDR-1066@666, 1TB WD green, Cine S2, KNC One DVB-S2 - Arctic IR Einschalter - gen2vdr V3 beta8
VDR2 - Athlon X2 4200+, Asus M4N78 Pro, 2GB DDR-800, 320GB Seagate, TT S2-3200, HP Nova-S Plus - gen2vdr V3 beta8
VDR3 - Athlon XP-M 1600+, 512MB, ASRock K7S8X, Haupauge Nova-S Plus, KNC One DVB-S


Immortal Romance Spielautomat