Linux/AM5728: GStreamer mjpeg decode issue

Hello,

I am sorry for the delay but I ran some tests on my side.
I was able to reproduce the error with this pipeline also:
root@am57xx-evm:~# gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12, width=1280, height=720, framerate=30/1 ! ducatijpegenc ! jpegparse ! ducatijpegdec ! vpe ! video/x-raw, format=NV12, width=320, height=200 ! waylandsink sync=false -e
Setting pipeline to PAUSED ...
[ 571.646722] omap-iommu 55082000.mmu: 55082000.mmu: version 2.1
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock

(gst-launch-1.0:1373): GStreamer-CRITICAL **: gst_buffer_peek_memory: assertion 'GST_IS_BUFFER (buffer)' failed

** (gst-launch-1.0:1373): CRITICAL **: gst_fd_memory_get_fd: assertion 'mem != NULL' failed
Caught SIGSEGV
#0 0xb6ac2a40 in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0xb6c05b84 in ?? () from /usr/lib/libglib-2.0.so.0
Spinning. Please run 'gdb gst-launch-1.0 1373' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
^Chandling interrupt.
Interrupt: Stopping pipeline ...
EOS on shutdown enabled -- Forcing EOS on the pipeline

I observed this error even more often(almost every time). I tried on my side to replease vpe with videoscale in my case. The error was not observed.

However, I tried this pipeline on my side:
gst-launch-1.0 -v videotestsrc ! video/x-raw, format=NV12, width=1280, height=720, framerate=30/1 ! ducatijpegenc ! jpegparse ! ducatijpegdec ! queue ! vpe ! video/x-raw, format=NV12, width=320, height=200 ! waylandsink sync=false -e -v
I ran it around 20th times and I was not able to reproduce it.
-e option was added also in the pipeline to make sure when ctrl+c is used the EOS will be send.

Hope this helps.

BR
Margarita

Did investingation bear any fruit yet, or is it still early?

Unfortunately we need to also rescale videos and simultaneusly use several videos as customers require specific screen layout.

It looks that just pipeline in previous post works but when I add scaling with caps filter at end I could reproduce same issue in about 1/10 cases.

If there was a way to take output from vpe and do accellerated rescaling it would also work. videoscale isn't very feasible as it takes too much cpu.

Our ideal would solution would be hardware accellerated overlay that could be displayed in kmssink/fullscreen wayland application.

A possibility is to compile gstreamer gl plugin. Currently it isn't compiled because autoconf couldn't find libraries(for example doesn't find wayland-egl library). But maybe I will find once I compile it that its also slow because it needs copy buffers to texture without dri. 

That look it works but it isn't exactly our problem as it doesn't involve scaling. I still get errors if I use different resolution in first and second filter for example:

first still has width=(int)640, height=(int)480  but just change second one to width=(int)800, height=(int)600
or if I keep first filter same but change output one to something nonstandard like width=(int)111, height=(int)232
then I get completely black window.

Also I tried if add second vpe for scaling would help. If I just test vpe by
videotestsrc ! CAPS1 ! vpe ! CAPS2 ! waylandsink then it does resizing correctly. 

However in pipeline below I get about once in ten tries same segfault as before.
You need to replace ! waylandsink sync=false with:

! vpe ! 'video/x-raw, format=(string)NV12, width=(int)1040, height=(int)333' ! waylandsink

Hello,

I ran around 20th times this pipeline:

gst-launch-1.0 -e videotestsrc ! 'video/x-raw, format=(string)NV12, width=(int)640, height=(int)480, framerate=(fraction)30/1' ! queue ! ducatijpegenc ! queue ! jpegparse ! queue ! ducatijpegdecvpe ! 'video/x-raw, format=(string)NV12, width=(int)480, height=(int)320' ! queue ! waylandsink

It seems to work I do not observe seg.fault on my side.

I executed this pipeline also:

root@am57xx-evm:~# gst-launch-1.0 -e videotestsrc ! 'video/x-raw, format=(string)NV12, width=(int)640, height=(int)480, framerate=(fraction)30/1' ! queue ! ducatijpegenc ! queue ! jpegparse ! queue ! ducatijpegdecvpe ! 'video/x-raw, format=(string)NV12, width=(int)111, height=(int)232' ! queue ! waylandsink

/GstPipeline:pipeline0/GstWaylandSink:waylandsink0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)NV12\,\ width\=\(int\)111\,\ height\=\(int\)232\,\ framerate\=\(fraction\)30/1"

I do not observe "black" screen, as you could see.

Please check this patch also:

http://git.ti.com/glsdk/gstreamer1-0-plugins-bad/commit/3a5a7f778b3c3259faab04748e7b10f0fd696aab

BR
Margarita

Not sure why, maybe you used earlier sdk version and this was added later?

As for pipelines I get bug mainly by concurently launching pipelines, saving it to file p then use

for i in `seq 1 5`; do
  sh p&
done

As I used latest sdk patch is already applied(I tested both source/binary as binary eliminated possibility of miscompilation on our side). I reverted that, makes no difference on mjpeg.