web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Der Stream der nicht funktioniert bei kamel5 sieht aber mit ffprobe so aus:

    Code
    Input #0, mpegts, from '00001.ts':
  Duration: 00:00:27.19, start: 1.409978, bitrate: 4756 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 100 tbc
    Stream #0:1[0x101](deu): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 224 kb/s

    Also 50Hz progressive. Da könnte das Problem liegen.


    Nachtrag:

    Ich bin Blind. Das es 50fps und progressive ist sieht man bei jsffm auch. Sorry

    OK, der Unterschied liegt in der Auflösung und fps. Das würde es zwar erklären, die Karte kann kein FullHD mit 50Hz, warum spielt sie das dann aber nach der Konvertierung ab:

    Auflösung und fps werden bei der Konvertierung nicht geändert, zumindest kann ich das nicht erkennen.

    Hier nach der Konvertierung:


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Ich habe mal die Datei runtergeladen:

    Original:

    Nach der Konvertierung:

    Code
    Input #0, mpegts, from '230717_darumgehts_dmn_6660k_p37v17-conv.mp4':
  Duration: 00:01:32.29, start: 1.400000, bitrate: 4678 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
  Stream #0:0[0x100]: Video: h264 (Constrained Baseline) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn
  Stream #0:1[0x101](deu): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 224 kb/s

    Es gibt da schon Unterschiede. Ich habe die Beiden dann mal im Videodir vom VDR entsprechend abgelegt und versucht abzuspielen. Das Original spielt es nicht ab, die Konvertierung schon, wenn es mich auch wundert, das die Karte 1080p50 abspielt.


    Im Endeffekt ist es schon so, das das Original ein Stream ist, der von dem dvbhddevice, Treiber, Firmware oder der Karte selbst nicht erkannt wird.


    Wenn ich diese Videos mit vlc abspiele, zeigt sich folgendes Bild:

    Links Original, rechts konvertiert.

    Der einzige Unterschied, der sich da zeigt, ist das avc1 vs h264.

    Zitat von jojo61

    Vergleich mal die Header des Streams mit und ohne konvertierung.

    Die sind vollkommen unterschiedlich.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von jojo61

    Ohne das derzeitig nötige remuxen könnte die Video URL direkt vom Plugin gelesen und der Stream an den vdr weitergeleitet werden.


    Damit wäre auch der Weg offen weitere Codes in das Ausgabeplugin zu integrieren. Mir ist klar das Vorschlag eher an kls gehen müsste damit andere Container neben TS unterstützung finden.

    Eine Unterstützung anderer Container und Codecs würde es vereinfachen. Allerdings sollte man nicht den Aufwand unterschätzen, den es macht das Video realtime zu laden. Ich meine nicht einfach nur das runterladen mit Full-Speed, sondern nur das, was benötigt wird. Noch schwieriger wird es dann z.B. mit mpeg-dash, weil da das dash-File auch regelmäßig aktualisiert wird. FFmpeg kann das viel besser als ich und auch noch vieles mehr.

    Ich hatte auch überlegt, auf FFmpeg als Applikation zu verzichten und alles mittels den Libs selbst zu machen, aber dann fragte ich mich, warum ich das tun sollte, wenn es doch Programme gibt, die das alles schon können.


    kamel5

    Bezüglich der Videos ARD/ZDF sehe ich aufgrund der Daten oben gar keine Möglichkeit mehr zur Unterscheidung. Es scheint ein Glücksspiel zu sein, ob h264 funktioniert oder nicht. Eine Unterscheidung zwischen den Sendern halte ich für ziemlich schräg.

    Wenn du in der codec.ini den h264 aus codec_copy nimmst, dann wird ein Stream mit h264 immer transcoded. Hat aber halt den Nachteil, daß dies bei ARD/ZDF und anderen Sendern immer transcoded wird.

    Leider ist avc1 nicht gleich h264. Und genau da ist das Problem mit der erkennung des Streams.

    Code
    avc1 indicates H.264 bitstream without start codes

    The MP4 container format stores H.264 data without start codes. Instead, each NALU is prefixed by a length field, which gives the length of the NALU in bytes. The size of the length field can vary, but is typically 1, 2, or 4 bytes.

And h264 indicates H.264 bitstream with start codes.

    H.264 bitstreams that are transmitted over the air, or contained in MPEG-2 program or transport streams, or recorded on HD-DVD, are formatted as described in Annex B of ITU-T Rec. H.264. According to this specification, the bitstream consists of a sequence of network abstraction layer units (NALUs), each of which is prefixed with a start code equal to 0x000001 or 0x00000001.
    Zitat von jojo61

    Leider ist avc1 nicht gleich h264. Und genau da ist das Problem mit der erkennung des Streams.

    Genau deshalb hatte ich Hoffnung, daß der FFmpeg Filter die Umwandlung zu einem "H.264 bitstream with start codes" gleich mit erledigt.

    Code
    2.12 h264_mp4toannexb

Convert an H.264 bitstream from length prefixed mode to start code prefixed mode (as defined in the Annex B of the ITU-T H.264 specification).

This is required by some streaming formats, typically the MPEG-2 transport stream format (muxer mpegts)

    Entweder funktioniert das nicht richtig, oder ich verwende den Filter falsch oder an der falschen Stelle. Dazu bin ich aber bei weitem nicht tief genug drin. Den Output-Muxer gebe ich mit "-f mpegts" auch schon an.

    Zitat von Zabrimus

    Eine Unterscheidung zwischen den Sendern halte ich für ziemlich schräg.

    :) , ja ich auch.

    Zitat von Zabrimus

    Wenn du in der codec.ini den h264 aus codec_copy nimmst, dann wird ein Stream mit h264 immer transcoded. Hat aber halt den Nachteil, daß dies bei ARD/ZDF und anderen Sendern immer transcoded wird.

    Das werde ich so machen.

    Zitat von jojo61

    Leider ist avc1 nicht gleich h264. Und genau da ist das Problem mit der erkennung des Streams.

    Ja, die Erkennung ist schwierig bis unmöglich.


    Danke an Alle für die Diskussion dazu.

    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Zitat von jojo61

    Ja er könnte an der falschen Stelle sein oder sich mit dem copy beißen.

    Das sample auf der FFmpeg Homepage macht das fast genauso:

    ffmpeg -i INPUT.mp4 -codec copy -bsf:v h264_mp4toannexb OUTPUT.ts.. Man könnte natürlich versuchen, den Filter im Transcoder direkt vor das "-f mpegts" zu schieben und schauen, ob das einen Unterschied macht.


    Code
    if (s.codec == "h264" && s.codec_tag == "avc1") {
 callStr.emplace_back("-bsf:v");
 callStr.emplace_back("h264_mp4toannexb");
}
callStr.emplace_back("-f");
callStr.emplace_back("mpegts");
callStr.emplace_back(fifoFilename);

    Ich habe nun mal in das Outputfile geschaut und da sind die 000001 Prefixe drin. Ist also auch ohne recoding ein h264 Stream und nicht mehr avc1.

    Du kannst den Parameter lassen wo er ist. Da macht der ffmpeg keinen Fehler und das Problem liegt wohl woanders mit der TT6400.

    Zitat von jojo61

    Ich habe nun mal in das Outputfile geschaut und da sind die 000001 Prefixe drin. Ist also auch ohne recoding ein h264 Stream und nicht mehr avc1.

    Du kannst den Parameter lassen wo er ist. Da macht der ffmpeg keinen Fehler und das Problem liegt wohl woanders mit der TT6400.

    Wunderbar. Danke für die Prüfung. Ich habe weder die Karte, noch das passende Plugin, noch irgendwas, was zur Hilfe beitragen kann.


    Für das Plugin gibt es den Branch rework_osd, darin sieht das Handling Osd/Player-Control viel logischer aus. Das OSD wird geschlossen, wenn nicht benötigt und es gibt eine Trenung OSD und Player/Control, obwohl es beides dieselbe Klasse ist, wird nun sauber differenziert.

    Es gibt nur 2 extreme Nachteile, die mich nerven:

    1. Z.B. die Lautstärke Regelung vom VDR wird eingeblendet und dabei entsteht ein sehr unangenehmes Flackern, oder sogar ein schwarzes Bild mit dem Video oben rechts bei der Tagesschau. Ich hätte gedacht, daß kein VDR OSD mehr eingeblendet wird, wenn ein Player/Control aktiv ist, aber da habe ich mich wohl getäuscht. Auf dem Zielrechner ist mir das egal, weil die Regelung über den Fernseher stattfindet, aber auf dem Rechner ist das furchtbar.

    2. Jetzt schmiert mir sws_scale auch ab. Gar nicht reproduzierbar. Ich muss da schon schnell zwischen verschiedenen Videos wechseln und irgendwann kracht es dann. Das geht mal gar nicht.


    Jetzt versuche ich, sws_scale zu ersetzen durch GraphicsMagick. Nur funktioniert das so gar nicht und ich habe keinen Plan mehr.


    Im Moment sieht der Code so aus:

    Code
    Magick::Blob blob(image, width * height * 4);
Magick::Image mimage;
mimage.size(Magick::Geometry(width, height));
// mimage.magick("BGRA");
mimage.magick("RGBA");
mimage.read(blob);
mimage.sample(Magick::Geometry(osd_width, osd_height));

    Nur passiert nach mimage.read(blob); nichts mehr. Ich komme nicht einmal zum sample. Keine Fehlermeldung, kein nix. Ich weiß nicht einmal, wo sich die Ausführung befindet oder ob das read einfach nur sehr sehr lange braucht.


    Edit: resample gelöst.

    Code
    Magick::Image mimage;
mimage.read(width, height, "RGBA", static_cast<const MagickLib::StorageType>(0), image);
mimage.sample(Magick::Geometry(osd_width, osd_height));
mimage.write ( 0, 0, osd_width, osd_height, "RGBA", static_cast<const MagickLib::StorageType>(0), scaled);

    Damit ist zumindest in dem Branch die Abhängigkeit von sws_scale weg und dafür gibt es nun GraphicsMagick++.

    Zitat von Zabrimus

    Das OSD wird geschlossen, wenn nicht benötigt

    Mir ist gestern aufgefallen das das OSD nach ein paar Sekunden weg geht wenn man einen Film pausiert. Eigentlich sollte da das OSD offen bleiben und das Pause Zeichen (II) sichtbar bleiben. Das ist zwar nicht schlimm verwirrt aber etwas weil man im Gegensatz zum vdr nun ok drücken muss damit es weiter geht. Mein hbbtv Fersenher lässt da das OSD offen.

    Zitat von Zabrimus

    1. Z.B. die Lautstärke Regelung vom VDR wird eingeblendet und dabei entsteht ein sehr unangenehmes Flackern, oder sogar ein schwarzes Bild mit dem Video oben rechts bei der Tagesschau. Ich hätte gedacht, daß kein VDR OSD mehr eingeblendet wird, wenn ein Player/Control aktiv ist, aber da habe ich mich wohl getäuscht.

    Und ich wollte noch fragen, ob man nicht die Lautstärkeregelung von VDR oder was anderes einblenden kann. Deaktivieren muss ja irgendwie gehen, vorher kams ja auch nicht. Flackern sollte natürlich nichts. Ich werde den Branch später mal testen.

    Zitat von Zabrimus

    Für das Plugin gibt es den Branch rework_osd

    Der Branch heisst osd_rework


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Zitat von Zabrimus

    Man könnte natürlich versuchen, den Filter im Transcoder direkt vor das "-f mpegts" zu schieben und schauen, ob das einen Unterschied macht.

    Das macht keinen Unterschied.


    Ich habe gestern mal ein wenig mit ffmpeg herumgespielt und es sieht folgendermaßen aus:

    "-f mpegts" ist wichtig, es spielt dabei keine Rolle, wo es steht.


    Wenn "-f mpegts" benutzt wird, ergibt es keinen Unterschied ob "-bsf:v h264_mp4toannexb" benutzt wird oder nicht, es entsteht das selbe Ergebnis (Binärkompatibel).


    Wenn "-f mpegts" nicht benutzt wird, macht es einen Unterschied, ob "-bsf:v h264_mp4toannexb" benutzt wird oder nicht, es entstehen unterschiedliche Files.


    Wenn "-f mpegts" benutzt wird, kann der VDR, bei entsprechendem Einbinden in das Videoverzeichnis, sogar ein Index-File erstellen. Ohne "-f mpegts" gibt es dann nur Fehlermeldungen.


    Keiner dieser Versuche führte aber dazu, das die TT6400 das Ergebnis mit Bild abspielen konnte. Bei benutzten "-f mpegts" wurde zumindest der Ton abgespielt, d.h. das das Ergebnis so falsch nicht sein kann.

    Das hilft aber alles nichts, ohne Bild macht das natürlich keinen Spaß.


    Ich werde also im Moment damit leben, das die Videos konvertiert werden müssen. Sollte sich irgendwann mal noch eine Erkenntnis dazu ergeben, kann man das ja immer noch nachtragen.


    Zabrimus , ich würde vorschlagen, die Sonderbehandlung erst einmal wieder zu entfernen.


    Grüße

    kamel5

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Auszug der ffmpeg Doku zu h264_mp4toannexb


    Please note that this filter is auto-inserted for MPEG-TS (muxer mpegts) and raw H.264 (muxer h264) output formats.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Zitat von rell

    Und ich wollte noch fragen, ob man nicht die Lautstärkeregelung von VDR oder was anderes einblenden kann. Deaktivieren muss ja irgendwie gehen, vorher kams ja auch nicht. Flackern sollte natürlich nichts. Ich werde den Branch später mal testen.

    Deaktivieren war eigentlich ein Fehler, den man natürlich reproduzieren kann. Die Ursache war einfach, daß ich das OSD aus dem Menu nicht wirklich geschlossen hatte und damit die Anzeige der Lautstärkeregelung unterbunden wurde. Versuchsweise habe ich den aktuellen OSD-Layer auf 0 gesetzt, aber dann ist in der Tagesschau nur das Video zu sehen, dafür flackert die Lautstärke-Anzeige nicht mehr. Auch nicht gut. OSD-Layer ab 1 flackert dann wieder.

    Wieviele OSDs gibt es denn da gleichzeitig?

    "Womit" flackert es denn?

    Wenn ich Zeit hab schau ichs mir auch nal an, aber das muss lösbar sein...

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden