Replies: 1 comment
-
The reason to put the 'uncompressed codec' not into a plugin was that the codec is not a simple compressed bitstream like in any other codec, but needs access to other boxes. The plugin-API does not support that. Thus, we would need a dedicated plugin API only for the 'uncompressed codec' which would be useful only for that one codec. But on the other hand, there is little value is providing a plugin interface for it because there is no quality difference in different encoder implementations (like x265 vs. kvazaar). If there is the wish to integrate it into FFMPEG, one can do this via the usual public libheif API or just integrate the 'uncompressed codec' into FFMPEG itself. It is not that complicated. Maybe, we will have some specific API just for the uncompressed codec anyway to have more direct control over it. |
Beta Was this translation helpful? Give feedback.
-
Unlike other codec implementations, the uncompressed codec was built directly into libheif. This seemed fine at the time, but now I would like other programs, such as FFmpeg, to use it to play uncompressed MP4 videos.
I'm wondering if an internal uncompressed codec was the right decision. Either way, it seems too late to change since a lot of work has already gone into developing it. Still, I wonder if there's a way for video applications to leverage the code already written in uncompressed_box.cc.
Beta Was this translation helpful? Give feedback.
All reactions