rec 2 mpg

[pixeljunkie]

ja, die Doku habe ich gesehen. Durch die beiden Repositories auf der Mplayer-site bin ich auch mal durch. Und unter "links" haben die ja noch eine Menge sonstiges brauchbares ...

Muss ich mir übers Wochenende mal genauer ansehen.

[steve]

[quote=""ragtime""]Hast du denn mittlerweile mal probiert, ob es was bringt mit dd nur den Topf-Header zu entfernen?[/quote]

So, hab mal getestet. Allerdings nicht dd, sondern DVBCut! Und ich muss sagen, ich bin begeistert. Klappt bislang fehlerfrei. Allerdings entstehen Wartezeiten, da die rec wohl erst indiziert wird und dann im Export auch noch mal einige Zeit arbeitet.

[ragtime]

Naja, ist halt in erster Linie ein Schnittprogramm und kein Tool zur TS->PS-Konvertierung!

Fuer ne reine Konvertierung (d.h. einmal sequentiel Lesen) braeuchte man die Indizierung im Prinzip ja nicht, ist aber programmiertechnisch nun nicht mehr so einfach zu umgehen. Es geht uebrigens auch ein Batchschnitt(bzw. konvertierung) mit:

dvbcut -batch <Projektdatei>

Die XML-Projektdatei fuer ne simple Konvertierung koennt man recht leicht auch automatisch erstellen.
Dummerweise muss man dabei aber zumindest ein IN/OUT-Schnittpaar angeben... im Fall der Konvertierung also 0 und max. Framezahl-1... an letztere kommt man aber nicht so einfach ohne GUI ran.

Wollte immer mal probieren, ob man da zB 9999999 eintragen kann, ohne dass er abstuerzt. Gut, dass du mich dran erinnerst... :-)

Die komfortabelste Loesung waere natuerlich, dass man anstelle der Projektdatei einfach ein TS-File angibt und er im Batchmodus dann einfach automatisch von Anfang bis Ende konvertiert... im Moment schreibt dvbcut da naemlich ein leeres File, weil ihm die Schnittmarken fehlen. Mal gucken was sich da machen laesst... hab ich auch schon oefters vermisst... ich liebe OpenSoureSoftware.

Die Zeit beim Export laesst sich uebrigens schlecht vermeiden... irgendwie muss das File ja geschrieben werden, oder? Beschleunigen laesst sich sowas allerdings bei JEDEM Tool erheblich, indem du NIE auf die Platte schreibst auf der das Inputfile liegt!!!

[steve]

[quote=""ragtime""]
Die Zeit beim Export laesst sich uebrigens schlecht vermeiden... irgendwie muss das File ja geschrieben werden, oder? Beschleunigen laesst sich sowas allerdings bei JEDEM Tool erheblich, indem du NIE auf die Platte schreibst auf der das Inputfile liegt!!![/quote]

Nein, das sind 2 unterschiedliche Platten, allerdings in 2 verschiedenen Systemen. Geht derzeit leider nicht anders.

[ragtime]

Wie,... unterschiedliche Systeme? Du meinst du schreibst uebers Netzwerk...

Das sollte ja kein Problem sein, wenn das nicht nur 100Mbit-Ethernet ist... die 2. Platte ueber ne 1Gbit-Ethernet
Leitung duerfte immer noch schneller sein, als auf einer Platte gleichzeitig Lesen und Schreiben!

[steve]

[quote=""ragtime""]Wie,... unterschiedliche Systeme? Du meinst du schreibst uebers Netzwerk...

Das sollte ja kein Problem sein, wenn das nicht nur 100Mbit-Ethernet ist... die 2. Platte ueber ne 1Gbit-Ethernet
Leitung duerfte immer noch schneller sein, als auf einer Platte gleichzeitig Lesen und Schreiben![/quote]

Normalerweise Wlan G. Aber zu dem Zweck hab ich den Läppi extra an die Leine genommen!! 100 Mbit

[ragtime]

OK, das ist dann der Flaschenhals... heutige Platten sind deutlich schneller... zum. bei seq. Lesen!

Uebrigens hab ich oben noch was geaendert... im Batchmodus kann man kein -generateidx angeben, dass ist dazu gedacht nur (irgendwo) nen Index zu erzeugen ohne die GUI aufzurufen und ohne irgendwas zu schneiden/konvertieren. Im Batchmodus wird das Indexfile automatisch da erzeugt wo das MPEG-File liegt, falls sein Name nicht im Projektfile explizit anders angegeben ist.

Nachtrag: Angabe eines zu grossen OUT-Schnittmarkers fuehrt uebrigens zu nix... das Outputfile ist leer da DVBcut alle ungueltigen Marker verwirft!

NACHTRAG2: Hab ne elegantere Loesung gefunden... patch ist submitted! Man braucht nun auch nicht mehr unbedingt ein Projektfile anzugeben... das Inputfile reicht. Revisionen >55 sollten das enthalten...

[Panurg]

Ich lese das jetzt erst wieder hier mit.

Also, ich habe, wie alle inzwischen wissen, Wombles "MPEG Video Wizard" im Einsatz.

Das gibt's mit 'ner 30 Tage Testzeit; kostet $69. (Es gibt auch noch eine Version für $99, die hat dann noch DVD authoring Sachen mit dabei (glaubich))

MVW macht .rec zu .mpg hoch zuverlässig und schnell. Nix demux oder so.
Man kann auch noch allerhand andere relevante Sachen machen mit dem Programm.

Ich habe seit kürzerem auch so einen Mediaplayer mit HDD: einen TViX M-4000 von DVICO. Der kann auch Transportstream, aber eben keine unbearbeiteten .rec-Dateien vom TOPF. Man kann also im MVW ein .rec zu einem Transportstream umarbeiten und setzt dann die passende Erweiterung, statt .rec, hinten ran, zB .tp oder .trp (das ist jetzt mal das, was mein TViX akzeptiert).
Ich denke aber, die Umwandlung in .mpg Program-File ist das beste. Jedenfalls kommt mein TViX damit besser zurecht als mit .tp: bei letzterem wird die Gesamtspieldauer nicht ordentlich ausgelesen und folglich misslingen Schnellvor- und -rücklauf fast immer irgendwie. MPG-Program wird fast immer fast überall gelesen.

Also, wenn man bereit ist, ein paar 50 EURO ans Bein zu binden, ist man mit MVW wirklich ziemlich gut bedient. (und nein, ich kriege keine provision von Womble )

P

[ragtime]

Also wenn du das rec-file eh durch so ein teil wie wombel oder dvbcut durchschleust ist es wirklich besser gleich den Programmstream rauszuschreiben, wenn das der Player auch kann.

Wenn du aber (aus was fuer nem Grund auch immer) ein topfheaderlosen Transportstream haben willst, wuerde ich doch lieber wie oben schon von ibbi erwaehnt nur mittels dd "umkopieren" .... oder noch besser sofern Linux vorhanden mit tsfilter (dann sind die TS-Files auch nicht mehr groesser als die PSe... MTV2 sendet naemlich ploetzlich >60% (!) unnuetzte payload mit.....Arghhhhh, und ich hatte gehofft die haetten die Bitrate/Aufloesung erhoeht! ).

Allerdings warte ich ja immer noch auf DAS Tool, was den Topfheader einfach entfernt ohne das File umzukopieren... also indem es einfach nur an der FAT schraubt... wuerde viel Zeit/Platz sparen!

NACHTRAG: Obiges gibt es ja schon fast... hifan hat beim Versuch rec-files auf seinem Mvix media-player abzuspielen nen Tool geschrieben, dass den Topf-Header einfach patched bzw. ueberschreibt. ;-)
--> viewtopic.php?p=242836#p242836

[hifan]

[quote=""ragtime""]Allerdings warte ich ja immer noch auf DAS Tool, was den Topfheader einfach entfernt ohne das File umzukopieren... also indem es einfach nur an der FAT schraubt... wuerde viel Zeit/Platz sparen!

NACHTRAG: Obiges gibt es ja schon fast... hifan hat beim Versuch rec-files auf seinem Mvix media-player abzuspielen nen Tool geschrieben, dass den Topf-Header einfach patched bzw. ueberschreibt. ;-)
[/quote]

Also um das klarzustellen: das topf2mvix überschreibt den Header mit normalen TS-packets. Insofern löscht es ihn defakto weg (glücklicherweise belegt der Header vorne eben genau soviel Platz wie 20 TS-packets a 188 Byte).

Aber das grundsätzliche Problem, einer Datei vorne wirklich was wegzuschneiden, ohne sie komplett neu zu schreiben, löst das natürlich nicht. Es wird nix am FAT (bzw. ext3 beim Mvix) Filesystem gedreht. Mir ist bis heute nicht bekannt, ob für sowas entspr. Filesystem-Unterstützung existiert bzw. ob das irgendwo möglich ist.

Wie auch immer, wer hier wirklich bloss Probleme mit dem Topf-Header als "Datenmüll" vornedran hat (hab den Thread jetzt nicht gelesen), der könnte tats. mit topf2mivx glücklich werden - wenn er es ggf. für Windows (so gewünscht) übersetzt bekommt und vielleicht noch die Umbenennung in .rec.ts ausbaut. Der Source findet sich jedenfalls im verlinkten Posting auf hdd-player.de

[jkIT]

Selbiges (oder ähnliches) macht TFtool bei "Extras -> Patch Header -> toTS".

Von der Möglichkeit, am Anfang einer Datei etwas abzuschneiden ohne umkopieren, habe ich auch noch nichts gehört.

[ragtime]

Hey, cool! Das Feature kannte ich noch gar nicht... :

Wobei mir ein kleines Linux Tool ja schon lieber waere,... hifans Code bringt naemlich zumindest den VLC nicht dazu 4000er Files abzuspielen... aber du kannst mir bestimmt sagen, wie lang bei denen der Header ist, damit ich weiss wieviele Nullen ich schreiben muss, oder?

[jkIT]

Der Header vom 4000er ist 564 Bytes lang. Obs für den VLC hilft weis ich aber nicht.

[ragtime]

Danke... also 3 TS Pakete!
Bisher hilft es fuer den VLC allerdings tatsaechlich nix...

Musste in hifan's code an div. Stellen ne hartkodierte 20 durch 3 (nun variabel) ersetzen... ohne zu wissen was er genau tut... soweit ich gesehen hab, nur hinter den Header springen. Aber was weiss ich, wo er implizit noch ueberall von der 5000er Struktur Gebrauch macht...

Im Moment schmirt er auch bei manchen Files ab, weil das TS-Paket danach nicht mit "0x47" anfaengt... weshalb das nicht bei allen Files passiert... K.A.... hifan?

Naja, ein Versuch war's wert... is ja auch nicht so dringend! War mehr akademischer Natur...

[jkIT]

Ich würde folgende Bytes pro TS-Packet versuchen

Code: Alles auswählen

0x47      sync
0x1F
0xFF      Null-Packet PID
0x00      Rest
...

Im Moment schmirt er auch bei manchen Files ab, weil das TS-Paket danach nicht mit "0x47" anfaengt... weshalb das nicht bei allen Files passiert... K.A.... hifan?

Am TF geschnitten?

[ragtime]

Fast exakt damit ueberschreibt hifan auch den header, allerdings hat er als 4. Wort noch die 0x11 bevor die Nullen anfangen... leider geizt der Gute etwas mit Kommentarzeilen (wie so mach anderer auch, dessen Code ich in die Finger kriege).

Das Problem ist aber, dass er mit dem Ueberschreiben gar nicht erst anfaengt, wenn nach dem header das naechste TS-Paket nicht auch mit 0x47 anfaengt,... kann schon sein das die Files am Topf geschnitten wurden... sind so Schnipsel die hier auf meiner PC-platte noch rumlagen.

Meinst du, da hab ich ev. mitten in nem TS-Paket geschnitten und der Stream faengt nach dem Header erst mit dem verkrueppelten Rest an... hmmmm...in dem Fall muesste man ja nur max. 188 bytes weitersuchen, bis man ne 0x47 findet, oder?

[jkIT]

[quote=""ragtime""]Fast exakt damit ueberschreibt hifan auch den header, allerdings hat er als 4. Wort noch die 0x11 bevor die Nullen anfangen... leider geizt der Gute etwas mit Kommentarzeilen (wie so mach anderer auch, dessen Code ich in die Finger kriege). [/quote]
Das 0x11 (binär 0001 0001) bedeutet
00 nicht verschlüsselt
01 kein "adaption field" nur "payload data" (*)
0001 ist der contínuity counter (0-15)
(*) hier habe ich 00 genommen (reserved) : "ITU-T Rec. H.222.0 | ISO/IEC 13818-1 decoders shall discard Transport Stream packets with the
adaptation_field_control field set to a value of '00'. In the case of a null packet the value of the adaptation_field_control
shall be set to '01'."

[quote=""ragtime""] Meinst du, da hab ich ev. mitten in nem TS-Paket geschnitten und der Stream faengt nach dem Header erst mit dem verkrueppelten Rest an...[/quote]
Das hängt mit der Clustergröße am TF4000 zusammen, die kein vielfaches von 188 ist (im Gegensatz zum 5000er).

[quote=""ragtime""] hmmmm...in dem Fall muesste man ja nur max. 188 bytes weitersuchen, bis man ne 0x47 findet, oder?[/quote]
Ja.

[ragtime]

Ah jetzt ja... sehr erhellend... langsam werd ich noch zum TF-TS-Experten!

Hab bisher Files mit 0,1,2,3 kaputten Paketen gefunden, bevor das 188byte-Raster kam. VLC spielt die Files aber trotzdem nicht.. naja,... jetzt kann das Dingens wenigstens (wahlweise) auch 4000er Files fuer den Mvix fit machen, falls das mal jemand braucht...