[ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool

Urig · 1. Januar 2011

Hallo Portal,

Ich hab Version 0.0.1 meines h.264 nalu fill data removal Tools veröffetlicht.

Das Tool löscht NALU fill data aus h.264 Streams in TS Dateien wie VDR-Aufnahmen. Die Dateistruktur wird dabei weitgehend beibehalten, nur TS-Pakete, die komplett aus NALU fill bestehen, werden entfernt. Auf HD-Kanälen mit fixer Videobandbreite kann das 40-60% der Dateigröße einsparen, ohne Bildinformationen zu verlieren.

Version 0.0.1 ist ein Standalone-Tool um einzelne Dateien zu verarbeiten. Bitte testet es mit Aufnahmen, prüft, ob die Aufnahme noch unverändert abspielbar ist, und, wenn Ihr habt, verwendet Verifikations-Tools wie ts-doctor, um das Ergebnis auf Fehler zu prüfen.

Spätere Versionen wird es auch als Patch für VDR geben, damit die fill Daten bereits bei der Aufnahme ausgefiltert werden.

Siehe auch den vorangegangenen Thread: TSDoctor für VDR? - Filler Data Entfernen

VDR Mailing-Liste: [vdr] [ANNOUNCE] naludump 0.0.1

Quelltext gibt's hier:

http://www.udo-richter.de/vdr/naludump.html

Code-Interessierten sei noch folgender Hinweis gegeben: Viele Codeteile sind abgespeckte Versionen von VDR-Quelltexten, der neue Programmcode findet sich in naludump.c (Dateiverarbeitung) und in remux.c (Klasse cNaluDumper und einige Hilfsfunktionen).

Gruß,

Udo

bexbier · 1. Januar 2011

Nabend Urig,

wo genau liegt denn der unterschied zwischen der Version von MartenR gegenüber deiner ?

Urig · 1. Januar 2011

Meine Version hab ich geschrieben.

Die Struktur ist etwas anders aufgebaut, dadurch imho leichter zu überblicken. Jeder Programmierer hat halt seinen Stil, und kann damit am besten. Und außerdem ist man beim zweiten Mal immer etwas schlauer.

Der Code versucht auch schon mal möglichst viel von VDR mit zu benutzen. Den PAT-PMT Parser zum Beispiel. Buffer für Ein- und Ausgabe, um die Anzahl Lese/Schreiboperationen zu senken.

Außerdem ist meine Version so minimal-invasiv, wie ich früher schon mal vorgeschlagen hatte: Als überflüssige Fill-Data gilt nur die vorgeschriebene Byte-Folge FF .... FF 80. Nur Pakete, die komplett aus dieser Füllmasse bestehen, werden gelöscht. (Es bleiben immer Reste von Fülldaten < 184 Byte übrig.) Und: Die Ausgabedatei hat komplett regelkonforme Fülldaten im Format FF ... FF 80.

Als Schmankerl kann der Code auch fill bytes am Anfang eines Pakets entsorgen und zu extension field filler umwandeln. Allerdings habe ich noch keinen Fall gesehen, bei dem die nalu fill's nicht exakt bis zum Ende eines TS-Pakets gehen. Und das nächste TS-Paket scheint auch immer ein gesetztes payload start flag zu haben. Aber man weiß ja nie.

Gruß,

Udo

Merlin4711 · 2. Januar 2011

Hab das mal probiert.

Musste libjpeg-dev nachinstallieren dann lief make durch.

index Datei gelöscht und naludump laufen lassen.

Danach war die datei ca 50% kleiner und ich konnte sie ohne irgendwelche Störungen abspielen.
Index Datei wurde neu erstellt und alles ist gut.

Vielen Dank für dieses tolle tool,spart echt viel Platz auf der Platte

BobW · 2. Januar 2011

Hallo,

habe das Tool auch mal probiert und bin dabei zu folgenden Ergebnissen gekommen:

ARD HD: Ersparnis rund 50%.
ORF HD: Ersparnis rund 35%

Das Kriterium für den Erfolg ist IMHO die index-Datei: Ist sie nach dem Schrumpfen und Neugenerieren gleich groß, dann ist alles OK. Ich hatte aber auch den Fall (bei ORF HD), dass die index-Datei plötzlich doppelt so groß war und die Zeiten nicht mehr stimmten, soll heißen, der Film war doppelt so lang (VDR-Anzeige beim Abspielen).

Bin gerne bereit, auch weitere Tests zu machen.

Ein Frohes Neues!
Michael

TheChief · 2. Januar 2011

Hab mal mit einer Datei einer SKY-HD Aufnahme getestet. Ergebnis: 0% dropped. Hab ich was verkehrt gemacht?

Hier mal mein Aufruf:
vdr:~/naludump-0.0.1# ./naludump ../00001.ts
Input file: ../00001.ts
Packets: 11157666 Dropped: 0 (0%)

Copperhead · 2. Januar 2011

Das klappt nur mit den öffentlich-rechtlichen

TheChief · 2. Januar 2011

Zitat

Original von Copperhead
Das klappt nur mit den öffentlich-rechtlichen

Achso? Gibt es da einen Grund für? Oder gibts dort die Fill Data nicht?

Argus · 3. Januar 2011

Zitat

Original von TheChief
Hab mal mit einer Datei einer SKY-HD Aufnahme getestet. Ergebnis: 0% dropped.

Ich denke mal , die senden in VBR und füllen, wenn nötig, anders auf Transponder-CBR auf.

Gruß Fr@nk

Zoolook · 3. Januar 2011

Hi,

danke Udo für diese stand-allone Variante, mir gefällt die schon so, auch wenn Du sie in Zukunft anders machen willst, habe sie trotzdem wie folgt als reccmd integriert, durch 2 Skripte (damit man das ganze innerhalb einer screen session aufrufen kann, vielleicht hilft das auch anderen freiwilligen Testern:

/usr/bin/naludump_vdr.sh:

Bash

#!/bin/bash


cd $1
for tsfile in *.ts; do
        mv ${tsfile} _${tsfile}
        naludump _${tsfile} ${tsfile} >> naludump.log 2>&1
        rm _${tsfile}
done
vdr --genindex=$1 >> naludump.log 2>&1
svdrpsend.pl MESG \"Finished stripping NALUs from recording '$1'\"

Alles anzeigen

/usr/share/vdr/bin/naludump_vdr_recording.sh (Pfad ist bei Gentoo VDR so üblich, dieses Skript sollte man in reccmds.conf einbinden):

Bash

#!/bin/bash


screen -dm sh -c "naludump_vdr.sh \"$1\""

Für Gentoo das ebuild /media-video/naludump-0.0.1:

Code

# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: Exp $


EAPI="2"


inherit eutils


IUSE=""


DESCRIPTION="Naludump - tool to delete NALU fill data (only complete TS packets) from h.264 streams embedded into TS files."
HOMEPAGE="http://www.udo-richter.de/vdr/naludump.html"
SRC_URI="http://www.udo-richter.de/vdr/files/${P}.tgz"


KEYWORDS="~amd64 ~x86"


SLOT="0"
LICENSE="GPL-2"


DEPEND="media-video/vdr
        app-misc/screen"


src_install() {
        dobin "${PN}"
        dobin "${FILESDIR}/naludump_vdr.sh"
        dodoc README
        insinto /usr/share/vdr/bin
        doins "${FILESDIR}/naludump_vdr_recording.sh"
        fperms ugo+x /usr/share/vdr/bin/naludump_vdr_recording.sh
}


pkg_postinst() {
        einfo ""
        einfo "You may add the following command to your \"/etc/vdr/reccmds/reccmds.custom.conf\":"
        einfo ""
        einfo "Strip h264 NALUs from recording          :/usr/share/vdr/bin/naludump_vdr_recording.sh"
        einfo ""
        einfo "And run it from your recordings menu for h264 recordings."
}

Alles anzeigen

Anbei das ebuild mit den skripten auch als Attachment.

Gruß,
Lucian

iNOB · 3. Januar 2011

Zitat

Hab mal mit einer Datei einer SKY-HD Aufnahme getestet. Ergebnis: 0% dropped. Hab ich was verkehrt gemacht?

Nö... ist bei mir genauso. Auf Sky und HD+ Sendern bringt das Strippen so gut wie keine Verringerung der Dateigröße.

Gruß
iNOB

lostinspc · 4. Januar 2011

Zitat

Originally posted by Urig
Bitte testet es mit Aufnahmen, prüft, ob die Aufnahme noch unverändert abspielbar ist, und, wenn Ihr habt, verwendet Verifikations-Tools wie ts-doctor, um das Ergebnis auf Fehler zu prüfen.

So, ich hatte jetzt Gelegenheit, naludump mal ausführlich zu testen. Ich habe es über 15 ältere und neuere HD-Aufnahmen laufen lassen, alle ARD und ZDF. Dabei waren sowohl (US-) Spielfilme als auch eigenproduzierte Reportagen und Serien.

Anschliessend habe ich die Aufnahmen mit TS-Doctor 1.0.53 ("c't Edition) überprüft.

Ergebnis: Die Größe der Aufnahmen wird (wie schon bekannt) in der Regel um ca. 40 bis 60% reduziert. In Einzelfällen sind's aber auch nur 15 bis 20%. Ich konnte in keinem Fall feststellen, dass durch das Entfernen der Nalu's Fehler entstanden sind.

Mein persönliches Fazit: Naludump ist "safe"

Das bedeutet allerdings nicht, dass TS-Doctor keine Fehler gefunden hätte: Bei Aufnahmen mit AC3 5.1 Ton kommen bei mir bei den meisten Aufnahmen regelmässig (so ca. 100 bis 150x pro Aufnahme) folgender Fehler:

Code

WARNING: For PID 17E8 AC3 properties changed at 00:02:19.863 (4.1 32kHz >>> 2.1 48kHz)
ES  ERROR: For PID 17E8 00:02:25.431 AC3 paket $00000002 has AC3 Crc error
ES  WARNING: For PID 17E8 AC3 properties changed at 00:02:25.431 (2.1 48kHz >>> 5.0 44.1kHz)
ES  ERROR: For PID 17E8 00:02:31.959 AC3 paket $00000003 has AC3 Crc error
ES  WARNING: For PID 17E8 AC3 properties changed at 00:02:31.959 (5.0 44.1kHz >>> 3.0 48kHz)
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $000E97A7 generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $00114768 generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $00147F5A generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $00179960 generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $001C0336 generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $001E2F0B generated a buffer overflow
ES  ERROR: For PID 17E8 00:02:32.919 AC3 paket $00000004 has AC3 Crc error
ES  ERROR: For PID 17E8 00:09:03.447 AC3 paket $00000005 has AC3 Crc error
ES  WARNING: For PID 17E8 AC3 properties changed at 00:09:03.447 (3.1 48kHz >>> 5.1 32kHz)
ES  ERROR: For PID 17E8 00:09:13.623 AC3 paket $0023EA93 generated a buffer overflow

Alles anzeigen

Diese sind allerdings schon in den unbehandelten Ausgangsaufnahmen vorhanden. Beim Anschauen hat das bei mir allerdings bis jetzt noch nicht zu wahrnehmbaren Fehlern geführt, vielleicht ist der TS-Doctor da auch einfach etwas zu "mäkelig".

PS: Bei Verwendung von nalustripper (weiss nicht mehr, ob die Implementation von MartenR oder Urig) gibt TS-Doctor noch folgende Warnung aus.

Code

TS  WARNING: For PID 177A $000378A7: Paket discontinuity 3,0
TS  WARNING: For PID 177A $0003CFD8: Paket discontinuity 12,8
TS  WARNING: For PID 177A $000439B1: Paket discontinuity 4,12
TS  WARNING: For PID 177A $00045F7D: Paket discontinuity 8,6
TS  WARNING: For PID 177A $000614D4: Paket discontinuity 10,8
TS  WARNING: For PID 177A $00061BD9: Paket discontinuity 6,4
TS  WARNING: For PID 177A $00061C60: Paket discontinuity 15,13
TS  WARNING: For PID 177A $00065A43: Paket discontinuity 11,2

Das passiert bei naludump nicht.

Grüße, Peter

berndb · 12. Januar 2011

Jetzt kam ich endlich auch mal zum Testen.

Ich habe zwar discontinuity-Warungen, die sind aber vorher wie nachher da (altes TS-Doctor 1.0.10 aus dem Keller gehohlt):

unbehandelte Aufhnahme:

Code

Opening file Z:\video\video2\Eine_Nacht_im_Grandhotel\2011-01-05.20.12.1-0.rec\00001.ts


...




Video format: H264 1280x720p/50 fps/High@4.0
Colorimetry : ColourPrimaries=BT.709, TransferCharacteristics=BT.709, MatrixCoefficients=BT.709


Scanning for audio details
Audio stream 1: MPEG1 Audio
Audio stream 2: MPEG1 Audio
Audio stream 3: AC3 2.0 48000Hz (DEU)


Cut in  at PCR: 00:00:00.000 (15:03:33.874)
Cut out at PCR: 01:39:57.426 (16:43:31.301)


Starting at paket $00000002(00000000) PCR: 00:00:00.000 (15:03:33.874)
No cutting at the end needed
TS  WARNING: For PID 177A $02DA06C6: Paket discontinuity 3,9
TS  WARNING: For PID 1786 $02DA06CA: Paket discontinuity 3,10
TS  WARNING: For PID 1784 $02DA06D9: Paket discontinuity 14,7
TS  WARNING: For PID 177A $02DA06DA: Paket discontinuity 10,12
TS  WARNING: For PID 1785 $02DA06DF: Paket discontinuity 12,5
TS  WARNING: For PID 177A $02DA06E0: Paket discontinuity 0,2
TS  WARNING: For PID 177A $02DA06E4: Paket discontinuity 5,7
TS  WARNING: For PID 1786 $02DA06FC: Paket discontinuity 10,12


---------  NAL Unit Type Statistic  ---------
Slices                 : 299855
    I-Slices           : 9727
    P-Slices           : 9177
    B-Slices           : 280951
    SP-Slices          : 0
    SI-Slices          : 0
Data Partition A       : 0
Data Partition B       : 0
Data Partition A       : 0
IDR Picture            : 0
SEI                    : 299856
Sequence Parameter Set : 9727
Picture Parameter Set  : 29181
AUD                    : 299855
End of Sequence        : 0
End of Stream          : 0
Filler                 : 119397
Slices                 : 0
Seq. Param. Set Ext.   : 0




Cutted pakets at the beginning: 0
Cutted pakets at the end: 0
Discarded pakets (not needed): 19454


ERRORS : 0
WARNINGS : 9735


Speed: 3,8 MBytes/sec
Duration: 00:41:48

Alles anzeigen

Dann naludump drüber, aus 9,3 GB werden 7,2 GB -!!

Code

Opening file Z:\ProjectX\Hotel.ts


...


Video format: H264 1280x720p/50 fps/High@4.0
Colorimetry : ColourPrimaries=BT.709, TransferCharacteristics=BT.709, MatrixCoefficients=BT.709


Scanning for audio details
Audio stream 1: MPEG1 Audio
Audio stream 2: MPEG1 Audio
Audio stream 3: AC3 2.0 48000Hz (DEU)


Cut in  at PCR: 00:00:00.000 (15:03:33.874)
Cut out at PCR: 01:39:57.426 (16:43:31.301)


Starting at paket $00000002(00000000) PCR: 00:00:00.000 (15:03:33.874)
No cutting at the end needed
TS  WARNING: For PID 177A $02362855: Paket discontinuity 14,10
TS  WARNING: For PID 1786 $02362859: Paket discontinuity 3,10
TS  WARNING: For PID 1784 $02362868: Paket discontinuity 14,7
TS  WARNING: For PID 177A $02362869: Paket discontinuity 11,11
TS  WARNING: For PID 1785 $0236286E: Paket discontinuity 12,5
TS  WARNING: For PID 177A $0236286F: Paket discontinuity 15,15
TS  WARNING: For PID 177A $02362873: Paket discontinuity 2,2
TS  WARNING: For PID 1786 $0236288B: Paket discontinuity 10,12


---------  NAL Unit Type Statistic  ---------
Slices                 : 299855
    I-Slices           : 9727
    P-Slices           : 9177
    B-Slices           : 280951
    SP-Slices          : 0
    SI-Slices          : 0
Data Partition A       : 0
Data Partition B       : 0
Data Partition A       : 0
IDR Picture            : 0
SEI                    : 299856
Sequence Parameter Set : 9727
Picture Parameter Set  : 29181
AUD                    : 299855
End of Sequence        : 0
End of Stream          : 0
Filler                 : 119397
Slices                 : 0
Seq. Param. Set Ext.   : 0




Cutted pakets at the beginning: 0
Cutted pakets at the end: 0
Discarded pakets (not needed): 19454


ERRORS : 0
WARNINGS : 9735


Speed: 11,3 MBytes/sec
Duration: 00:10:51

Alles anzeigen

Art und Anzahl der Fehler also vorher und nachher gleich. Sichtprüfung (also Film komplett geschaut) gab keine Auffälligkeiten.

Gleiches Spiel (ohne Sichtprüfung) bei einer arte-Aufnahme. Hier lies naludump sogar die angeblich verschlüsselten Pakete im Stream der arteHD-Aufnahme....

FireFly · 12. Januar 2011

ich kanns zwar nicht testen, aber evtl. ist der TS Packet Editor von hier hilfreich da er lt. Beschreibung auch Streams nach Fehlern durchsuchen kann (aber Vorsicht: ist Windows! :D)

hepi · 1. Februar 2011

Hallo,

erstmal vielen Dank an Urig für das Tool! Ich habe es mal auf zwei aktuelle Aufnahmen losgelassen, die von BBC HD und BBC One HD (S28.2E) stammen. Das Tool hat Pakete entfernt, jedoch wurde in beiden Fällen nur 1% der Dateigröße eingespart, das heißt, es lohnt sich hier eigentlich nicht, das Tool zu verwenden.

Das kann natürlich verschiedenste Ursachen haben, die wahrscheinlichste ist, dass BBC das ganze irgendwie cleverer macht als ARD und ZDF. Wie kann ich denn ersehen, ob dort mit variabler Bandbreite gesendet wird? Geht das hier ohne Account:

http://www.linowsat.de/cgi-bin…cgi?0282-10847-V-2050-0-0

EDIT: Ein Teil meiner Fragen wird hier beantwortet: TSDoctor für VDR? - Filler Data Entfernen

Gruß
hepi

bobo71 · 3. Februar 2011

Hallo.

Ich habe den Naludump auf meinem x86 Server mit zwei Dreambox TS Aufnahme getestet. Leider entfernt er dort keine Blöcke.
Ich habe auf dem Server vdr installiert und das naludump binary installiert.

Weiß vielleicht jemand woran das liegen kann?

Code

lin007:~# /tmp/naludump /media/Musik/ZDFHD-Lena .ts /media/Musik/test.ts
Input file: /media/Musik/ZDFHD-Lena .ts
Output file: /media/Musik/test.ts
Packets: 21448921 Dropped: 0 (0%)
lin007:~#

Danke.

Urig · 13. Februar 2011

Hab gerade eine erste Testversion eines VDR-Patches zusammen geflickt. Setup-Option etc. fehlt noch, aber er hat immerhin schon eine 1-minütige Testaufnahme geschafft.

Da das Wochenende schon wieder um ist, mach ich mal release eary, release often. Der Patch ist im Anhang. Wer Experimentierfreudig ist, kann bis zum nächsten Wochenende schon mal probieren, bis dahin sollte dann eine endgültige Version und eine neue Kommandozeilenversion fertig sein.

Aktiv wird er so nur, wenn NALUDUMP im Dateinamen auftritt. Wer ganz mutig ist, kann im Quelltext Setup_DumpNaluFill = true setzen, dann ist der Patch bei allen MPEG4-Aufnahmen aktiv, und lässt sich über NALUKEEP im Dateinamen deaktivieren.

Gruß,

Udo

hotzenplotz5 · 26. Dezember 2011

Urig ich hab grade deinen patch getestet:
http://www.udo-richter.de/vdr/naludump.html

danke !

scheint mit vdr-1.7.22 auch noch zu funkionieren.
wird aufjedenfall mit dem nächsten yavdr update auf vdr-1.7.22 kommen

https://github.com/yavdr/vdr/tree/master/debian/patches (kleine patchsammlung)
https://github.com/yavdr/vdr/b…hes/opt-63_naludump.patch

ich hoffe das passt so

Urig · 26. Dezember 2011

Der Patch wird von mir weiterhin gepflegt, und läuft zumindest bei mir ohne Störungen.

Übrigens, dieser Thread ist der ältere bis zur 0.0.1, das letzte Announce für 0.1.0 ist [ANNOUNCE] naludump-0.1 - NALU fill data Patch

Gruß,

Udo

hotzenplotz5 · 26. Dezember 2011

Zitat

Übrigens, dieser Thread ist der ältere bis zur 0.0.1, das letzte Announce für 0.1.0 ist

au verdammt sry.
diese portalsuche ... naja

[ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema