TSDoctor für VDR? - Filler Data Entfernen

Zitat

Original von gda

Setze mal ein strace davor und poste den output um den open()-Befehl.

Oder vorher erst mal ein

ls -l /mnt/data/video/00001.ts

Zitat

Original von gda
Setze mal ein strace davor und poste den output um den open()-Befehl.

Gerald

vdr01 ~ # strace /usr/local/src/nalustripper /mnt/data/video/00001.ts /mnt/data/video/test.ts
execve("/usr/local/src/nalustripper", ["/usr/local/src/nalustripper", "/mnt/data/video/00001.ts", "/mnt/data/video/test.ts"], [/* 60 vars */]) = 0
brk(0)                                  = 0x804c000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb771c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=180602, ...}) = 0
mmap2(NULL, 180602, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76ef000
close(3)                                = 0
open("/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260A\4\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=909352, ...}) = 0
mmap2(NULL, 932044, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb760b000
mmap2(0xb76e4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd9) = 0xb76e4000
mmap2(0xb76e9000, 22732, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76e9000
close(3)                                = 0
open("/lib/libm.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@4\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=161720, ...}) = 0
mmap2(NULL, 151680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75e5000
mmap2(0xb7609000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23) = 0xb7609000
close(3)                                = 0
open("/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\34\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=50564, ...}) = 0
mmap2(NULL, 53768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75d7000
mmap2(0xb75e3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb) = 0xb75e3000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20m\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1393360, ...}) = 0
mmap2(NULL, 1345792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb748e000
mmap2(0xb75d1000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x143) = 0xb75d1000
mmap2(0xb75d4000, 10496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb75d4000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb748d000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb748c000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb748c6d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb75d1000, 8192, PROT_READ)   = 0
mprotect(0xb75e3000, 4096, PROT_READ)   = 0
mprotect(0xb7609000, 4096, PROT_READ)   = 0
mprotect(0xb76e4000, 16384, PROT_READ)  = 0
mprotect(0x804a000, 4096, PROT_READ)    = 0
mprotect(0xb773a000, 4096, PROT_READ)   = 0
munmap(0xb76ef000, 180602)              = 0
brk(0)                                  = 0x804c000
brk(0x806d000)                          = 0x806d000
open("/mnt/data/video/00001.ts", O_RDONLY) = -1 EFBIG (File too large)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb771b000
write(1, "Input file: /mnt/data/video/0000"..., 37Input file: /mnt/data/video/00001.ts
) = 37
write(1, "Cannot open /mnt/data/video/0000"..., 36Cannot open /mnt/data/video/00001.ts) = 36
exit_group(-1)                          = ?
vdr01 ~ #

Zitat

Original von FireFly
Oder vorher erst mal ein

Code

ls -l /mnt/data/video/00001.ts

vdr01 ~ # ls -l /mnt/data/video/00001.ts
-rwxr-xr-x 1 root root 15576475860 22. Aug 14:34 /mnt/data/video/00001.ts
vdr01 ~ #

Ersetze mal fopen mit fopen64.....

Marten

Zitat

Original von MartenR
Ersetze mal fopen mit fopen64.....

Marten

Damit gehts.

vdr01 src # g++ -O2 -o nalustripper nalustripper.c
nalustripper.c: In function »int main(int, const char**)«:
nalustripper.c:323: Warnung: Der Rückgabewert von »size_t fwrite(const void*, size_t, size_t, FILE*)«, der mit dem Attribut warn_unused_result deklariert wurde, wird ignoriert
vdr01 src # /usr/local/src/nalustripper /mnt/data/video/00001.ts /mnt/data/video/test.ts
Input file: /mnt/data/video/00001.ts
Output file: /mnt/data/video/test.ts


Found new h264pid 1920!
**********^C
vdr01 src #

Zitat

Original von MartenR

Pes oder TS SD Aufnahmen?
Bei Pes ist das klar das es nicht funktioniert, solll es ja auch nicht, bei TS SD Aufnahmen sollte er das eigentlich nur kopieren..

Es sind TS SD-Aufnahmen:

Dort kommt dann:
Found new h264pid 601! ****

Das file ist dann auch einige MB kleiner, aber man sieht / hört nichts mehr, das läuft dann unter moderne Kunst ...

Bei TS HD-Aufnahmen kommt im Gegensatz dazu:
Found new h264pid 6010!

Grüße, Peter

lostinspc
Ok, ich sehe was passiert, da war ein Tippfehler im PAT PMT Parser, versuch mal die neue Version.

Marten

Hi,

könntest Du Versionsnummern für den Patch und die Standaloneversion vergeben?
Sonst kommt man ruck-zuck durcheinander welche Version man grade benutzt und auch bei Supportanfragen bzw. Fehlersuche wird es schwierig zu helfen, da der Fehler z.B. in einer neueren Version schon gefixed ist, man aber nicht feststellen kann welche Version benutzt wurde.

Gruß
FireFly

Hallo

ich hab die letzte .c-datei vom 25.08.2010 heruntergeladen.

Meine eine Testdatei "00001.ts" ist über 9GB groß, um sie in einem auch mit anderen programmen, Abspielgeräten abspielen zu können.

Wenn ich so eine Riesendatei mit dem compilitertn tool anpacke, wird die neue ts-datei immer um die 2GB groß. Da fehlt dann aber über die Hälfte des Films.

Darauf hin hab ich dann mal eine andere 7GB-Datei angepackt.
Da ist das selbe. Immer eine Datei, die ungefähr 2GB groß ist
und dann ist Ende.
Beide Aufnahmen sind fehlerfrei, ausser das sie eben nur 30-45Min. lang sind.

Ich weissnix aber fielleicht haben auch andere Leute das Problem und nicht nur Ich.

Ok, das hätte also zweimal fopen64 sein müssen, naja, ist korrigiert jetzt mit Versionsnummer.
[Edit: hatte den Anhang vergessen]

Marten

MartenR

kann man das schon irgendwo runterladen?

wie wäre es eigentlich eine mini-homepage bei vdr-developers.org zu haben?
Müsste ja nur der download-link drinnen sein, oder?
nur mal so als Idee daher gesagt, aber ich weissnix

Zitat

kann man das schon irgendwo runterladen?

Hatte vergessen auf den Speichern link zu drücken.

Zitat

wie wäre es eigentlich eine mini-homepage bei vdr-developers.org zu haben?

Finde ich für ein Program dass in nur ein paar Stunden geschrieben wurde und nur zum testen des Patches dient, ein wenig mit Kanonen auf Spatzen geschossen. Ziel wird eher sein kls später vom einbauen eines Patches zu überzeugen.

Marten

Zitat

Original von MartenR
....Ziel wird eher sein kls später vom einbauen eines Patches zu überzeugen.

Marten

na, ich hoffe, das es das eigenständige programm auch noch was geben wird.
Da kann ich doch, wenn alles klappt die alten HD-Aufzeichnungen nachträglich verkleinern.

(logisch: im Moment nur zum Testen noch mit Originaldatei als Backup)

...
mit der Homepage fänd ich nur übersichtlicher, da sieht man direkt, wann wo was neu ist.
Der ursprüngliche Thread-Ersteller pflegt ja Deine neuen Versionen nicht ganz oben im trhead ein.
Daher muss man sich durch den ganzen thread gucken bevor man das aktuellste an Programmen von Dir findet.
Das ist aber nicht bös gemeint von mir.
daher dachte ich, wäre ein mini-homepage übersichtlicher.

gruß, weissnix

Zitat

Original von MartenR
... ist korrigiert jetzt mit Versionsnummer.

Ähm, ich dachte nicht nur im Quelltext sondern auch als Archiv (wäre dann als tar besser da dann der Archivname vom Dateinamen unabhängig wäre) und außerdem müsste es ja dann schon Version 0.0.0.4 sein ...
Nix als Wünsche haben die Leute hier .....

Zitat

Original von MartenR
lostinspc
Ok, ich sehe was passiert, da war ein Tippfehler im PAT PMT Parser, versuch mal die neue Version.

Marten

Danke, passt jetzt. Bei SD wird jetzt keine h264 pid mehr gefunden, laut cmp sind input und output identisch. HD funktioniert nach wie vor.

Grüße, Peter

PS: Wenn Dir mal wieder langweilig ist Etwas Statistik wäre noch cool (z.B. saved xxxx MB, output size is 50% of input size)

Moin,

Sky sendet wohl keine NULL-Bytes? Alle bisher ausprobierten Sky-Samples werden nicht ein Bit kleiner?!

Gruß, ollo

Zitat

Original von ollo
Moin,

Sky sendet wohl keine NULL-Bytes? Alle bisher ausprobierten Sky-Samples werden nicht ein Bit kleiner?!

Gruß, ollo

war da nicht sowas wie: die öffentl.rechtlichen Sender senden mit einer gleichbleibenden Größe an Daten?

Währenddessen doch angebl. Sky die besseren Codier-Computer hat um mehr Daten aufm Transponder zu bekommen.
Deswegen sind wohl die gleichen Filme einmal größer und einmal kleiner.
Je nach Tagesform

Vielleicht hab ich mich falsch ausgedrückt, aber ich meine sowas in der Art mal in so eine Sat-zeitschrift gelesen zu haben, das die "Fülldaten" nur bei bestimmten statisch ausstrahlenden Sender gäb.
aber ich weissnix
mehr wo das war, wo ich das gelesen hab.

Zitat

Original von MartenR
...
Ziel wird eher sein kls später vom einbauen eines Patches zu überzeugen.
...

Nun, iirc war Klaus nie ein Freund davon, den eintreffenden Datenstrom in irgend einer Wiese zu veränden.
Er hat sich immer strikt an die Standarts gehalten, und hat dafür Schelte in der Mailing List erhalten, ich sag nur SVDR Port
Ich beführworte diese Haltung. Darum sollten wir uns eigentlich fragen, warum wir alle GEZ für Datenübertragungsvolumen zahlen, obwohl wir nichts dafür bekommen.

pinky666

man kann kls ja mal fragen, das kostet nichts und in diesem fall ist ja auch ein echter "gewinn" vorhanden und wenn es nicht integrierbar ist dann könnte man über eine entsprechende plugin schnittstelle reden

> Ich beführworte diese Haltung. Darum sollten wir uns eigentlich fragen, warum wir
> alle GEZ für Datenübertragungsvolumen zahlen, obwohl wir nichts dafür bekommen.

??? vieleicht überlässt du das lieber brain