Thema: Wozu dient der PVA Aufnahmemodus...

[oxmox]

bzw. was fange ich damit an?

Habe probehalber mal was in dem Format aufgenommen.
Doch keines meiner Proggis konnte die verwerten.

[SiLæncer]

Die Unterschiede zu .mpg bestehen hauptsächlich im den Header die vor den Audio / Videopaketen hängen und deren Informationen. (siehe auch im PDF welches ich unten angehängt habe)

http://de.wikipedia.org/wiki/PVA_%28Format%29

btw. wenn du Fehlerfrei in .mpg aufnehmen kannst macht die PVA Aufnahme eh keinen Sinn ...hängt aber letztlich davon ab welche Tools du hinterher zur Verarbeitung nutzt...

btw.

Also das Aufnahmen in PVA grundsätzlich besser sind als solche in MPG bzw. VDR oder was auch immer, ist IMO ein "Ammenmärchen".
Wesentlich hierbei ist, welche Soft- bzw. Firmware das Format erzeugt.
Abhängig davon hat jedes seine Vor- und Nachteile bei der Weiterverwendung.

Datenlieferant ist bei allen der Transportstrom.
Je nach gewählter PID werden hieraus die A/V-Elementarströme usw. gefiltert.
Jedes erfolgreich synchronisierte Transport-Paket (übl. 188bytes) enthält u.a. einen Indikator (und NUR da) , ob es einen nicht behebbaren Bitfehler inne hat; einen Continuity-Zähler (0..15, Kennung ob Pakete fehlen, oder wiederholt übertragen wurden, z.B. bei Data -> unübl. bei A/V); sowie den Startcode, wenn z.B. ein neues PES-Paket beginnt (übl. 1 Paket mit Zeitstempel je Videoframe, bzw. je 5 Audioframes).
Der genannte Error-Indikator ist eigentlich die einzigst sichere Info, ob ein Datenfehler bei der Dekodierung zu erwarten ist. Nur wird diese Info weder im PVA noch MPG etc. integriert.

Die Uridee bei TT's PVA war IMO die direkte Auslese der Video- und Audiopuffer,
die noch die PES-(komprimierten)-Daten zum aktuell dekodierten Programm enthalten.
Hierbei werden ähnlich dem Transportstrom zwei IDs (1=V, 2=A, max 255 mögl.) generiert. V wird in <=6kB, A in <=2kB Häppchen je PVA-Paket geteilt und verschachtelt gespeichert.
V wird dabei seines eigentlichen PES-Headers "beraubt" und ein enthaltener PTS PVA-kompatibel ersetzt. A behält das komplette original PES-Paket.
Beide bekommen den zusätzl. PVA-Header vorne dran. Dieser enthält als wesentlich verwertbar nur das PVA-Syncword + ID, einen Zähler (0..255), sowie ebenso nen Startcode (wenn bei A unmittelbar ein PES-Header folgt, bzw. bei V ein umgebauter Zeitstempel).
Dieser Zähler nutzt n.m.E. aber nicht viel:
Es werden nur die im Puffer enthaltenen Daten mitgezählt. Sind die aber garnicht erst dort angekommen, ist zwar der Zähler lückenlos, aber es fehlen trotzdem Daten. (dann sah man das übl. auch aufm Schirm)
Andersrum waren zwar alle Daten im Puffer (und halt auch fehlerlos aufm Schirm), die Platte kam beim Schreiben aber nicht mit bzw. der Puffer wurde nicht richtig ausgelesen, weshalb dann z.B. ein Paket(-zähler) fehlte.
(Auch im PES-Paket kann's einen Zähler geben, der wird aber IMO seltenst benutzt)
Im übrigen kann IMO ein MPEG Decoder (A wie V) gar keine Fehler reparieren, allenfalls maskieren, da nehmen sich aber die Onchip-Version und als Software nichts.

Im Fall von MPG / VDR kann man dagegen die original PES-Pakete so nehmen, wie sie eh schon sind (mit minimalen Anpassungen, insbes. der Größe wegen zusätzl. Header ergänzen) und fortschreiben.
Kann sein, dass die aktuellen TT-WDM Treiber da schon keinen Unterschied mehr machen, d.h. PVA + MPG auf gleiche Weise erzeugen, womit am Ende keins besser oder schlechter ist.
(Bei PVA wird ja am Videostrom mehr manipuliert, womit dann theoret. mehr Fehler passieren können; zum anderen geht dabei auch noch der DTS hops)
Es ist eher so, dass für MPG/VDR die geringsten Anpassungen am original PES getätigt werden müssen. (bei MPG zusätzl. Pack-Header)
Der IMO einzigste Vorteil von PVA ist noch, das dort viele verschiedene, aber auch absolut identische, Ströme sicher getrennt untergebracht werden können (MPA, AC3, PCM, subpics etc.), was bei den anderen nicht ohne weiteres direkt möglich ist (auch in der Anzahl).
Zudem gibts für solche Sondersachen keinen Player (De-/Muxer aber schon).

k.A. ob jetzt nicht sogar alle Treiber die Daten per direktem Transportstromdemultiplex schreiben (ohne Umweg über die eingebauten Hardware-A/V-Puffer). Bei mehr als 1* V und 1* MPA, wie z.B. zusätzl. AC3 ist das ohnehin der einzigste Weg.
Also keines der Formate (und insbes. PVA nicht) ist eine "echte" 1:1 Kopie des Datenstroms.
Die "sicherste" 1:1-Methode wäre die Kopie des partiären Transportstroms vom gewählten Programm, das wird aber durch die meiste Hardware von DVB-Karten geblockt (die Umleitung via CAM bei PayTV kommt ja auch noch hinzu)

Wichtig ist also wie o.g. 'ne stabile API/Treiber, die auch bei hohen Bitraten lückenlos die PIDs filtern und a bissl angepaßt auf Platte schreiben kann.

Doch keines meiner Proggis konnte die verwerten.

Dann fehlen dir wohl noch so einige essentielle Dinge Da schaust du am besten mal in die Nachbearbeitungssektionen...