http://satellite-board.de

WinPVR auch für Video Raw
Hi,
jetzt könnt ihr alle mit der Spezialversion WinPVRRaw070 experimentieren. Zu finden unter http://www.radonmaster.de/pvr-ripper/

Es ist der aktuelle Hard-Disk Ripper für Rohdaten von Boom und Andal, eine Spezialversion von WinPVR0.7.0. Er erlaubt es, neben den Audiodaten auch die Videodaten "raw" auszugeben. Die Rohdaten können von Programmen weiterverarbeitet werden, die ursprünglich für andere Empfänger gedacht sind. Dazu gehören PVAStrumento und ds.jar. WinPVARaw läuft unter Win2000, NT oder XP. Es funktioniert nicht unter Win95/98.

Viel Erfolg!

hab ich richtig gelesen -> Videoraw speichern als .pva ? (also das Spezialformat von TT vom TI-Chip)

mfg

Yes Sir,
so hat Andal es benannt und so steht es hinterher auf der HD. Und ds.jar kann damit leben (xxx.pva und xxx.mpp hinein - xxx.m2v und xxx.mp2 heraus). Allerdings braucht es sehr viel Zeit. Auf meinem 400MHz-PC 2/3 Echtzeit bei kleiner Premiere-Datenrate. Wäre es günstiger, dem einen anderen Namen zu geben?

na wie jetzt?
nach PVA benannt, aber ist nicht in so'nem Format?
das ist arg ungünstig.
der Name/Extension ansich spielt (für ds.) keine Rolle.

was zeigt'n ds. fürn Typ an? im filemenü!
(hab ich doch schon paarmal nach gefragt... )
hier hält man sich ja (leider) sehr bedeckt darüber...

ich schätze "PES (...) !Vpacketsize0"
das ist eigentl. nur ne Notlösungs-Unterstützung, weil wiederum fehleranfälliger, weil man nicht von Pack zu Pack springen kann, sondern die passenden Header suchen muß. (Mißdeutungen möglich!)

das würde dann den langen Parsevorgang erklären , und vermittelt viell. einen falschen Eindruck!
Besser ist, wenn die PES-Packsize Einträge für Video schon beim Rippen gesetzt werden.. (die größer 0xFFF8) zusätzl. geteilt. (weil vom original TS genommen stehen die ja auf "0")
beim .m2v demux-Ripp muß das doch auch "behandelt" werden

klärt mich doch mal auf

mfg

Ich habe es PVA getauft, weil es wie die Streams von der DVB-Karte mit PES-Daten daherkommt (also Zeitmarken). Ich glaube nicht, dass PVA an sich etwas besonders TT-bezogenes ist. PVAStrumento kann mit dem Stream nichts anfangen. Der Elecard MPEG Decoder spielt das File aber als Video ab. Nur die Laufzeit zeigt er überhaupt nicht richtig an. Aber das scheint ein allgemeines Problem von Transport Streams zu sein.

@dvb.matt
Scheisse ich habe jetzt 5 Minuten gegrübelt, was ich schreiben soll. Es ist halt so schwer um etwas zu bitten.
Kannst Du mir etwas - eine Vorgehensweise geben wie Du den Stream ausliest. Wie Du vielleicht weisst, habe ich noch Probleme mit diversen Audiostreams und natürlich mit kaputten Videostreams. Wie gehst Du da vor. Ich will Dich damit nicht Arbeitslos machen, aber da der Stream auf der Platte des Hunni eh schon demuxt vorliegt ist es eigentlich ein Unding ihn erst roh auf die Platte zu klatschen und dann durch Dein Tool durchzuschleusen.
Danke im Voraus (und wenn nicht verstehe ich das - wer gibt schon gern sein hart erarbeites Know How her)

@robernd
Bei Dir schlägt das Java Monster zu. Die App ist eigentlich recht schnell. Aber nur, wenn Dein Proz das auch "daziagt" wie wir in Bayern sagen. Bei mir braucht ein 1:30:00 Film etwa 10 Minuten bis er geschaufelt ist. (Athlon XP 1600 + 512 MB)
Performancehinweis: nie auf der gleichen Platte operieren, sondern immer von einer Platte auf die Andere schaufeln. Das wirkt Wunder.

Servus,
Andal

.pva ist IMO deshalb ungünstig, weil der nächste DAU sicher versucht, das in PVACut zu laden zum schneiden, was dann nich gehen wird. (wenns kein PVA etc. ist)

@andal
jetz denk' ma nich, das ich soviel mehr weiß
ich denk' halt nur oft (und gern) quer...
das wär dann was für'ne PM Konversation...

aber nu verwirrst du einen doch total:
PVA -> PES (->PTS) -> Video -> Transport Stream -> Stream aufm Hunni schon demuxt ?
was liegt denn nun in echt aufm Hunni/Kathy..?

mfg

Tja,
das mit der Rechnerleistung ist ein Problem. Mit einem neuen PC zögere ich immer noch. Wahrscheinlich würde es mich 1 bis 2 Monate Kosten, bis alles wieder stabil läuft. Außerdem müsste ich meine heißgeliebte ISA-Harware wegwerfen (Creamware-Soundkarte mit Digital I/O und zugehöriger Software).

Nach meiner 2/3-Theorie würde mein PC Andals Film in ca. 1 h verarbeiten. Unter Berücksichtigung eines Faktors 4 bis 5 an Rechenleistung gegenüber 1.6 GHz würden die Zahlen schon zusammen passen. Von einer HD auf die andere ist auch selbstverständlich. Ich will ja schließlich keine HD künstlich altern
Bislang hatte ich die Erfahrung, dass Videobearbeitung (im Gegensatz zu Fotobearbeitung) nicht viel Speicher braucht (habe nur 128 MB). Ist das inzwischen urealistisch?
Gibt es ein Java Runtime-System, das schneller ist als die Sun-Software?

haaaallo, hört/liest mich denn keiner??

was ist denn das nun für ein Format/Type im Video.raw (Anzeige im ds. filemenü)
Das ist mitentscheidend für die Geschwindigkeit in ds. (s.o. im Thread)
(mir könnt's ja egal sein.....) ..nochmal frag ich nicht.


JRE von IBM ist wohl aufm Mac schneller..

Hi dvb.matt

Also, ich hab's rasch ausprobiert:


Die ganze "Demux"-Aktion dauerte für gut 1,1GB übrigens 4'23", auf einem P4/1,8/512, und das mit identischem Start-/Zielverzeichnis.

Grüsse
audio-freak

Aus Neugier habe ich noch die als ES (also nicht RAW) gerippten Files mit ds.jar "demuxt":


Das Ganze dauerte 2'42". Beide Versionen liessen sich muxen, sind synchron und scheinen i.O. zu sein (nicht 1:1 kontrolliert).

Die unbearbeiteten ES von WinPVR liessen sich zwar mit bbMPEG muxen (TMPGEnc weigerte sich: Illegal MPEG audiostream), doch fehlt beim Abspielen der Ton. Öffnet man das mp2-File von WinPVR aber zuerst mit mp3DirectCut und speichert es neu ab, funktioniert das Muxen sowohl in bbMPEG als auch TMPGEnc einwandfrei.

Grüsse
audio-freak

yap.
das mit dem langsamen liegt an bereits o.g. Grund (Notlösung für einen Workaround wg. Aufnahmeproblemen der KNC One mit GlobeTV)

BTW: mein PC würde auch ewig rödeln.. aber gsd kann ich mit PVA,MPG arbeiten..

mfg

Also nochmal:
es geht schneller, wenn man zwei Platten hat. Ist ja auch logisch - eine liest, eine schreibt.
@ audio-freak: das waren doch nicht 1.1 MB sondern 1.1 GB ?
Ich glaube auch, dass Du Glück gehabt hast, weil der Stream "sauber" war. Ansonsten glaube ich nicht, dass er mit dem Audiofile zusammengepasst hätte.

CU,
Andal

@andal
Sorry, natürlich waren es etwa 1,1GB, nicht MB (gemäss Log von ds.jar 1157780180 Bytes).

Selbstverständlich geht es schneller, wenn man von Platte zu Platte schreibt - aber nicht immer. Bei rechenintensiven Jobs spielt das nämlich kaum eine Rolle. Konkret: Das Konvertieren der RAW-Files dauerte hier mit identischem Start-/Zielverzeichnis 4'23", von Platte zu Platte 3'50", also 33 Sekunden oder etwa 12,5% schneller. Beim Encoden (TMPGEnc) kann ich - natürlich - überhaupt keinen Geschwindigkeitsvorteil mehr feststellen.

@dvb.matt
Also ich finde die 4'23" für 1,1GB RAW eigentlich ganz akzeptabel. Immerhin gibt's ja noch die Batch-Funktion, damit lässt sich's sicher auch mit älteren Rechnern arbeiten.

Grüsse
audio-freak

@Robernd
@andal

Ich hab mit dem Raw Ripper probleme beim AC3. Am ende eines Audio Rips mit AC3 Stream stürzt das Programm ab. Es ist eine Microsoft Visual C++ Runtime Library Melung: Runtime error in ...
abnormal Programm Termination.
Der AC3 stream steht aber als mpp vollständig da und lässt sich auch weiterverwenden.

Ich wollte meine UFD Platte mal leerräumen, und da hält die Jobverarbeitung immer an.

Vieleicht findet Ihr ja was.

By

Hi,
immer noch besser als ein laufendes Prog ohne Ergebnis
Ich kann dazu wenig sagen. Rippst du bis zum Ende? Versuch einmal einige sekunden vorher aufzuhören.
Wie wolltest du die Platte leerräumen? Soweit ich weiß, geht das mit WinPVR nicht. Nur mit Disk-Editor oder Cleandrive.