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

  • From: Zenja Solaja <solaja@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 12 Oct 2019 21:04:04 +1100

Looking at the ffpeg add-on, I can see that if I specify color_space to B
_CbCr420 in media_format (when reading from BMediaTrack),
AVCodecDecoder.cpp will pass this color_space to SwsContext() so
sws_scale() should in theory bypass colour conversion since its
transforming from AV_PIX_FMT_YUV420P (src) to AV_PIX_FMT_YUV420P (dest), ie
do nothing. Stephan has a point that this may already exist since overlay
code (video drivers) requires images in this colour space. I remember back
in R5 days doing a video player with overlays in a YUV format, so the API
should already be good for skipping colour conversion.

I’ll test this next week and report back.

Thanks everyone for civil and informative replies.



On Sat, 12 Oct 2019 at 3:55 am, Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:

This stuff is fading out of my memory as it should be, so sorry if I'm
misinterpreting something.
But setting fOutputColorSpace seems to have the result that then only
B_RGB32 is used in the code.
So it seems to me cannot possibly output to any other format:

Yes, right. What I'm saying is I don't understand why it is forced at all
here.


Someone is required to check all this stuff on API user side, but I
remember that most of the use
case there was to just share the same format, and that will have the
effect also to always use
B_RGB32 even if it's not needed, this and other are a number of reasons
for why this API should
have been reviewed and updated.

There is no problem with the API, which allows one to set values in the
structure passed to
BMediaFormat::DecodedFormat and have the decoder do its best to meet the
request, or modify
the structure if it can't achieve it.

There is a rather large limitation in the way ffmpeg implements this API,
by ignoring the passed
structure and always using RGB32 here. I don't see why it would allow
YCbCr when not using libswscale
but force RGB when using it, there is no reason for that, libswscale can
certainly output to YCbCr.

So, let's just remove this #ifdef and use the other branch? If that's all
there is to it, that sounds
like a simple fix.

--
Adrien.



Other related posts: