[markad] überarbeiteter Decoder

Auch markad hat ein Problem mit Ubuntu 22.04, genauer gesagt mit dessen ffmpeg Version.

Wenn man --cut und --fullencode nutzt, ist die MP2 Tonspur weg. Somit:

Die Version 3.0.22 ist auf vdr-plugin-markad verfügbar.

- fix encoding of mp2 audio with ffmpeg >= 4.4
- fix some possible null pointer dereference
- some minor bug fixes and optimizations, see git

Die Version 3.0.23 ist auf vdr-plugin-markad verfügbar. Diesmal insbesondere Fixes für die neue ffmpeg channel layout API.

- some fixes for the new ffmpeg channel layout API
- adjustments for vdr 2.6 error counter
- declare ffmpeg 3.2.18 from Debian 9 Stretch as deprecated
- some minor bug fixes and optimizations, see git

Erster Verdacht: Da läuft auf deinem 32 Bit System eine Variable über. Ist das Problem nur bei dieser Aufnahme oder bei allen ?

Mal ein Versuch: Bitte in /command/debug.h den Kommentar in der Zeile "// #define DEBUG_INDEX" entfernen, neu bauen und dann die markad.log nochmals posten.

Zitat von durchflieger

Hab es gerade nochmal mit einer zweiten Aufnahme probiert. Abbruch an selber Stelle wieder direkt beim ersten Packet.

Das macht es einfacher, wenn es ein grundsätzliches Problem ist.

Das knallt ja schon beim Aufruf.

Bitte nochmals mit dem Stand ein Log erzeugen. Ich habe kein 32 Bit System mehr, das wird jetzt "stochern im Nebel".

Das sieht gut aus.

Das "stochern in Nebel geht weiter": Vielleicht liegt es am Aufruf der Funktion mit der int64 Variable, das dein Compiler nicht mag.

Bitte nochmals mit dem aktuellen Stand aus o.g. Branch testen.

Zitat von durchflieger

Hab mal die alte markad Version 0.1.6 mit dem patch "improvements for markad for recent ffmpeg versions" portiert.

Die läuft auf den beiden Aufnahmen mit Parameter --cDecoder einwandfrei durch.

Klar, da gab es die Index Funktion, die bei dir crashed noch nicht.

Zitat von durchflieger

Mit dem neuen Branch leider nach wie vor selbes Resultat.

Was ist denn das für ein Compilier bei dir ? Bitte nochmals mit dem aktuellen Stand testen, ich sehe immer noch nicht die Codezeile, die da den Crash verursacht.

Das ist doch in Bug im Cross Compiler ???

Das Element wird zwar auf dem Stack allokiert, sollte aber kein Problem sein, da push_back eh das Element in den Heap kopiert. Mein Verdacht ist nun, dein Cross Compiler verhält sich hier anders.

Teste bitte mal nochmals mit dem aktuellen Git Stand. Vorsicht: Das ist nur mal ein Quick and Diry Test und hat sicher noch einen Memory Leak drin.

Zitat von durchflieger

Vieleicht hilft das weiter?

Ja, ich denke schon. Ich bekomme in meiner Build Umgebung keine Warning.

Zitat von durchflieger

Dort meldet der gcc zum source index.cpp schon eine warning bezüglich vector.

Nein, die Warning kommt nicht aus meiner Source, sondern aus einer C++ Standard Lib, die ich include. Hier scheinen deine Libs und dein Compiler nicht zusammen zu passen. Kannst du mal mit einem älterem Compiler oder mit neueren C++ Libs testen ?

C -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -rdynamic -Wextra -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__USE_XOPEN_EXTENDED   evaluate.cpp
In file included from /home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/vector:72,
                 from index.h:13,
                 from index.cpp:8:
/home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/bits/vector.tcc: In member function 'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {const cIndex::sPTS_RingbufferElement&}; _Tp = cIndex::sPTS_RingbufferElement; _Alloc = std::allocator<cIndex::sPTS_RingbufferElement>]':
/home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/bits/vector.tcc:426:7: note: parameter passing for argument of type 'std::vector<cIndex::sPTS_RingbufferElement>::iterator' {aka '__gnu_cxx::__normal_iterator<cIndex::sPTS_RingbufferElement*, std::vector<cIndex::sPTS_RingbufferElement> >'} changed in GCC 7.1
  426 |       vector<_Tp, _Alloc>::
      |       ^~~~~~~~~~~~~~~~~~~
In file included from /home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/vector:67,
                 from index.h:13,
                 from index.cpp:8:
/home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/bits/stl_vector.h: In member function 'void cIndex::AddPTS(int, int64_t)':
/home/dev/build-enviroment/builds/openatv/release/gb7252/tmp/work/cortexa15hf-neon-vfpv4-oe-linux-gnueabi/vdr-plugin-markad/3.0.23-r0/recipe-sysroot/usr/include/c++/9.2.0/bits/stl_vector.h:1195:4: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator<cIndex::sPTS_RingbufferElement*, std::vector<cIndex::sPTS_RingbufferElement> >' changed in GCC 7.1
 1195 |    _M_realloc_insert(end(), __x);
      |    ^~~~~~~~~~~~~~~~~

So tief bin ich da auch nicht drin. Hat jemand eine Idee, wo man hier noch ansetzen könnte ?

Kannst du mal direkt auf dem Zielsystem zu kompilieren, vielleicht ändert das was.

Die Funktion ist eine Basisfunktion und wird sicher von jedem genutzt und keiner bekommt hier einen Crash. Da muss bei dir was besonderes sein, was das Problem verursacht.

Zitat von durchflieger

Da geht vorher was in die Hose.

Viel vorher gibt es nicht, das crashed ja ziemlich am Anfang.

Bitte teste mal diesen Code. Da allokiere ich den Speicher für das neue Element im Vektor vor dem push_back. Mal sehen, ob das was ändert. Falls es neue Compiler Warnings bei dir gibt, bitte die auch posten.