You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. Im using (and loving) ThreadX and USBX Host stack to interface with an UVC.
I started with this issue and managed to get MJPEG working flawlessly - the stack is very accessible and the example in the above link was quite self-explanatory.
The next step in my application is implementing H264 capture. I have an UVC - descriptor below - that has two streaming interfaces:
I tried (and failed hilariously) to switch the current interface. Take, for example, the following function:
VOID uvc_parameter_list (UX_HOST_CLASS_VIDEO * video)
{
ULONG format_index;
UX_HOST_CLASS_VIDEO_PARAMETER_FORMAT_DATA format_parameter;
UINT status = UX_SUCCESS;
int i;
/* format types */
for (format_index = 1; format_index <= video->ux_host_class_video_number_formats; format_index++)
{
/* Get format data for current format index. */
format_parameter.ux_host_class_video_parameter_format_requested = format_index;
status = _ux_host_class_video_format_data_get(video, &format_parameter);
printi("FOUND FORMAT %lx", format_parameter.ux_host_class_video_parameter_format_subtype);
if (UX_SUCCESS == status)
{
/* Save number of frames in the video instance. */
video->ux_host_class_video_number_frames = format_parameter.ux_host_class_video_parameter_number_frame_descriptors;
uvc_parameter_frame_list(video);
}
}
}
This works great (for the default interface) - but I'd like to also parse the secondary interface (the H264 one) and switch to that interface when the user requests H264 video.
Right now I managed to get that working (to test the functionality), by setting the parameters for MJPEG and before starting acquisition, switching the interface number to the (known) H264 one. Which is ugly and naturally not production-worthy.
status = ux_host_class_video_frame_parameters_set(video, UX_HOST_CLASS_VIDEO_VS_FORMAT_MJPEG, 1920,1080,333333);
[...]
for (int j = 0; j < 128; ++j)
{
video->ux_host_class_video_streaming_interface = video->ux_host_class_video_streaming_interface->ux_interface_next_interface;
if(video->ux_host_class_video_streaming_interface->ux_interface_descriptor.bInterfaceNumber == 2)
{
break;
}
}
status = _ux_host_class_video_channel_start(video, &channel_parameter);
The parsing of the video packets is the exact same one would use to validate and reconstruct a JPEG, I'm using the same function and I'm getting valid AUs (multiple NALs for consecutive packets with the same FIDs).
I have a hunch that the stack is currently written to only support one interface (it makes sense, 90% of UVCs in the wild only have one), but I'm sure there's a way to select/ switch the interface numbers after the initial parsing and still be able to get info about the current interface, correctly request the stream format etc. I just couldn't find it.
I'd appreciate any kind of pointers regarding this issue.
Thank you kindly!
The text was updated successfully, but these errors were encountered:
Hi. Im using (and loving) ThreadX and USBX Host stack to interface with an UVC.
I started with this issue and managed to get MJPEG working flawlessly - the stack is very accessible and the example in the above link was quite self-explanatory.
The next step in my application is implementing H264 capture. I have an UVC - descriptor below - that has two streaming interfaces:
UVC Descriptor
I tried (and failed hilariously) to switch the current interface. Take, for example, the following function:
This works great (for the default interface) - but I'd like to also parse the secondary interface (the H264 one) and switch to that interface when the user requests H264 video.
Right now I managed to get that working (to test the functionality), by setting the parameters for MJPEG and before starting acquisition, switching the interface number to the (known) H264 one. Which is ugly and naturally not production-worthy.
The parsing of the video packets is the exact same one would use to validate and reconstruct a JPEG, I'm using the same function and I'm getting valid AUs (multiple NALs for consecutive packets with the same FIDs).
I have a hunch that the stack is currently written to only support one interface (it makes sense, 90% of UVCs in the wild only have one), but I'm sure there's a way to select/ switch the interface numbers after the initial parsing and still be able to get info about the current interface, correctly request the stream format etc. I just couldn't find it.
I'd appreciate any kind of pointers regarding this issue.
Thank you kindly!
The text was updated successfully, but these errors were encountered: