In avidemux plugin side:
Once the vprp ( Video Propertiies Header) detected exist in avidemux plugin, we can the see the aspect ratio is
16384:9223 which is aspect_n = 16384 and aspect_d = 9223.
Inside the avidemux plugin, under gst_avi_demux_parse_stream function (gstavidemux.c):
The pixel aspect ratio is using w/h and aspect ratio:
n = aspect_n stream video height = 16384 720 = 11796480
d = aspect_d stream video width = 9223 1270 = 11713210
In the GST_DEBUG message for avidemux, the gst_avi_demux_check_caps is using to check for caps values.
I found out the pixel-aspect-ratio=(fraction)1179648/1171321
The last digit totally gone. In gst-msdk, we retrieve the GstVideoInfo based on the caps, the vip.par_n = 1179648 and vip.par_d=1171321.
In the avidemux plugin side, may need to gstreamer deveoper side how he pixel-aspect-ratio calculate. It could be on certain format for avi file container checking for certain condition.
In the qtdemux, the formula is
n = display width stream video height
d = display height stream video width
In the h264parse plugin, the sps->vui_paramters.aspect_ratio_info_prresent_flag is equal to 1.
The h264parse also detect the parsed_par_n and parsed_par_d is different with sps->vui_parameters->par_n and sps->vui_parameters->par_d.
The h264parse updated the parsed_par_n and parsed_par_d to use the vui_parameters->par_n and vui_parameters->par_d.
But currently the upstream_par_n and upstream_par_d exist, the pixel-aspect-ratio caps will be chosen to use upstream_par_n and upstream_par_d instead
of the par_n and par_d extra from sps->vui_parameters.
The gst-vaapi got its own parse function, they can overwrite the pixel-aspect-ratio directly use the information from sps->vui_parameters.
On the gst-msdk side, looks like we need to extra out sps information check for vui_parameter exist or not.
To decide to use sps->vui_parameter sar_width and sar_height for par_n and par_d to fill in AspectRatioW and AspectRatioH inside the mfxFrameInfo struct.
In gst-msdk plugin side:
MSDK library has mfxFrameInfo struct contains member AspectRatioW and AspectRatioH with data type mfxU16 which is only 2 bytes. But the par_n and pard_d is gint which is 4 bytes.
Once the value larger than 2 bytes, the value assign to AspectRatioH and AspectRatioW will not correct anymore. The information are missing from 4 bytes to 2 bytes.
The decoder-params passing to MFXVideoDECODE_Init will return MFX_ERR_INVALID_VIDEO_PARAM (-15). This will lead to video fail to play. To prevent the issue happen again due overflow, we will
added check to ensure par_n and par_d passing from upstream is within 2 bytes before pass to MSDK, else will do shift 16 for par_n and par_d values over 2 bytes.
In avidemux plugin side: Once the vprp ( Video Propertiies Header) detected exist in avidemux plugin, we can the see the aspect ratio is 16384:9223 which is aspect_n = 16384 and aspect_d = 9223.
Inside the avidemux plugin, under gst_avi_demux_parse_stream function (gstavidemux.c): The pixel aspect ratio is using w/h and aspect ratio: n = aspect_n stream video height = 16384 720 = 11796480 d = aspect_d stream video width = 9223 1270 = 11713210
In the GST_DEBUG message for avidemux, the gst_avi_demux_check_caps is using to check for caps values. I found out the pixel-aspect-ratio=(fraction)1179648/1171321
The last digit totally gone. In gst-msdk, we retrieve the GstVideoInfo based on the caps, the vip.par_n = 1179648 and vip.par_d=1171321. In the avidemux plugin side, may need to gstreamer deveoper side how he pixel-aspect-ratio calculate. It could be on certain format for avi file container checking for certain condition.
In the qtdemux, the formula is n = display width stream video height d = display height stream video width
In the h264parse plugin, the sps->vui_paramters.aspect_ratio_info_prresent_flag is equal to 1. The h264parse also detect the parsed_par_n and parsed_par_d is different with sps->vui_parameters->par_n and sps->vui_parameters->par_d. The h264parse updated the parsed_par_n and parsed_par_d to use the vui_parameters->par_n and vui_parameters->par_d. But currently the upstream_par_n and upstream_par_d exist, the pixel-aspect-ratio caps will be chosen to use upstream_par_n and upstream_par_d instead of the par_n and par_d extra from sps->vui_parameters.
The gst-vaapi got its own parse function, they can overwrite the pixel-aspect-ratio directly use the information from sps->vui_parameters. On the gst-msdk side, looks like we need to extra out sps information check for vui_parameter exist or not. To decide to use sps->vui_parameter sar_width and sar_height for par_n and par_d to fill in AspectRatioW and AspectRatioH inside the mfxFrameInfo struct.
In gst-msdk plugin side: MSDK library has mfxFrameInfo struct contains member AspectRatioW and AspectRatioH with data type mfxU16 which is only 2 bytes. But the par_n and pard_d is gint which is 4 bytes. Once the value larger than 2 bytes, the value assign to AspectRatioH and AspectRatioW will not correct anymore. The information are missing from 4 bytes to 2 bytes. The decoder-params passing to MFXVideoDECODE_Init will return MFX_ERR_INVALID_VIDEO_PARAM (-15). This will lead to video fail to play. To prevent the issue happen again due overflow, we will added check to ensure par_n and par_d passing from upstream is within 2 bytes before pass to MSDK, else will do shift 16 for par_n and par_d values over 2 bytes.