Re: ffmpeg impasse

Hi Steven,

Your analysis sounds fine I think. i also arrive in the same
conclusions, but with these differences :

- As I understand in ffmpeg code (not easy to understand), the
video/audio stream depends on codec and format processed which can
give different results.
- I read somewhere in a forum (but I don't remember where, probably in
QtAv area) that ffmpeg can be forced to be sync in stream processing
(aka a decoding mode), but with degraded performances.

Rewriting this class in QtAv can be a solution, after all QtAv author
said that he will not maintain the code because it have not be well
designed. I recommend first to take a look to the new ffmpeg interface
implemented in Qt6::Multimedia as new module:

https://code.qt.io/cgit/qt/qtmultimedia.git/tree/src/plugins/multimedia/ffmpeg

We talked about it with Maik by private mails a few months ago, and it
sounds like the future, if this module is stable and works better than
QtAv. Also, it's only for Qt6 targets, not Qt5, and we cannot yet
switch completely digiKam for these blocking points :

- Marble widget is not yet ported to Qt6 : no geolocation in digiKam at all.

https://invent.kde.org/education/marble/-/issues/12

- MXE cross compilers do not integrate Qt6::WebEngine : no web service
support under Windows.

https://github.com/mxe/mxe/tree/master/src/qt/qt6

Except for these 2 features, digiKam ported to Qt6 is mostly ready of
course, including QtAV code with the glitch that you listed before.

Best

Gilles