QtCS2024 FFmpeg in Qt Multimedia: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
m (Adding notes from the presentation)
Line 24: Line 24:
Roadmap for backend support
Roadmap for backend support


Questions and discussions
Questions and discussions:
 
 
What to do about native backends on 6.8.
 
* Suggestion: make them opt-in
* KDE point of view: android is causing the most pain. FFmpeg is painful to cross compile to android. For simple camera access the native backend is better. Think about simple use cases where codecs aren't needed
 
 
It is possible to build ffmpeg with a super minimal configuration to have it in a small size.
 
How about reduce the support for native backend to the minimal basic use cases? -> Seems to be an acceptable approach


[[Category:QtCS2024]]
[[Category:QtCS2024]]

Revision as of 08:18, 11 September 2024

Session Summary

In this session, we will look at the core functionalities of Qt Multimedia, address the challenges of ensuring consistent behavior across various platforms, and discuss our strategic transition to FFmpeg as a cross-platform backend. This move from native platform backends to FFmpeg has implications for both Qt contributors and users. We encourage an open and constructive discussion on the direction we are taking.

Session Owners

Jøger Hansegård, Artem Dyomin, and Maycon Stamboroski

Notes

Outline

What is Qt Multimedia?

Core APIs

Qt Multimedia's backend architecture

FFmpeg media backend

Considerations when switching to FFmpeg media backend

Linking to FFmpeg media libraries

Notes on licensing

Roadmap for backend support

Questions and discussions:


What to do about native backends on 6.8.

  • Suggestion: make them opt-in
  • KDE point of view: android is causing the most pain. FFmpeg is painful to cross compile to android. For simple camera access the native backend is better. Think about simple use cases where codecs aren't needed


It is possible to build ffmpeg with a super minimal configuration to have it in a small size.

How about reduce the support for native backend to the minimal basic use cases? -> Seems to be an acceptable approach