[softhddevice] Verständnisfrage pts

    Hallo zusammen,


    ich spiele gerade mit meiner softhddevice-drm-gles Version herum und stelle fest, dass ich bei amlogic relative viele Framedrops und -dups habe.

    Das liegt laut den logs daran, dass die dekodierten frames nicht in der richtigen Reihenfolge, d.h. nach pts geordnet aus dem decoder kommen.

    Fehlt ein frame, wird gedupt. 2 frames später kommt es aber und dann wird gedroppt usw...

    Das ganze passiert aber nur, wenn mit Hardware, d.h. über ffmpeg/h264_v4lm2m dekodiert wird, und auch nur mit amlogic, soweit ich es bisher feststellen konnte.


    Deshalb habe ich mal eine grundsätzliche Verständnisfrage:

    Ich glaube verstanden zu haben, dass nicht sichergestellt ist, dass die Pakete im stream in der richtigen Reihenfolge ausgeliefert werden.

    Ich meine auch gesehen zu haben, dass der decoder bei den anderen Platformen über avcodec_send_packet und avcodec_receive_frame die richtige Reihenfolge herstellt. Stimmt das?

    Wenn das so sein sollte, stimmt wohl was an decoder bzw. ffmpeg nicht.

    Wenn dem decoder aber erlaubt ist, die frames einfach nachdem sie dekodiert wurden in den ringbuffer zu legen - egal ob der pts in der richtigen Reihenfolge ist - müsste ich mich ja dann im Ausgabeplugin darum kümmern, dass die frames wieder geordnet werden?


    Woher kommt denn der pts bzw. wer legt den fest? Aus den Paketen im Stream schon?

    Kann da jemand für mich Licht ins Dunkel bringen? Wie machen das die ganzen softhddevice Varianten?


    Am Ende stellt sich trotzdem die Frage, warum das bei amlogic so ist. Ich muss mir noch den Rpi4 bei h264 ansehen, ob das da auch so ist. Auf dem rockchip mit v4l2_request tritt das jedenfalls nicht auf.


    Danke für eure Hilfe.


    Gruß

    Andreas

    Im Stream sind die Packete in der Decodierreihenfolge. Das ist nicht zwangsläufig die Anzeigereihenfolge. Das sortieren macht nach dem decodieren der Decoder anhand des PTS. Das scheint bei AML noch zu fehlen. Der PTS steht im undecodierten Packet und wird vom Sender / Encoder festgelegt.

    Ok danke. Das zeigt zumindest, wo ich suchen muss.

    Hier mal ein paar Beispiele, wo ich den pts in CodecReceiveFrame mitgeloggt habe.


    Hier fehlt 17:04:23.057 und das frame kommt mit leerem pts:

    Code
    Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.017
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.037
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts  0:00:00.000
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.077
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.097
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.117
Mär 21 08:48:28 odroid vdr[15593]: [15602] [softhddevice][AV_Sync] More then 5s Pkts 47 deint 0 Frames 2 AudioUsedBytes 90112 audio 17:04:23.056 video  0:00:00.000 Delay 0ms diff -61463056ms
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.137
Mär 21 08:48:28 odroid vdr[15593]: [15609] [softhddevice][Codec] VideoRenderFrame: pts 17:04:23.157

    Hier fehlt 17:06:06.317 und das frame kommt mit leerem pts, allerdings wird zumindest das 297er gedupt:

    Hier mal eine Stelle, wo die Reihenfolge nicht passt 317-377-357, das 337 hat wieder keinen pts.

    ... und hier genauso

    Das wäre doch dann der Beweis, dass der decoder, sprich ffmpeg nicht richtig arbeitet, oder? Ich kann da mal reinschauen.


    Besteht die Möglichkeit, hier erstmal im softhddevice einen workaround zu basteln? Theoretisch müsste das Frame ohne pts den richtigen Timestamp bekommen und außerdem müsste man den ringbuffer sortieren. Aber wahrscheinlich macht es mehr Sinn, das im decoder zu fixen...


    Für mich sieht es so aus, als hätte ffmpeg ein Problem damit, die frames zu sortieren, wenn es mit einem leeren pts zu tun hat. Vielleicht löst sich das Problem, wenn man den gefixt bekommt.

    Meines Erachtens müsste das Zusammensortieren der Pakete in der richtigen Reihenfolge durch die Hardware bzw. im Kernel erfolgen. Bei dem von amlogic gepatchten Kernel 4.9 funktioniert das jedenfalls, ohne dass nach meiner Kenntnis softhdodroid eine Vorsortierung vornehmen muss. Vielleicht kann jojo61 dazu mehr sagen.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    rell Loge doch mal die PTS der Frames die du zum dekoder schickst und dann die PTS die du da wieder raus bekommst. Das kann M.E. nicht die gleiche Reihenfolge sein, da der dekoder ja einige Frames z.b. die I-Frames als Referenz behalten muss um die B-Frames zu dekodieren. Dann überholt z.b. das B-Frame ein I-Frame im Dekoder und somit sollte sich die richtige reihenfolge hinter dem decoder ergeben. Wenn das nicht der Fall ist dann stimmt etwas im Decoder nicht. Evtl. hat der decoder auch zu wenig Puffer ums Frames zwischen zu lagern. Das kann man doch beim ffmpeg Parametrieren.

    jojo61 Das habe ich schonmal gemacht und es ist richtigerweise so, dass die pts der avpkt beim Eingang eine andere Reihenfolge haben, als die pts der frames, wie sie wieder rauskommen. Ich muss nochmal mit den Rpi4 testen, ob das da auch so ist. Dann stimmt nämlich was an der ffmpeg Version nicht. Ansonsten ist das ein amlogic Problem.


    Ich nutze https://github.com/jc-kynesim/…tree/dev/6.0/rpi_import_1 wie sie auch von LE genutzt wird für amlogic. Kann natürlich sein, dass da ein bug drin ist. Ich glaube die codestelle um diesen Commit herum ist die entscheidende. Die Version trackt glücklicherweise die Pakete, wie sie durch den decoder gehen vorher und nachher mit pts. Ich werde mir die Logs mal genauer ansehen, denn wenn die falsche Reihenfolge kommt, müsste man das ja auch da nachvollziehen können.


    Wo kann ich den Puffer bei ffmpeg einstellen?

    Zitat von rell

    Wo kann ich den Puffer bei ffmpeg einstellen?

    Das ist wohl codec abhängig, aber z.b. bei cuvid stelle ich das so ein:

    Code
    if (av_opt_set_int(decoder->VideoCtx->priv_data, "surfaces", 10, 0) < 0) {
            Fatal(_("codec: can't set option surfces to video codec!\n"));
}

    Aber M.E. sollte es so etwas bei jedem Codec geben.

    Hier nochmal ein Ausschnitt aus dem Log. send und receive habe ich mitgeloggt. So wie ich das lese geht im decoder irgendwo das paket für 10:15:38.804 verloren und wird mit einem AV_NOPTS_VALUE ausgeliefert. Dadurch scheint dann die Sortierung durcheinander zu kommen. send_packet legt allerdings ein av_pkt mit *.804 ab...

    Bei RPi4 konnte ich das bisher noch nicht nachvollziehen, und versuche jetzt dann exakt mal die ffmpeg-Version auf dem odroid.

    Die Reihenfolge nach dem Decoder stimmt einfach nicht...

    Einstellungen für einen buffer habe ich noch nicht gefunden, evtl. capture_num_buffers?

    Ansonsten verhalten sich beide ffmpeg Varianten gleich. Ich glaube, ich muss tiefer einsteigen...

    Welcher Hardwaredecoder wird denn da benutzt. Bei mmal gibt es noch folgende Parameter:

    Code
    static const AVOption options[]={
    {"extra_buffers", "extra buffers", offsetof(MMALDecodeContext, extra_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
    {"extra_decoder_buffers", "extra MMAL internal buffered frames", offsetof(MMALDecodeContext, extra_decoder_buffers), AV_OPT_TYPE_INT, {.i64 = 10}, 0, 256, 0},
    {NULL}
};

    Ganz bin ich nicht durchgestiegen, aber es wird h264_v4l2m2m benutzt, der ein wrapper für den hardwarespezifischen decoder sein sollte.

    D.h.

    Code
    static const AVOption options[] = {
    V4L_M2M_DEFAULT_OPTS,
    { "num_capture_buffers", "Number of buffers in the capture context",
        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 2, INT_MAX, FLAGS },
    { NULL},
};

    Wären die Optionen aus https://github.com/jc-kynesim/…2_m2m_dec.c#L226C1-L231C3

    Weiß nur noch nicht, wie und wo ich das setzen muss ;)

    Das gibts auch noch. https://github.com/jc-kynesim/…libavcodec/v4l2_m2m.h#L39

    Code
    #define V4L_M2M_DEFAULT_OPTS \
    { "num_output_buffers", "Number of buffers in the output context",\
        OFFSET(num_output_buffers), AV_OPT_TYPE_INT, { .i64 = 16 }, 2, INT_MAX, FLAGS }

    Bei output und capture komme ich immer durcheinander ;)

    Einmal editiert, zuletzt von rell ()

    Danke, jojo61 !

    Scheint zu funktionieren, bzw. damit zusammenzuhängen. Ich habe jetzt folgendes drin:

    Code
    if (av_opt_set_int(decoder->VideoCtx->priv_data, "num_capture_buffers", 10, 0) < 0) {
            Fatal("CodecVideoOpen: can't set num_capture_buffers"));
}

    Viel besser, bei ARD HD (fast) keine sync Probleme mehr. Hier und da seltenst evtl. mal ein drop, aber das kann andere Gründe haben...

    Bei ZDF HD auch viel besser, manchmal läuft er nach ein paar Sekunden hier rein : https://git.kernel.org/pub/scm…/vdec/vdec_helpers.c#n388 und ich habe immer mal wieder AV_NOPTS_VALUE, was alles durcheinander bringt...

    Aber auf jedem Fall viel besser als vorher. Ich schau mir das heute abend live an, evtl. ist das mit den Klötzchen beim Start ja auch besser...


    Anschlußfrage: Woher kommen die "10"? Einfach so, oder gibts da Regeln?

    • Neu

    Es scheint, als wäre der kernel der Übeltäter. Mit https://git.kernel.org/pub/scm…5a89a172b905f9ecbb6fc5b67 hat sich wohl ein bug eingeschlichen und https://pastebin.com/raw/4XDz6xDF nimmt den teilweise wieder zurück. Bisher keine Framedrops auf ZDF HD. Jetzt muss ich nur noch sehen, wie ich einen fix nach upstream kriege...

    Damit wären wir bei amlogic dem Ziel wieder eins näher...


    Im Plugin muss ich die buffer damit übrigens nicht mehr setzen bzw. erhöhen ;)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden