Posts by zillerbaer

    Evtl. liegt es ja wirklich am Audio und dein Mutex verbessert es. Bin gespannt ob du Erfolg damit hast. Dann übernehme ich es

    Den Mutex kannst Du schon einbauen. Die PTS von Audio stimmt ab und zu nicht.


    Einen zweiten Punkt hab ich noch gefunden. Wenn ein Audio Packet in den Ringbuffer geschrieben wird wird die PTS gesetzt. Die ist aber für das erste Sample im Packet. Beim Ermitteln der Audio PTS wird die aber für das letzte Sample angenommen. Ich füge beim Setzen der PTS jetzt die Zeit die das Packet beinhaltet zur PTS hinzu.

    Ich hoffe du siehst nun warum ich stille einfügen möchte.

    Mmmh. Stille einfügen würde ich nicht. Warum ist der Decoder so langsam? Da seh ich das Hauptproblem. Wird in SW decodiert? Die Startschwelle könnte mit AudioStartThreshold * 6 verzögert werden.

    Das ganze passiert auch im laufenden Programm wenn der Audiotakt leicht zu schnell ist.

    In x86 Systemen sind zwei Taktgeber. Einer auf der Soundkarte und einer auf der Videokarte. Soweit auseinander sollten die aber nicht liegen! Wenn Du das Problem wegwerfen von einem Frame und danach gleich wieder verdoppeln meinst, die Hauptursache hab ich gefunden. Es gibt 3 Threads die auf den AudioRingBuffer zugreifen. Die Zugriffe habe ich mit einem Mutex abgesichert und es lief viel stabiler. Ich hab's leider noch nicht im git. Bin noch am Testen.



    Wenn ich das AudioStartThreshold * 4 < n abschaltet dann braucht man zwingend das AudioVideoReady zum starten des Audio, und das kommt aber nicht bei Radio sendern. Deswegen habe ich es erstmal wieder eingebaut.

    Da bin ich am Überlegen den PlayMode zu nutzen.

    Das Konzept nur Video "wegzuschmeißen" funktioniert bei softhddevice manchmal nicht.

    Dem ist nicht so. Da wird beim Start der Wiedergabe auch Audio weg geschmissen. Nach dem Start sollte alles so synchron laufen das nix mehr "entsorgt" werden muss. An der Problematik sitze ich auch gerade für softhddevice-drm.


    Edit: Da wird auch audio verworfen.

    Ich werde in jedem Fall erstmal weiter an einem Ausgabeplugin arbeiten was meine Wünsche realisiert

    Das mache ich auch. Um Streaming kommt man aber nicht mehr herum. Beispiel Ski WC. Im TV wird eine Zusammenfassung gebracht und der komplette Wettkampf läuft im Stream. Meinen Ansatz Mediaplayer mit dem ich das Abdecken wollte habe ich aus o.g. Gründen beerdigt. Vielleicht spendiere ich softhddevice-drm Playerfunktionen.

    Gerade die Geschichte mit den Ausgabeplugins, in unsinniger Vielfalt und größtenteils ungepflegt,

    VDR wird nun mal nicht im Team entwickelt sondern in eine Ansammlung von Einzelkämpfern.

    Meiner Meinung nach ist der VDR (auf Client-Seite) auf dem Stand des alten Pentium im Scovery-Gehäuse stehen geblieben.

    Ja, das bedaure ich auch sehr.

    Ja, VDR ist veraltet. Was VDR attraktiv macht ist die Netzwerkfähigkeit. Auch wenn das hauptsächlich Plugins machen. Es steht eine Kiste die eine fette HDD hat auf der Videos und Musike ist und mit einem kleinen Raspi hat man alles in allen Räumen. Als schlimmer empfinde ich das VDR nur PES oder TS weitergibt. So parsed VDR den stream und das Ausgabeplugin dann noch einmal. Wenn man einen Player schreiben will muss das Material in PES/TS gewandelt werden und das Ausgabeplugin muss sich da wieder alles rausfummeln. Das sind in meinen Augen alte Zöpfe aus FF-Karten-Zeit die fallen sollten. Wenn es einfacher wäre plugins zu schreiben würden sicher mehr dran arbeiten.

    Es wäre auch eine Überlegung wert auf eine Multimedia-Lib wie FFmpeg umzusteigen. Das würde vieles vereinfachen. Man muss heute nicht mehr alles selbst schreiben und pflegen.

    wenn es ein VDR V4L2 M2M Plugin gibt wird es dann neben RPi auch Allwinner, Rockchip, AML, IMX und Snapdragon unterstützen.

    Ohne HW deinterlacer muß es eine Mischform mit ffmpeg bleiben. Mal sehen wie sich die v4l Schnittstelle in FFmpeg entwickelt.

    Softhddevice, Vaapidevice, Softhdcuvid, ...

    ... alle haben Johns als Ursprung. Das ist halt mit forks so. Ob die wieder zusammen geführt werden ist fraglich aber schön wäre es schon.

    Das Decodieren an sich ist ja nur die halbe Wahrheit - problematisch, weil plattformabhängig, ist auch die synchronisierte Ausgabe der decodierten (ob nun mit oder ohne Hardwareunterstützung) Audio- und Videoframes. V4L scheint da ein vielversprechender Weg zu sein, aber wann das für die neue Himbeere kommt ist fraglich.

    Die Ausgabe per DRM funktioniert eigentlich recht gut. Problematisch sind die unterschiedlichen FB Formate.


    Die v4l Entwickler sind momentan dabei sich eigene Standarts zu erarbeiten. Auch da ist der Zoo recht gross(plane, mplane, statefull, stateless, ...). Aber immer noch besser als wenn jeder Hersteller sein eigenes Süppchen kocht.

    Quote

    The end result should be that we start to adhere to more standard Linux libraries rather than the vendor specific MMAL.

    Das hört sich doch sehr vernünftig an! Den Sonderweg OMX/MMAL hab ich nie gemocht. Wenn jeder Hersteller seine eigenen Bibliotheken hat muss für jedes Board extra geschrieben werden. Wenn Standarts wie v4l oder ffmpeg genutzt werden ist der Aufwand die Hardware zu unterstützen gering.