Output stride

[sander.borsboom]

Hello,

I got decoding working correctly in most cases, but in specific cases it goes wrong since the output data includes a larger stride than the number of pixels per row times bytes per pixel.

As an example, we have an image with a width of 270 pixels, but the Stride is 812 bytes: 810 bytes for the pixels followed by 2 times 0x00.

This is not a problem to handle, but I need to know how to find out this parameter. I check the VideoStreamInfo->stride() values for both the input and output MediaSockets, before and after the first image is decoded, but they all reported 0, which is definitely not correct ;). A workaround I guess would be to take (the number of received bytes - expected bytes) / nr of rows, but that seems really iffy.

So what is the best way to find the stride of the output we get from the decoder?

Greetings,

Sander Borsboom

[Svilen Stoilov]

Hi Sander,

 

(Sorry for the late reply. I was not careful on Friday as my answer was swallowed by the automatic no-reply system  and was not posted in the AVBlocks support group)

 

Currently the only reliable way is to calculate it based on the size of the received data and the specified output color format and the frame size. I guess that you are working with RGB24 (3 bytes per pixel) and it's easy to calculate it for RGB because it uses a single plane.

The RGB stride is: ReceivedBytes / FrameHeight. This is conceptually the same as your calculation but you get the padding for each row instead of the full stride length. While not optimal this calculation is perfectly fine because it is guaranteed that you will receive one whole uncompressed frame on primo::Stream::write and the RGB format makes it easy for calculation. It can be a little more difficult for some of the YUV color formats that use 2 or 3 planes.

 

As for VideoStreamInfo->stride() being always 0 you are right. But as of now the input and output sockets do not reflect the current actual format of the transcoder. They specify what you have as input and what you want as output and then the transcoder will try to make this happen.

So VideoStreamInfo->stride() == 0 actually means to use the default stride for the uncompressed format.

You can explicitly set the output stride by using VideoStreamInfo->setStride() as part of your output socket description and then the uncompressed video frame will be with this stride. But I think this is actually brittle compared to the manual calculation above because the transcoder won't open successfully if the explicitly specified stride length is less than the default one.

 

We understand that it's better to have the actual stride coming form the transcoder (together with other params) so we are going to schedule this feature for one of the next releases and VideoStreamInfo->stride() will report the current stride even if has been originally 0 (default).

 

Regards,

Svilen

[sander.borsboom]

Hello Svilen,

my original reservation against just calculating it was that this might be brittle and there might be better ways. If it is the "standard" way, then I have no problem with it and since I agree the approach forcing the transcoder to use a certain stride is brittle, I will implement it based on the calculation. 

Thank you for the explanation,

Sander Borsboom

Op maandag 12 augustus 2013 16:21:50 UTC+2 schreef Svilen Stoilov: