[haiku-development] Re: BMediaTrack->ReadChunk() query

  • From: Dario Casalinuovo <b.vitruvio@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 11 Oct 2019 15:01:20 +0200

Hi Zenja,

On Fri, Oct 11, 2019 at 2:02 PM Zenja Solaja <solaja@xxxxxxxxx> wrote:

Hi everyone.

From the Haiku community forums some of you may have seen that 'm
developing a Haiku native media editor (audio + video).  I'm currently
working on the Export media functionality, and have 2 (user selectable)
export engines:  native BMediaKit and ffmpeg.

During video editing, the number of untouched frames is proportionally
quite high. ie. a majority of frames are simply trimming and repositioning,
so the bulk of frames have no applied graphical effects.  The source frames
are typically in a YCrCb format (eg. YUV420p planner instead of chunky), as
are the destination frames in mp4 and webm formats.  Since colour
conversion is lossy, quality suffers in the YCrCb->RGB->YCrCb pipeline.


Some of you can probably see the nature of my query.  Is it possible to
get the YCrCb data from BMediaTrack using ReadChunk() instead of
ReadFrames(), eg. using the BMediaTrack->ReadChunk() API (which uses the
ffmpeg media addon under the covers)).  If this were possible, then for a
majority of frames I could simply redirect the YCrCb frame to the ffmpeg
encoder without performing the lossy colour conversion to RBG and back
again.


I do think the problem is that ReadChunk is not meant at all to do that,
you still need the decode step to get YCrCb that can be only done in the
decoder. What could have worked is specifying the output format as YCrCb in
the decoder and get this from ReadFrames but AFAIK the plugin is doing
conversion to RGB without possibility to choose that.

The reason for introducing the codec kit was to expose a more flexible API
to overcome those needs. I think you have two choices, either you go into
the ffmpeg pluging and see if you can do what I mentioned, or maybe access
the private API and implement your own decoder.


BMediaTrack->ReadChunk() was originally designed to work with RAW
(unencoded) videos.  But there is a very valid use case to read the YCrCb
image without performing colour correction, and to write it during
editing.  ReadChunk() specifies a byte size, and ideally it would return a
full frame (instead of 2 or more) and ignore the input buffer size (or
treat it like a max size but I cannot do anything with a partial frame).
Also, can I arbitrary call ReadChunk() after a previous ReadFrame(), mix
their calls (so to speak).  The original R5 header files says that this is
discouraged, but this was pre ffmpeg add-on.


I don't think you can. As far as I remember calling those independently is
going to mismatch the internal data that is used for duration and so on.
However, my honest advice is: don't loose time with BMediaTrack, just use
ffmpeg. You have nothing to gain other than loosing time.

-- 
Saluti,
Dario

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 10-2019