Beiträge von bitstreamout

  • [ANNOUNCE] bitstreamout plugin 0.85 (AC3 loop through sound card)


    Der ist inzwischen eingeflossen. Der Weg über die Verbindung S/P-DIF out der
    DVB-Karte zum S/P-DIF in der Soundkarte ist für Mpeg-Audio und hat den
    grossen Vorteil, Synchron zu sein. DTS/DD dagegen sollten über den PCI
    Bus von bitstreamout plugin zur Soudnkarte geschickt werden.


    Wirf doch mal einen Blick in das Howto von Viking :D


      Werner

  • Neue Testversion F32623 für AV7110 firmware

    Zitat

    Original von Zimbo
    Danke, Werner, nur noch einen zum Verständnis:


    Demnach müsste das Signal auch bei Aufnahmen genauso abreißen, da das der 1:1 Strom vom Satelliten ist ?


    Noe, der Stream ist zwar 1:1, aber kommt von der Platte und wird mit dem
    Zeitnormal des PC's eingelesen und mit diesem neuen Zeitnorma bzw.
    mit der sich daraus ergebende Datenrate zur DVB-Karte und der Soundkarte
    weitergegeben. Und die Quarze liegen normalerweise nicht weit auseinander.
    Aber auch hier kann ein Unterschied im Zeitnormal zum Problem führen, nicht
    umsonst haben professionelle Soundkarten eine Einstellung, in der sie das
    Zeitnormal extern bekommen.


    Zitat


    Kann man da evtl mit einem geeigneterem ALSA Treiber noch etwas rausholen ? Wenn ich das richtig gesehen habe, läuft der auf dem Board verbaute Realtek Sound mit einem Intel Treiber (AC97).


    Da bräuchtest Du schon einen Lötkolben, eine ruhige Hand und eine veränderbaren
    SMD-Spule oder verändernbaren SMD-Kondesator, um den Schwingkreis des Quarz
    und dessen Normalfrequenz besser stimmen zu können. Oder eine professionelle
    Soundkarte mit internen S/P-DIF TTL-Eingang, der auch das Zeitnormal liefern kann.


      Werner

  • Neue Testversion F32623 für AV7110 firmware


    Eher mit der Soundkarte bzw. dem Quarz darauf. Normalerweise versuche ich
    im Plugin den HW-Buffer der Soundkarte gut gefüllt zu halten, das ist einer der
    Gründe, warum 48ms sehr weh tun. Denn wenn der HW-Buffer leerläuft oder
    auch überläuft stoppen die Soundkarten normalerweise die Wiedergabe bzw.
    der ALSA-Treiber macht das. Bei LiveTV führt der Unterschied zwischen dem
    Zeitnormal des Senders und diesem Quarz entweder zum Underrun oder
    zum Overrun. Daher gibt es eine Option VariableIO, die auf yes gesetzt bei
    einem drohenden Underrun AC3 Frames mit gesetzten Errorflag wiederholt
    bzw. bei einem Overrun AC3 Frames auslässt. Wenn VariableIO auf no steht,
    kommt es zum Reset, d.h. `no' ist nur sinnvoll wenn zB weil die Soundkarte sich
    die Normalzeit vom S/P-DIF Out der DVB-Karte oder aus der Rate des Datenstrom
    holen kann oder die Soundkarte bzw. der ALSA-Treiber das besser machen.


      Werner

  • Neue Testversion F32623 für AV7110 firmware

    Zitat

    Original von Zimbo
    @Werner


    Wenn ich die Manpage richtig gelesen habe, kann ich wohl zusätzliche Wartezeit bis zum Streamoutput einfügen (Livedelay), aber selbst bei Null hinkt der Sound dem Bild schon hinterher. Gibt's da eine Lösung ?


    Du redest vom bitstreamout plugin und von Mpeg-Audio statt AC3?
    Da gibt es derzeit keine Lösung. Die libmad will den Startheader des
    nächsten Mpeg-Audio Frames parsen bevor es das gerade angekommene
    dekodieren möchte. Damit habe ich einen prinzipiellen Offset von 48ms,
    den ich irgendwie nicht umgehen kann.


    Bei AC3, also DD 2.0 und DD 5.1, habe ich das Problem nicht. Einer der
    Gründe, warum ich Mpeg-Audio über eine Verbindung vom S/P-DIF Out
    der DVB-Karte zum S/P-DIF In der Soundkarte führe, aber Achtung, der
    Ausgang der DVB-Karte hat einen Level von 5V, statt der für Koax
    üblichen 0.5V, d.h. die Soundkarte sollte mit diesem TTL-Signallevel
    auch umgehen können.


    Beside this: was hat den das mit der firmware zu tun?


      Werner

  • Neue Testversion F32623 für AV7110 firmware


    Auf den gleichen Transponder zurück zu springen, funktioniert und
    das obwohl es außer EuroNews keinen FTA-Sender auf 11817 vertikal
    gibt. Habe einfach den nächsten Sender `I>TELE' direkt angesprungen
    und bin dann vie `0' wieder zurück auf CNN.


    Beside this: Den langsamen OSD-Ausfbau kann ich nicht sehen, habe
    allerdings nur eine 1.5er 2MB-Karte. Aber eventuell liegt das an der
    von mir gewählten Art der Synchronisierung von Bild und Ton während
    des Starts des Senders. Ich denke darüber nach, wie man das verbessern
    kann, allerdings um die kurzen Störungen während des Umschaltens von
    Mpeg-Audio auf AC3 zu umgehen. Ob das auch hier hilft, weis ich nicht,
    immerhin ist es genau genommen eine Art Transfer auf der DVB-Karte
    und der hat Vorrang vor den OSD Daten ... schon wegen der
    Synchronisierung :D


      Werner

  • Neue Testversion F32623 für AV7110 firmware

    Zitat

    Original von UFO


    Teste doch mal, ob es genügt, auf den zuletzt funktionierenden _Transponder_ (d.h. einen beliebigen Sender dieses Transponders) zurückzuschalten. Falls ja, deutet es eher in Richtung Tuning-Problem/Frontend-Treiber.


    Was zeigt femon bei schwarzem Bild an?
    Verwendest Du DiSEqC?


    Also das mit dem Transponder, aber anderen Kanal habe ich noch nicht
    probiert, aber die Stärke des Signals und das Signal Noise Verhältnis ist
    identisch wie mit Bild und Ton. DiSEqC verwende ich zwar, aber das
    macht AFAIR keinen Unterschied, ob nun DiSEqC oder ob LNB frequency
    switching. Wenn es das naechste mal auftritt, dann werde ich mal
    nach einem Sender auf dem gleichen Transponder suchen und den
    ausprobieren.


      Werner

  • Werbung und non-I-Frame-Schnitt

    Zitat

    Original von dmh
    Also das Problem ist im Moment nicht die neuerzeugte GOP, das macht libavcodec schon ordentlich und funktioniert wohl auch. Könnte ihr (libavcodec) zwar sagen, dass nur I-Frames verwendet werden sollen, aber das brauche ich nicht, weil er eine neue abgeschlossene GOP erzeugt.


    Kann man die libavcodec eventuell dazu veranlassen, keinen geschlossenen
    GOPs zu produzieren, d.h. ihr das Referenzbild aus dem vorherigen GOP
    zu geben, damit sie die passenden B-Frames gleich mitliefert bzw. von
    selbst includiert?


    Zitat


    Das Problem ist, dass der Index der einzelnen Frames mit Hilfe der index.vdr-Datei berechnet wird und bei meinem jetzigen Verfahren versagt. Und zwar werden die Indizes der I-Frames nicht mehr richtig angezeigt und GOP-Größen nicht mehr richtig berechnet.


    Wie wird das den bisher gelöst? Die invalid B-Frames stehen in der index.vdr und
    werden durch das abgeschlossene GOP nicht abgespielt. Im Prinzip kann da also
    statt der echten B-Frames auch ein dummy B-Frame eingesetzt und die offsets im
    index.vdr passend korrigiert werden.


      Werner

  • Werbung und non-I-Frame-Schnitt

    Zitat

    Original von dmh
    Ich "leihe" mir einfach zwei vorhergehende B-Frames und packe sie an eine entsprechende Stelle mit PTS kleiner als die des neu generierten I-Frames. Dann sollte der VDR die auch nicht mehr spielen. Beim GOP genauen Schnitt hat man ja auch zwei B-Frames, welche nicht mehr dekodiert werden können und deren PTS kleiner ist als derjenige des ersten I-Frames. Jetzt ist natürlich die Frage, ob auch P-Frames in eine nachfolgende GOP dürfen?!?


    Wenn die GOP als geschlossen markiert wurde, sollte das funktionieren.
    Bei P-Frames dürfte das nicht funktionieren. Was spricht eigentlich
    dagegen, um die Schnittmarken herum, nur I-Frames zu verwenden?
    Wenn in einer GOP nur I-Frames auftreten hast Du die ganzen
    Probleme nicht. Wie man wegen der erhöhten Bandbreite aus I-Frames
    wieder eine IBBP-Sequenz ohne vollständige Dekodierung/Enkodierung
    macht, weis ich nicht (im Prinzip geht das). Aber eventuell ist es möglich
    einfach eine Sequenz von I-Frames um die Schnittmarken herum zu
    verwenden und auch abzuspielen. Damit fallen jedenfalls die Backward
    Referenzen der B-Frames weg.


      Werner

  • Neue Testversion F32623 für AV7110 firmware

    Ich beobachte wieder ein andere Phänomen. Beim Schalten von Euro-News
    auf CNN gekomme ich desöftern kein Bild. Früher tratt das beim Schalten von
    CNN auf n-tv auf. Es ist kein Absturz, sondern man muss auf den letzten sicht-
    baren Sender, also jetzt Euro-News zurückschalten, warten bis das Bild kommt
    und erst dananch kann man weiter zappen. Wenn man nicht auf den letzten
    sichtbaren (und hörbaren) Sender zurückschaltet, gibt's gar kein Bild bzw. Ton ;(


      Werner

  • Werbung und non-I-Frame-Schnitt


    Was hälst du davon, Deine eigene Liste zumindest für zwei, drei GOPs um
    die Schnittpunkte im Speicher zu halten? Scannen mußt Du ja sowieso, also
    warum nicht die Daten für spätere Schneiden vorhalten. Dürfte dem User
    kaum auffallen, dass da im Hintergrund vor dem bildweisen Verschieben der
    Schnittmarken ein Scanner und B/P-to-I-Frame-Transformator im Hintergrund
    läuft ... oder?


      Werner

  • VDR bleibt stehen bei Dolby Digital umschaltung


    Das hat meiner Meinung nach nichts mit der firmware zu tun. Es sieht
    für mich so aus, als ob der VDR zu lange auf etwas wartet und ihn
    daher der eigene Watchdog abschießt. Daher wäre es interessant
    die Version des VDRs, des Treiber und des Kernels zu erfahren.


      Werner

  • Werbung und non-I-Frame-Schnitt

    Zitat

    Original von dmh


    Ist zwar nur nebensächlich, interessiert mich aber im Moment. Habe gegoogelt nach "/dev/shm" und dabei herausbekommen, dass es "shared memory" bedeutet und hauptsächlich für Interprozesskommunikation verwendet wird. Da können wohl zwei Prozesse Daten über einen gemeinsamen Speicherbereich austauschen.


    Warum also /dev/shm? Oder kann man den auch als sehr schnellen Speicher verstehen, wie eine Art Ramdisk?


    Also /dev/shm/ ist ein tmpfs, in dem Du Dateien anlegen kannst. Das geht
    schon mit `echo xxx > /dev/shm/yyy'. Die Datei ist in einer Art Ramdisk
    enthalten, und läßt sich via mmap auch in den Speicherbereich eines
    Programms abbilden. Im bitstreamout plugin verwende ich das dazu, um
    grosse und kontinuierliche Speicherbereiche zu erhalten. Das Interface dazu
    ist in shm_memory_tool.c und shm_memory_tool.h enthalten. Der Zugriff
    ist schneller als über virtuelle Speicheradressen. Wenn Du keine Ramdisk
    möchtest, wäre eventuell posix_typed_mem_open(3) eine Alternative.


    Mit mmap() erspart man sich auch das Einlesen von Dateien von der Festplatte
    in einen Speicherbereich. Nur beim Parsen der Daten sollte man sich halt
    merken, was wo genau liegt und zu welcher relativen Adresse im gemappten
    Bereich.


      Werner

  • Werbung und non-I-Frame-Schnitt

    Zitat

    Original von rnissl
    ich hatte auch schon den Gedanken, die PES-Pakete aus den c*Repackern in separaten Puffern abzulegen, die Puffer dann der Reihe nach abzugrasen und jeweils das Paket mit den niedrigsten PTS weiterzureichen.


    Eventuell könnte man das mit memory mapping auf die jeweilige *.vdr
    Datei und einer Indizierung, die mittels c*Repacker-Klassen erstellt wurde,
    lösen. Die Indizierung könnte man mit mehreren offenen linked list von
    structs fertig sortiert an eine zu schreibende cMutliplex-Klasse übergeben,
    die dann die passenden ES-Daten in zu generierende PES-Container steckt.


    Zitat

    Bei den Audio-Streams sollte das nicht zu kompliziert sein, denn deren PTS sind aufsteigend.


    Beim Video-Stream existiert das Problem, dass die Frames in Dekodier-Reihenfolge erscheinen und die PTS deshalb bei den B-Frames zurückspringen. Man müsste hier also sicherstellen, dass die Audio-Daten spätestens beim Wiedergabezeitpunkt des Frames vorliegen.


    Das ist klar, denn die temporale Referenz sollte erhalten bleiben. Über so einen
    struct könnte bzw. sollte man, neben der PTS, auch Typ und ggf deren
    Eigenschaften in passenden unions berücksichtigen.


      Werner

  • Werbung und non-I-Frame-Schnitt

    Zitat

    Original von dmh
    Ahhh, danke. Sehe das jetzt schon etwas klarer. Dabei ist dann aber nur der Versatz in dem MPEG-Strom gemeint, also sprich in Bytes. Man könnte also den Byte-Abstand zweier (nahezu) gleicher Audio- und Video-PTS berechnen. Wie gesagt, um den Ton kümmere ich mich morgen.


    Hmmm ... ob das mit reinen Byte-Abständen machbar ist? Eventuell als temporäre
    Index-Liste ala index.vdr als temporäre Datei in /dev/shm/. D.h. eine Zuordnung
    von PTS auf den Startoffset eines AC3 oder Mpeg-Audio Frames.


    Zitat


    Das Demultiplexing mache ich ja in der Tat schon, da avcodec_decode_video einen normalen ES-Strom erwartet und PES nicht verarbeiten kann. Nur das Multiplexing habe ich noch nicht in Betracht gezogen, daher auch die Probleme mit den Blockartefakten.


    Ohne das funktioniert die firmware nicht korrekt.


    Zitat


    Kann mir jemand vielleicht einen Hinweis geben, wo ich etwas über Multiplexing erfahren kann? Oder hat der vdr durch den *Repacker schon einen eigenen simplen Multiplexer, dem ich einfach einen Videostrom und einen oder mehrere Audioströme gebe und er mir einen PES-Strom ausspuckt? Die Audioströme müssten dabei so sein, dass die erste Audio-PTS mit der ersten Video-PTS übereinstimmt, right?


    In remux.c gab es eigentlich schon immer einen remuxer, der TS nach PES und
    dann in ES + PTS auspackt und in neue PES-Frames steckt. Das nun die c*Repacker
    Klassen, jeweils ein Viedo- bzw Audio-Datenframe in genau ein PES-Container stecken,
    ist neu :D


    Zitat


    Falls der vdr das nicht kann, in welchem Verhältnis müssen Audio- und Videodaten gemixt werden?


    Solange es weit unterhalb der buffer-Grenzen von Treiber und der firmware
    liegt eigentlich beliebig.


    Zitat


    Macht es evtl. sogar Sinn die PTS am Anfang des Videos auf 00:00:00.000 zu setzen und bei jedem Schnitt die PTS nahtlos in einanderübergehenzulassen?


    Wenn die PTS-Zeiten continuierlich verlaufen, sehe ich nur Vorteile und solange
    die PTS nicht mit 33Bit max startet, ist IMHO alles im grünen Bereich.


      Werner

  • Werbung und non-I-Frame-Schnitt


    In den GOPs sind ja auch die PES-Container füe Audio und AC3-Audio enthalten.
    Da ein GOP in etwa meist 480ms dauert (12*(1000/25)) und der Zeitversatz
    zwischen den Zeitstempeln von Audio und Video bis zu zwei GOPs betragen kann,
    sollten meiner Meinung nach die Audio und Video Daten in diesem Bereich getrennt
    geschnitten werden. Könnte etwa so aussehen:


    Wenn Du also die PES-Container in die einzelnen ES-Streams zerlegtst, solltest
    Du den AV-Offset berücksichtigen. Denn der führt dazu, das Audio nach dem
    Video-CutIn noch zu Bildern vor dem Video-CutIn gehören und Audio nach dem
    Video-CutOut zu Bildern vor dem Video-CutOut gehören (das letzte Wort der Werbung).
    Eventuell läßt sich das bei Aufnahmen, die durch den Remuxer mit Reinhards *Repacker
    gelaufen sind, durch einfaches Sortieren nach den PTS-Zeitstempel der einzelnen
    Audio PES-Container erledigen.


      Werner