TDA4VE-Q1: J721S2 SDK 9.02

Part Number: TDA4VE-Q1

Tool/software:

We are trying to create two pipelines that each utilize an instance of the v4l2h264enc element. For our purposes, we would like the output to be composed of entirely IDR frames. However, no matter what/how the extra-controls property is set to, we are only getting 1 IDR frame at the very beginning and the rest are P frames. For the extra-controls, we are setting video_gop_size = 1 and h264_i_frame_period = 1. The property is set in the pipeline that is created and run first. We also tried setting the property for both pipelines, with no change. For the method of setting the pipeline and property, we have tried 2 ways.

The first way we used gst_element_factory_make to construct the pipeline and linked each element. To set the extra-control property for the encoder here, we created a GstStructure populated with the proper key/value pairs. The GstStructure was then set using g_object_set. This did not seem to affect the output stream at all.

The second way we used the example from the multi_cam_codec demo application. The entire pipeline was written as a string and and launched using gst_parse_launch. Again, the output stream did not change no matter what we changed the properties to.

In the application, we are saving the stream to file by pulling a sample when the "new-sample" signal is sent. We then retrieve the buffer using gst_sample_get_buffer. The buffer is then mapped using gst_buffer_map. The mapped buffer data member is then written to a file using the mapped buffer's size member. We found using the V4L2 API to perform the encoding does result in every frame being an IDR frame, but Gstreamer is not able to. We would like to use Gstreamer for the simplicity, and would appreciate help with this issue. We would like to continue using SDK 9.2 and avoid upgrading to SDK 10.0.

  • Hello Joe, 

    Apologies for the delay in response. 

    No need to upgrade to 10.0 SDK, this feature is supported in the 9.02 SDK. Please see below pipeline: 

    gst-launch-1.0 is-live=true num-buffers=1000 ! video/x-raw,format=NV12,width=1920,height=1080, framerate=30/1 ! v4l2h264enc extra-controls="enc,video_gop_size=1,prepend_sps_and_pps_to_idr=1" ! filesink location=idr.264

    If you run ffprobe -show_frames -i idr.h264, you can see that each frame is an IDR frame. 

    As for the method being used to set property, gst_parse_launch with a proper string should work. Try updating your string to use the properties I shared above and your output data should consist of all IDR frames.

    Best,

    Brandon

  • We have tried those pipeline settings using gst_parse_launch and gst_element_factory, but the resulting stream still only contains a single I frame at the beginning.

  • Hi Joe, 

    Before you moved to gst_parse_launch, could you first try the pipeline I shared in command line?

    Please also attach your .c file that contains the gst_parse_launch call.

    Thanks,

    Brandon

  • We tried launching the pipeline with a few modifications to make it work with our input, which is a collection of YUV frames in individual files. We tried the two following pipelines:

    gst-launch-1.0 multifilesrc location=%010d.yuv ! video/x-raw,format=NV12,width=1920,height=1080, framerate=30/1, interlace-mode=progressive, colorimetry=bt601 ! v4l2h264enc extra-controls="enc,video_gop_size=1,prepend_sps_and_pps_to_idr=1" ! filesink location=idr.264

    and

    gst-launch-1.0 multifilesrc location=%010d.yuv ! video/x-raw,format=NV12,width=1920,height=1080, framerate=30/1, interlace-mode=progressive, colorimetry=bt601 ! v4l2h264enc extra-controls="enc,video_gop_size=1,prepend_sps_and_pps_to_idr=1,h264_i_frame_period=1" ! filesink location=idr.264

    Neither pipelines resulted in a stream consisting entirely of key frames. Since it is not working on the command line interface with just gst-launch-1.0, we are hesitant to send a C file just yet.  We feel that the failure of these command line operations should be enough for you to test on your end, and go from there.  But if not, let us know.

  • Hi Brandon;

    I was wondering if you had any more information on our issue?

    Thanks,
    Joe

  • Hi Joe, 

    I apologize for late response. I have just returned back to work after the holiday season. 

    Have you been able to make any more progress on your issue? If not, please share with me the .yuv files you are using in the pipelines you shared above. Also, were you able to try this pipeline: 

    gst-launch-1.0 videotestsrc is-live=true num-buffers=1000 ! video/x-raw,format=NV12,width=1920,height=1080, framerate=30/1 ! v4l2h264enc extra-controls="enc,video_gop_size=1,prepend_sps_and_pps_to_idr=1" ! filesink location=idr.264

    This uses videotestsrc to create the raw image data. Please try with this to see your output. I have tested this in 9.2 and I know it works, so lets make sure the image you are using supports this.

    Best,

    Brandon

  • Brandon;

    Thanks for the response.

    It seems the fake data source provided does indeed result in only I frames being generated.

    We also tested it on TI's sample NV12 files provided in the psdkra test dataset. These test files also resulted in only I frames being generated.

    The issue seems to arise when we save live data NV12 images to file before being input into the encoder. Running the GStreamer pipeline on these files did NOT result in only I frames being generated. We used the same pipeline as with the psdkra test dataset.

    Attached is this test data, along with a text file including the code used to save the images to file (used generic process to map OpenVX images to pointers and fopen/write/close with generic names).

    Thanks in advance,
    Joe Shidle

    h264_test_yuvs.zip