cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
storm-se
Participant
Participant
906 Views
Registered: ‎02-03-2019

Problem with VCU Decoder, MultiScaler and Resolution of 1024x768

Jump to solution

Hi,

we are currently facing a severe problem with the target resolution of our system which is 1024x768.

The system is receiving a video stream via Ethernet, decodes it in the VCU and then scales it down to a PAL resolution of 720x576 by using the MultiScaler. This works fine if the resolution is different from the target resolution (e.g. 1280x720). When the resolution is 1024x768 we get an EOS message back from the pipeline. Switching on DEBUG we can see that a buffer pool request fails:

0:00:04.526261082  3279   0x55a4e3bd90 WARN          v4l2bufferpool gstv4l2bufferpool.c:807:gst_v4l2_buffer_pool_start:<v4l2v
ideo0convert0:pool:src> Uncertain or not enough buffers, enabling copy threshold
/GstPipeline:pipeline0/v4l2video0convert:v4l2video0convert0.GstPad:sink: caps = video/x-raw, format=(string)NV12, width=(int)1024, height=(int)768, i
nterlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/
left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)mpeg2, colorimetry=(string)bt7
09, framerate=(fraction)60/1
0:00:04.599770277  3279   0x55a4e3bd90 WARN          v4l2bufferpool gstv4l2bufferpool.c:1989:gst_v4l2_buffer_pool_process:<v4
l2video0convert0:pool:sink> failed to acquire a buffer: eos
0:00:04.599843764  3279   0x55a4e3bd90 WARN           basetransform gstbasetransform.c:2159:default_generate_output:<v4l2vide
o0convert0> could not get buffer from pool: eos
Got EOS from element "pipeline0".

 The used GStreamer command (for debugging) is:

VIDEO_CAPS="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264,payload=(int)96"

GST_DEBUG=2 gst-launch-1.0 -v udpsrc port=5004 caps=$VIDEO_CAPS ! rtph264depay ! h264parse ! omxh264dec ! queue ! \
              v4l2video0convert capture-io-mode=4 output-io-mode=4 ! video/x-raw, width=720, height=576, format=UYVY ! \
              fakesink

For testing we have created a testvideo which is streamed from a Linux PC:

gst-launch-1.0 -m videotestsrc num-buffers=2000 ! video/x-raw, width=1024, height=768, format=NV12, framerate=60/1 ! x264enc ! mp4mux ! filesink location="testimage-1024x768.mp4"

gst-launch-1.0  -m -v filesrc location ="testimage-1024x768.mp4" ! qtdemux ! video/x-h264 ! rtph264pay config-interval=1 ! udpsink host=192.168.178.65 port=5004

As said, this works fine if the resolution is not 1024x768. Decoding the video without scaling also works and scaling down a video by using a test pattern generator also works:

gst-launch-1.0 -v videotestsrc num-buffers=1000 ! video/x-raw, width=1024, height=768, format=NV12, framerate=60/1 ! queue ! \
     v4l2video0convert capture-io-mode=4 output-io-mode=4 ! \
     video/x-raw, width=720, height=576, format=UYVY ! fakesink

Does someone have an idea what the reason might be? Might this be a strange alignment problem because of the power of two value?

Any ideas are welcome.

Best regards,

Frank

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
storm-se
Participant
Participant
745 Views
Registered: ‎02-03-2019

Since there was no further reaction, I had to debug this myself.

The reason for the problem was a bug in the GStreamer OMX library, function gst_omx_try_importing_buffer in file gstomxvideodec.c. The line

  if (GST_VIDEO_FRAME_SIZE (*frame) < port->port_def.nBufferSize) {

has to be replaced with

  if (GST_VIDEO_FRAME_SIZE (*frame) <= port->port_def.nBufferSize) {

If the resolution is 1024x768, both values are the same, while in other resolutions the frame size of *frame was smaller then nBufferSize. So in effect the branch was not taken although it should. Replacing "<" with "<=" solved the problem.

I have seen that the code in PetaLinux 2020.1 in this file has been reworked (function gst_omx_try_importing_buffer no longer exists). We did not test with PetaLinux 2020.1 so I don't know whether the problem has been solved or whether it still exists. Perhaps someone at Xilinx could have a look.

 

View solution in original post

0 Kudos
3 Replies
watari
Professor
Professor
902 Views
Registered: ‎06-16-2013

Hi @storm-se 

 

What petalinux and gstreamer version are you using ?

 

Best regards,

0 Kudos
storm-se
Participant
Participant
893 Views
Registered: ‎02-03-2019

Sorry, I realized that I forgot this detail after pressing the send button.

We are using PetaLinux 2019.1 with the included GSTreamer. We have also included the VCU patches 2019-12-24_-_AR72324_BSP2019-1_VCU2019-1.tar.gz.

 

 

0 Kudos
storm-se
Participant
Participant
746 Views
Registered: ‎02-03-2019

Since there was no further reaction, I had to debug this myself.

The reason for the problem was a bug in the GStreamer OMX library, function gst_omx_try_importing_buffer in file gstomxvideodec.c. The line

  if (GST_VIDEO_FRAME_SIZE (*frame) < port->port_def.nBufferSize) {

has to be replaced with

  if (GST_VIDEO_FRAME_SIZE (*frame) <= port->port_def.nBufferSize) {

If the resolution is 1024x768, both values are the same, while in other resolutions the frame size of *frame was smaller then nBufferSize. So in effect the branch was not taken although it should. Replacing "<" with "<=" solved the problem.

I have seen that the code in PetaLinux 2020.1 in this file has been reworked (function gst_omx_try_importing_buffer no longer exists). We did not test with PetaLinux 2020.1 so I don't know whether the problem has been solved or whether it still exists. Perhaps someone at Xilinx could have a look.

 

View solution in original post

0 Kudos