• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 359 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

h264 encode stops prematurely

Greg Ellis
Prodigy 70 points

Hi,

The problem I'm having is that my h264 encode pipeline stops encoding prematurely and the kernel reports the following error:

VPSS_FVID2:queue timeout
kernel BUG at drivers/media/video/ti81xx/ti81xxvin_main.c:840
Unable to handle kernel NULL pointer dereference at virtual address 00000000

The pipeline I'm using is as follows:

gst-launch v4l2src always-copy=false queue-size=16 num-buffers=5000 decimate=2 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1280,height=720,framerate=(fraction)30/1' ! omxbufferalloc numBuffers=16 ! omx_h264enc bitrate=5000000 ! gstperf ! filesink location=v4l2cap.h264

I'm using a digital video generator as the source outputting 720p at 60fps over component. The 'decimate' parameter on the v4l2src effectively reduces the frame rate to 30fps. The caps filter stipulates the correct format, resoultion and frame rate. During encoding, 'gstperf' indicates that captured video is encoded at 30fps.

I get the same problem when the frame rate is reduced to 15fps (decimate=4) so it doesn't look like a stability issue, although It does manage to encode around 2500 frames at 15fps, compared to around 1000 at 30fps.

Has anyone else had this problem or know how to resolve it?

Regards,

Greg.

  • 0
    Prodigy 70 points

    Hi,

    Thought I'd better post an update in case anyone finds it useful.

    I resolved this issue by applying some patches to the kernel source and rebuilding it. I found the patches in the following thread:

          http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/186865/675787.aspx#675787

    I can now capture and encode video with no crashes.

  • 0 in reply to Greg Ellis
    TI__Mastermind 20245 points

    Hi,

    This was a problem with V4L2 capture driver. We have fixed it now.

    Regards,

    Hardik Shah

  • 0 in reply to HardikShah
    Genius 3120 points

    Hi Hardik,

    We are planning to migrate to latest ezsdk_5_04_00_11 which has PSP version "linux-2.6.37-psp04.04.00.01".

    Is this issue (VPSS_FVID2:queue timeout) fixed in this PSP version? Can I get 1080P60 FPS with this?

    Regards,

    Krunal

  • 0 in reply to Krunal Patil
    TI__Mastermind 20245 points

    Hi,

    You will have to apply same patches as above to solve the issue.

    Regards,

    Hardik Shah

  • 0 in reply to Krunal Patil
    Prodigy 70 points

    Hi Krunal,

    I am using EZSDK 5_04_00_11 and PSP linux-2.6.37-psp04.04.00.01 with the patched kernel and I can capture, encode and preview 1080P60 with no stability issues.

    Here is the pipeline if anyones interested:

    gst-launch v4l2src always-copy=false queue-size=16 num-buffers=1000 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1920,height=1080,framerate=(fraction)60/1' ! omxbufferalloc numBuffers=16 ! tee name=t ! queue ! omx_scaler ! v4l2sink t. ! queue ! omx_h264enc bitrate=5000000 ! gstperf ! filesink location=v4l2cap.mp4 t.

    Regards,

    Greg.

  • 0 in reply to Greg Ellis
    Genius 3120 points

    Greg,

    Thanks for the confirmation.

    I am using Android so I may take sometime to integrate all the ezsdk components to Android SDK. Also, I need to port ezsdk kernel to Android and make necessary changes for HDMI capture (as I have done for previous ezsdk.).

    I will keep everyone posted for the progress with ezsdk5_04 with Android.

    Thanks,

    Krunal

  • 0 in reply to Krunal Patil
    Prodigy 70 points

    Krunal,

    Having made such a bold statement in my last post, I thought I'd better go back and double check 1080P60. I'm happy with 720P30, so I haven't tried to use 1080P60 in anger...until now.

    The above pipeline is fine because it terminates after 1000 frames (num-buffers=1000), hence the bold statement; but if you up the number of frames to 10,000, the pipeline will usually hang before it gets there. Occasionally it manages the full 10,000 frames, but mostly it doesn't. It just hangs after a random number of frames and no error is reported. So to clarify, there are still stability issues with 1080P60 on this platform. I guess stability would improve if you lowered the encode bitrate and/or the framerate.

    In fact, 1080P30 is much more stable, even with a much higher bitrate of 10Mbps. I have run the pipeline several times and it has not hung once.

    Something else to be aware of is that gstperf indicates that encoding max's out at 42fps. So your decode and display pipeline will have to account for this by regulating the framerate supplied to the display. I have used the videorate element with a caps filter to force the framerate as follows:

    gst-launch filesrc location=v4l2cap.mp4 ! h264parse ! omx_h264dec ! omx_scaler ! videorate ! 'video/x-raw-yuv,framerate=(fraction)42/1' ! gstperf ! v4l2sink

    Sorry for the mis-information. Hope this helps.

    Regards,

    Greg.