Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Freitag, 20. August 2010, 21:19

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


2

Samstag, 21. August 2010, 14:42

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

Samstag, 21. August 2010, 15:37

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

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

Samstag, 21. August 2010, 17:21

@ 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

Samstag, 21. August 2010, 17:27

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

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


6

Samstag, 21. August 2010, 17:50

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

7

Samstag, 21. August 2010, 18:21

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)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MartenR« (21. August 2010, 18:26)


8

Samstag, 21. August 2010, 19:23

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.

9

Samstag, 21. August 2010, 20:06

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

10

Samstag, 21. August 2010, 20:32

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »MartenR« (21. August 2010, 20:40)


11

Samstag, 21. August 2010, 23:41

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

12

Sonntag, 22. August 2010, 04:46

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:

Quellcode

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

kompilieren.

Die Syntax lautet:

Quellcode

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« hat folgende Datei angehängt:
  • nalustripper.c.gz (2,74 kB - 258 mal heruntergeladen - zuletzt: 31. Oktober 2016, 19:09)
vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

13

Sonntag, 22. August 2010, 09:46

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.

Meine VDR

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

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

Sonntag, 22. August 2010, 10:20

@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?

15

Sonntag, 22. August 2010, 12:29

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.

16

Sonntag, 22. August 2010, 13:26

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »HH_Maus« (22. August 2010, 13:26)


17

Sonntag, 22. August 2010, 14:48

Ein erster Test von Arte HD:

Quellcode

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

Sonntag, 22. August 2010, 15:05

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »IG88« (22. August 2010, 15:06)


19

Sonntag, 22. August 2010, 15:25

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.

Meine VDR

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

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

Sonntag, 22. August 2010, 16:14

Zitat

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