Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Anzeige

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Mit per ProjectX erzeugten TS-Dateien habe ich bisher noch nicht experimentiert.

Die beiden Fehlermeldungen haben mich aber auf einen Fehler im Programm aufmerksam gemacht. Dadurch wurde dann wohl keine korrekte PMT-PID gefunden und deshalb auch keine PMT. Da keine PMT gefunden wurde, wurde keine PCR-PID gefunden. Deshalb konnte die Dauer nicht ermittelt werden und in den Comag-Info-Blöcke wurde keine korrekte Laufzeit eingetragen. Außerdem ist dann auch in der meta.dat die Laufzeit falsch. Ich hoffe, ich habe den Fehler gefunden und korrigiert. Für Tests mit der neuen Version hatte ich noch keine Zeit.

Ich verwende die offizielle 3.8, die ich über die FAQ bezogen habe.

ffmpeg schreibt regelmäßig (AFAIR alle 20ms) einen neuen PCR. Das braucht jeweils min. 9 Byte. Der Vorteil dabei ist, dass man mit dem PCR eine recht gute Zeitbasis hat. Wobei ich an der Stelle noch ein Verständnisproblem habe, denn eigentlich hatte ich erwartet, dass der PCR ein 27 MHz-Wert ist. Es zeigt sich aber, dass die Ergebnisse weit besser sind, wenn ich die damit ermittelte Dauer mit 2 multipliziere.

Beim ffmpeg-Patch verwende ich statt des PCR übrigens PTS als Zeitbasis. createrec übernimmt die Zeitlinie der mit »ffmpeg -f mpegtscomagenc« erzeugten Comag-Info-Blöcke dann auch. Es wird nur die Split-Größe im Header korrigiert. Dadurch ist createrc dann nochmal erheblich schneller. Wenn Du meinen ffmpeg-Patch verwendest, kannst Du den Titel der Aufnahme per »-metadata title="Das ist der Titel"« angeben. In dem Fall wird die Option »--title« von createrec ignoriert. Wenn Du das nicht willst, musst Du Option "--forceextended" verwenden. Das gilt entsprechende für die Sprachoption (die Sprache eines AUDIO-streams kann man bei ffmpeg per »-alang=ger« setzen).

createrec ist übrigens keine besondere Leistung. Nachdem ich aus den von GDRGuy69 aufbereiteten Quellen zwei bisher fragliche Daten ermitteln konnte, basiert createrec eigentlich nur auf der daraus entstandene Doku und ein wenig ISO/IEC 13818-1.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Ja, genau, der war in Deiner vorherigen Version auch schon identifizierbar. Weil der Wert eigentlich konstant ist, weil der Receiver immer an der gleichen stelle aufteilt, ich aber einen Tippfehler an der Stelle in meinem Programm hatte, hatte ich stundenlang das Problem, dass der Receiver beim Abspielen meiner erzeugten rec-Ordner an der Split-Grenze nicht zur nächsten Datei weitergeschaltet hat. Ich hatte dann in Deinen Quellen einen Hinweis auf diesen Wert entdeckt und so meinen Fehler gefunden. Ohne das hätte ich noch ein paar Stunden nach meinem Fehler gesucht.

Ich glaube, bei früheren Firmware-Versionen war der kleiner. Wenn ich mich recht erinnern kann, waren dort die einzelnen Dateien nicht etwas weniger als 2GB, sondern als 1GB groß. Außerdem kommt der Receiver offenbar auch mit anderen Werten zurecht, sie müssen nur stimmen. Wenn man also ein anderes Dateisystem hätte, bei denen das Aufteilen der TS-Datei überflüssig wäre, wäre an der Stelle ggf. ein entsprechend großer Wert einzusetzen (der darf übrigens auch größer als die tatsächliche chunk-Größe sein. Ob man das Ding jetzt »Chunk« oder »Section« nennt ist mir völlig egal. Ich habe beim Schreiben der Doku einen Namen dafür gebraucht und eben »Section« verwendet.

Wenn ich es richtig sehe, fehlt mir Dank Deiner Arbeit nun nur noch das Verständnis für den Wert bei 88. Bei dem erschließt sich mir einfach keine Logik. Mir scheint allerdings, dass der Receiver den zum Abspielen aber auch nicht wirklich braucht. Jedenfalls kann ich in den von mir erzeugten Aufnahmen problemlos blättern und spulen, auch wenn in der Stelle immer eine 0x00000000 steht.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

In der 3.6L, auf der meine Quellen basieren, wird nach dem Starten einer Aufnahme folgender Code aufgerufen (zum Glück war SindiTV so nett, keine Optimierung beim Compilieren einzuschalten, sonst wäre mir das garnicht aufgefallen )

if (storageMedium == 1)
{
fdvr_set_split_size(r17->fdvrRec, FDVR_CHUNKS_FOR_2GB);
}
else
{
fdvr_set_split_size(r17->fdvrRec, FDVR_CHUNKS_FOR_2GB);
}

wobei:

#define FDVR_CHUNKS_FOR_2GB ((unsigned)(2048*1024*1024)/(512*188))

und storageMedium == 1 (USB)

Vielleicht hatte man früher unterschiedliche Split-Grössen für interne HDD und USB.

Mal sehen. Ich habe zwar das Gebiet Aufnahme/Wiedergabe schon etwas vernachlässigt, aber ich kann ja noch mal schauen.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Ich aber !

Ich habe mir das gestern angeschaut und bin zu dem gleichen Ergebnis gekommen.Ich habe es dann bei mir geändert. Wenn man bei PjX in den
Einstellungen -> Erweitert-> generiere PCR/SCR anwählt
kann createrec damit arbeiten.

Das kann aber nicht diesen Zuwachs von mehr als 1Gb erklären.

Das Ergebnis ist Laufzeit der Aufnahme ?
Die Laufzeit aus PCR/PTS kann IMHO bei geschnittenen Aufnahmen (nicht nur Anfang und Ende) nicht funktionieren.PCR/PTS müßten ja nach der Schnittstelle wieder korrigiert werden.
PjX führt nach einem demux eine Zeitanpassung durch. Ob dort diese PTS/PCR Werte korrigiert werden habe ich noch nicht überprüft.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Nö, aber bist Du sicher, dass Du den Audio- und Video-Stream nur kopiert und nicht recodiert hast? Beim Kopieren werden AFAIK zwar die Frames von ffmpeg ausgepackt und dann im neuen Containerformat wieder eingepackt, und dabei auch neu mit PCR und PTS/DTS versehen (und bei Verwendung von mpegtscomagenc auch gleich die Comag-Info-Blöcke mit erzeugt), aber eben nicht rekodiert. BTW: Von mpegtscomagenc werden ja alle 509 Quellpakete drei Pakete Comag-Info-Block eingefügt. Wenn Du also mpegtscomag verwendest, wird die ts-Datei, die Du mit PjX erzeugt hast, durchaus signifikant größer. Dafür wird sie aber später bei der Bearbeitung mit createrec nicht mehr größer.

Hm, die Schnittsoftware, die ich so verwende, korrigiert PCR und DTS aber. Das sollte eigentlich auch passieren. Wenn man sich darauf nicht verlassen kann, muss man tatsächlich eine Vorverarbeitung durchführen, die genau das macht. ffmpeg generiert die bei Verwendung der copy-Codecs ja ebenfalls neu (und ist dabei extrem schnell), so dass eine Vorverarbeitung damit ein korrektes Ergebnis liefern sollte. createrec kann das nicht leisten. Dazu müsste es die Streams in frames auspacken, um dann aus der Framerate die Zeit zu ermitteln und neue Streams zu generieren. Das ist aber nicht Aufgabe des Programms. Aufgabe des Programms ist eine korrekte ts-Datei für den Receiver aufzubereiten. Natürlich könnte man eine Demuxer/Muxer-Schleife basierend auf dem Code von ffmpeg, also unter Nutzung von libavformat/libavcodec einbauen, aber genauso gut kann man in den Produktionsablauf einen vorherigen Demuxer/Muxer-Aufruf mit dem Programm seiner Wahl einfügen, bevor man createrec aufruft.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo !

Genau das war mein Problem. Mit copy ist ffmpeg wirklich schnell. ABER jetzt hat ffmpeg Probleme die Laufzeit zu ermitteln. Hatte gerade einen Film umgewandelt von ~zwei Stunden -> ffmpeg hat über 14 std. angezeigt. Vormaterial war von PjX.(Mediainfo zeigt das beim Vormaterial von PjX auch an, also ist da wohl PjX der Schuldige.)
Zweites Problem mit ffmpeg ist der Ton. Das leiert ähnlich wie bei einer USB-Aufnahme.

Kann ich mir ehrlich gesagt nicht vorstellen, dafür ist es zu schnell.

Darf man fragen, welche Schnittsoftware Du verwendest ?
PjX macht diese Korrekturen mit Sicherheit nicht. Habe ich gestern überprüft.

Ich werde gleich noch einen Film mit Pjx und createtrc umwandeln und das Ergebnis mir mal anschauen.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Bezüglich PCR hast Du insofern recht, als im adaptation_field eine Discontinuität signalisiert werden kann ─ wenn ich das richtig verstanden habe. Eventuell gibt es das bei den bereits am Receiver geschnittenen Aufnahmen. Bei meinen selbst geschnittenen konnte ich das bisher aber nicht finden. Das liegt wohl hauptsächlich daran, dass ich i.d.R. Software wie avidemux2 verwende, die per libavformat die Streams verpackt und diese wohl tatsächlich den PCR bei jedem Video-Stream-PES-Paket neu schreibt und dabei auch noch mit dem DTS vergleicht (siehe Funktion mpegts_write_pes in mpegtsenc.c oder mpegtscomagenc.c).

Da ist dann eventuell auch noch ein Fehler in mpegtscomagenc.c, weil dort die Bitrate nicht korrekt berechnet wird. In mpegtsenc.c wurde AFAIR im Repository kürzlich ebenfalls ein Berechnungsfehler korrigiert. Eventuell kommt der leiernde Ton daher. Ich selbst konnte den bisher aber nicht feststellen.

Aus Zeitgründen kann ich dazu im Augenblick nicht mehr sagen.

BTW: Ich habe einen Teststream mit output-example (siehe ffmpeg-Sourcen) erzeugt, indem ich dort ein paar kleinere Änderungen vorgenommen habe (width, height, duration, Sinusgenerator). Mit dem werde ich demnächst auch noch ein wenig testen. Eventuell werde ich auch einen Stream mit gleichbleibendem Ton erzeugen, weil man daran dann Wedergabeprobleme recht gut erkennen kann.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

So, inzwischen habe ich mir die Zeit genommen, die Kritik aufzugreifen. Das hat zu einem kompletten Redesign von createrec geführt. Das Programm hat jetzt ein GTK-GUI und verwendet nicht mehr PCR, PTS oder DTS, sondern fragt unter Verwendung von libavcodec und libavformat die Codec nach der Dauer der Pakete und summiert diese auf. Das müsste eigentlich ziemlich genau sein. Außerdem ruft das Programm selbständig ffmpeg auf, um die Videodatei umzukodieren, falls die Ausgangsdatei nicht als MPEG TS vorliegt. Dabei wird nach Möglichkeit auf copy-Codecs zurückgegriffen (beispielsweise bei Ausgangsmaterial als MPEG PS mit mpeg2video und mpeg Sound).

Ich bitte zu beachten, dass es sich hier noch immer um eine frühe Beta-Version handelt. Deshalb existiert derzeit auch noch kein Command-Line-Interface, keine Anleitung und an diversen Stellen steht im Source noch ToDo oder FixMe. Immerhin hat das Programm bei mehreren meiner Tests gut funktioniert. Es ist aber etwas langsamer als createrec (ohne "_gtk"). Wenn ich irgendwann die Zeit finde, werde ich eventuell noch eine Command-Line-Steuerung der GUI einbauen und ggf. ein alternatives Benutzerinterface ohne GUI implementieren. Außerdem gibt es in der GUI noch etwas Optimierungsspielraum (z. B. Fortschrittsanzeige nur dann aktualisieren, wenn ein Fortschritt von min. 0,5% - oder so - erreicht wird). Natürlich darf sich auch gerne jemand den Source nehmen, und darauf aufbauend etwas besseres bauen.

Mit einem Teststream habe ich allerdings herausgefunden, dass in unregelmäßigen Abständen ein gleichmäßiger Ton beim Abspielen über den Receiver kurz die Höhe (nach oben) verändert. Wenn ich den gleichen Stream stattdessen per mplayer oder xine abspiele, tritt das nicht auf. Eventuell gibt es beim Receiver Probleme, wenn der Gesamt-Bitstream keine konstante Rate besitzt. Man müsste in dem Fall dann eigentlich zusätzliche Null-Pakete einfügen, um die Konstanz herzustellen. Das würde den Stream aber aufblähen, was ich eigentlich gerade nicht will. Bei zwei echten Filmen, bei denen ich diesbezüglich genau hingehört habe, ist mir dieses Problem übrigens nicht aufgefallen. Es könnte also auch sein, dass das Problem ebenso mit Original-Aufnahmen auftritt, man es nur normalerweise nicht hört. Leider konnte ich keinen Kanal mit einem Testbild und konstantem Ton finden, den ich dazu testweise hätte aufnehmen können.

Anekdote am Rande: Bei der Konvertierung war mir zunächst ein Fehler unterlaufen, wodurch alle VIDEO- und AUDIO-Streams in der TS-Datei als AUDIO gekennzeichnet waren. Der Receiver hat dann nicht versucht, den Ton ohne Bild abzuspielen, sondern beim Abspielen konstant das Bild des eingestellten Senders angezeigt und keinen Ton abgespielt. In der Info-Anzeige hat sich der Fortschrittsbalken aber vorwärts bewegt wie beim schnellen Vorlauf. Das ganze wurde dann korrekt am Ende der Datei beendet. Der Receiver war in der Zeit auch noch bedienbar. Nur wenn ich das gleiche per USB-Stick abgespielt habe, war er praktisch unbedienbar. Dabei hat sich die schlechte Bedienbarkeit bei USB-Zugriffen noch extrem verstärkt. Das betrifft übrigens nicht nur die Fernbedienung. Auch das Tastenfeld am Gerät selbst wird dann nur noch sehr selten abgefragt.

Achja: Ich verwende neuerdings einen 8-GB-USB-Stick von Tevion (ALDI). Nachdem ich zuvor schon diverse Markenprodukte mit 8 und 16 GB erfolglos getestet hatte, funktioniert das Teil nun richtig gut. Der Stick ist nicht partitioniert, sondern im sog. Superformat (Laufwerk selbst trägt direkt ein Dateisystem). Witzigerweise zeigt mir der Receiver ein wenig Datenmüll beim Laufwerksnamen nach dem eigentlich Namen, während der Computer sowohl unter Linux als auch Windows nur den Namen zeigt. Der Stick ist halbwegs schnell und wird vom Receiver sehr gut erkannt. Einmal hat er mir allerdings Datensalat darauf produziert, der ein dosfsck notwendig gemacht hat.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo Markus !
Bei laufen weder die Aufnahmen auf dem Comag, die mit createrec_gtk und createrec_cli umgewandelt worden sind.
Wie hast Du die Stream aufbereitet.
Das gleiche TS-File mit createrec-1a läuft. Der Stream scheint also in ordnung zu sein.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Ich habe nichts besonders gemacht, sondern die ganze Arbeit in der Regel einfach createrec_gtk oder createrec_cli überlassen. Ich habe sowohl einen Testfilm, den ich mit dem output-example von ffmpeg erzeugt habe und der mal als MPEG TS mal als MPEG PS vorlag, damit umgewandelt als auch diverse Filme, die ich mit avidemux geschnitten und als MPEG PS neu kodiert hatte. Dabei habe ich bei avidemux das lavc-Backend für DVDs ausgewählt, das AFAIK ebenfalls auf ffmpeg bzw. dessen Bibliotheken libavformat/libavcodec basiert.

Mit welcher Version von libavformat/libavcodec hast Du createrec_* denn getestet? Ruft es korrekt ffmpeg auf, um ggf. einen MPEG TS zu erzeugen? Zeigt ffmpeg dabei vernünftige Daten an? Kürzlich wurde auf der ffmpeg-Entwickler-Mailingliste ein Problem mit dem Muxer mpegtsenc diskutiert. Das sollte aber inzwischen behoben sein.

Was ich bisher nicht gemacht habe: Eine mit ProjectX erzeugte MPEG TS createrec_* vorgelegt.

Ich hatte ja extra auf Deine Einwände bezüglich der Kontinuität der Zeitangaben im Stream die Ermittlung der Dauer auf komplett neue Beine gestellt, nämlich auf die tatsächlich von der Codec beim Lesen des Streams gemeldete Dauer der via av_read_frame (libavformat) gelesenen Frames. Diese Zeit soll laut ffmpeg-Entwickler korrekt und mit größter Genauigkeit - größer als wir sie brauchen - sein. Theoretisch könnte ich bei der Gelegenheit auch gleich noch testen, ob Video und Audio halbwegs synchron sind (z. B. Delay von max. ein Video-Frame). Mache ich derzeit aber nicht. Leider soll ich ich av_read_packet nicht verwenden, weil dessen Verwendung deprecated ist. Deshalb wird jede Datei doppelt eingelesen. Einmal direkt, um die Pakete selbst zu erhalten und einmal über libavformat via av_read_frame um die Laufzeit zu ermitteln.

Zumindest unter Linux scheint der Filesystem-Cache dabei gut zu funktionieren, so das das doppelte Einlesen weit weniger als doppelt so lange dauert wie das einfache.