Beiträge von dvb.matt

    Es wird davon ausgegangen, das die Teile von TS Aufnahmen immer zeitlich zusammenhängen, was hier nicht vorliegt.
    Das Zusammensetzen funktioniert aber nur unter diesen Voraussetzungen (deswegen klappte es manchmal, oder eben beim vertauschen).

    Die 2 Sachen waren eingestellt:

    ++> Untertitel: PID 0x17F3 / PesID 0xBD / SubID 0x20 :
    Multicolor ACTIVE / switches 000003E0 >>FROM GUI<<
    Multicolor: shw1Line=-1 shw1Pic=-1 noRepairs=true NoCOLCON=true SolidBgrd=true Shading=true OldClrs=true
    -> gewähltes DVB Untertitel Farbmodell: ZDFvision(mc) ; fixiert auf Seitennr.:

    Zusatz für ini-Datei vor dem nächsten Start
    Subpicture.S9Debug=3E0

    ulkig, das das .sup nicht verwertet wird, es entspricht vom Bildinhalt und Kodierung 1:1 der sup.sub

    das mit den B-Frames (hier vermutl. nicht closed) ist hier wohl nur Folgeerscheinung, das Grundproblem liegt in den häufigen Zeitsprüngen beim Wechsel der VOB Kapitel, wovon der Rec. wohl alle 60 GOPs ein neues anlegt. Das steht noch in der PjX-ToDo, hat aber geringe Priorität weils DVB-untypisch ist. (eher HDD-PVR typisch)

    Zitat von grua

    Mit ProjextX 0.81.9 bekam ich beim Demuxen des PVA nur einen stotternden Ton hin - nur das Bild war in Ordnung.

    Zitat von dvb.matt

    Entweder wird niemals dieses Pflicht-Flag gesetzt, oder nur unregelmäßig bei ein paar PVA-Paketen. Entsprechend kann bei PVA-getreuer Analyse die Tonspur nicht fehlerfrei ausgelesen werden. (-> vgl. Bild 2 im Thread).
    (deshalb die Wahloption in Pj.X dies ggf. abzuschalten)


    um bei vernünftigen (PVA)Aufnahmen keine Fehler zu produzieren, ist diese Option als Std. immer an. ("..PVA Audio standardgemäß..").
    die sollteste mal abschalten.

    ach herrje, da muss man wohl etwas weiter ausholen ;)

    vor etlichen Monaten hatte ich schon das zweifelhafte Vergnügen, einige problematische PVA-Daten von pdvb anzuschauen.

    Dabei fallen gleich mehrere Non-Konformitäten auf.

    Video:
    die besagten "E4" Pakete sind im Grunde die originalen PES-Kopfdaten von/vor jedem Bild aus dem Transportstrom.
    Aufgabe von pdvb wäre es, diese zu entfernen und entsprechend dem Zielformat umzuformen. Tut's aber nicht, daher bleiben die über.
    Stattdessen werden nur die PTS(Zeitstempel) ausgelesen und neue PES-Kopfdaten noch obendrauf gesetzt. (bzw. im PVA-Fall nur PTS + PVA-Kopf).
    Da wir jetzt aber E0 bis EF im Quellvideostrom haben können, müsste rme4 auch diese erkennen und entfernen/patchen. aber es heißt ja nun rme4 und wird wohl daher nur E4 entfernen (was IMO unzureichend wäre) /E1 s.u.
    Da es in Pj.X nicht vorgesehen ist, Fehler stillschweigend zu 'schlucken', wird hier eben jeder gemeldet. Das macht's natürlich langsam (dem durch abschalten der Meldungen aber entgegengewirkt werden kann), zeigt zudem die Masse an Fehlern im Strom (jedes Bildpaket halt muß bereinigt werden -> vgl. Bild 1 im Thread).
    Pj.X ist daher (weiß nich mehr seit wann) darauf eingestellt, dieses "E4" Problem zu beheben, jedoch nicht nur "E4" s.o.

    man wage nicht dran zu denken, wenn pdvb auch noch die Zeitstempel gegen 0 neu umrechnen würde, was es zzt. noch nicht macht..

    die 'grünen Klötze' sind ja nun wieder ganz anderen Ursprungs, lediglich Zoran hat hier wohl in seiner FW für MpegDecoder ein Problem.
    wobei die ARD nach letztem Stand tlw. ihre Encoder diesbzgl. mit geänderter FW (von SA) (resultierend aus unseren Tests dazu) umstellen wird.

    Audio:
    im PVA-Format ist für Ton spezifiziert, dass jedes darin verpackte originale (nicht Video-) PES-Paket im vorangestellten PVA-Kopf mit einem Flag angekündigt wird (vgl. TS-Pakete) und zwar mit jedem neu begonnenen Paket. Das originale Paket incl PES-Kopf hat dabei unmittelbar dem PVA-Kopf zu folgen, bei Überschreitung der max. Paketgröße darf eine Teilung in mehrere erfolgen, die weiteren dann natürlich ohne PES-Kopf.
    was passiert nun hier?
    Entweder wird niemals dieses Pflicht-Flag gesetzt, oder nur unregelmäßig bei ein paar PVA-Paketen. Entsprechend kann bei PVA-getreuer Analyse die Tonspur nicht fehlerfrei ausgelesen werden. (-> vgl. Bild 2 im Thread).
    (deshalb die Wahloption in Pj.X dies ggf. abzuschalten)

    Auch hier gibt es noch div. andere Negativbeispiele (frühere Multidec-Streamengines bspw. waren in dieser Hinsicht extrem instabil und Quell von üblen Aufnahmen).
    So kommt/kam es z.B. auch vor, dass im (falschen) PVA-Format eine Tonspur-ID, die bspw. bei arte eigentlich "C3" hat, von der Streamingengine in einem PVA-Paket die korrekte "C3" für den PES-Kopf behielt, im nächsten jedoch wiederum "C0" (weil dies ja wohl Standard ist, nur halt in dem Fall garnicht so im Original vorhanden) an dieser Stelle aber absolut unpassend, zudem natürlich ohne 'Flag' und viell. sogar noch um ein paar Bytes 'verrutscht'.

    was also soll man dazu noch sagen, als dass man solche Fehler IMO nicht 'verschweigen' sollte bei der Abarbeitung in einem Tool, denn sonst gewinnt man nur einen falschen Eindruck..

    und wenn wir schon dabei sind ;)
    Hauppauge scheint es auch mit der aktuellsten SW 2.18 für z.B. ihre DEC-Produktreihe nicht hinbekommen zu haben, die Größe der AC3-Pakete korrekt anzugeben, stattdessen immer noch mit 6Byte zuviel. Sowohl im Mpg als auch als separate Datei, die im übrigen zwar .ac3 heißt, aber auch noch im (fehlerhaften) PES-Format vorliegt.

    /E1
    aus dem dvdboard zu rme4:
    Tatsächlich entfernt RME4 sogar alle Pakete, deren Syncwort zwischen 000001E0 und 000001EF liegt, also alle Pakete, die als PES-Header eine Zeitangabe enthalten könnten.
    hieraus ist jedoch nicht ganz ersichtlich, ob auch 'vergessene' PES-Köpfe 'ohne Zeitangabe' tatsächlich behandelt werden, was ein weiterer Fehler sein kann. Pj.X schenkt dem Sonderfall dann zumindest auch seine Aufmerksamkeit..

    moin,
    ich heiß' mich mal selbst hier willkommen ;)

    --

    zum Thema:
    sowas kommt davon, wenn man progdvb verwendet..
    Thread1 und Thread2 aufmerksam 'studieren', eigne Meinung bilden.. (und dann die o.a. Meldungen abschalten)

    diese Meldungen sollen dem Benutzer das Problem verdeutlichen (welches _nicht_ von Übertragungsfehlern herrührt, sondern eben neu erzeugt wird) und im nächsten Schritt die Entscheidung erleichtern, das Recording-Tool zu wechseln..

    btw: die angesprochene erweiterte 'Speicherfreigabe' bringt hier IMHO nicht wirklich was.. (der Abbruch erfolgt nur später)