using shmsrc as gstreamer source

[Rinaldo Merlo]

Not really an stb-tester support issue, but any help would be appreciated from the people who understand what stb-run does with its source pipeline. 

In order to possibly run multiple instances of stb-tester on one PC I've been experimenting with putting the decklinkvideosrc into a socket like so:

gst-launch-1.0 -v decklinkvideosrc connection=HDMI mode=720p60 device-number=0 '!' videoconvert '!' queue name=_stbt_user_data_queue max-size-buffers=0 max-size-bytes=0 max-size-time=1000000000 '!' decodebin '!' queue name=_stbt_raw_frames_queue max-size-buffers=2 leaky=upstream '!' shmsink wait-for-connection=0 socket-path=/tmp/multiviewer shm-size=20000000 sync=true 

And from there multiple instances of stb-tester can connect to the same socket, so my stbt.conf source is:

source_pipeline = shmsrc socket-path=/tmp/multiviewer ! video/x-raw,format=(string)UYVY,framerate=(fraction)60/1,\

    width=(int)1280,height=(int)720,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,\

    chroma-site=(string)mpeg2,colorimetry=(string)bt709,sync=true ! videoconvert

This actually seems to work, and my test results seem unaffected compared to using my normal source_pipeline which is...

source_pipeline = decklinkvideosrc connection=HDMI mode=720p60 device-number=0 ! videoconvert

...but it is complaining a lot with gstreamer critical errors, that you can see in the attached debug. 

Particularly worrying are these errors:

0:00:00.038213962 10203 0x7f7e84002de0 ERROR             video-info video-info.c:430:gst_video_info_from_caps: no width property given

0:00:00.038227696 10203 0x7f7e84002de0 ERROR            videofilter gstvideofilter.c:242:gst_video_filter_set_caps:<videoconvert0> invalid caps

0:00:00.038232438 10203 0x7f7e84002de0 WARN           basetransform gstbasetransform.c:1421:gst_base_transform_setcaps:<videoconvert0> FAILED to configure incaps video/x-raw, format=(string)BGR and outcaps video/x-raw, format=(string)BGR, width=(int)1, height=(int)1, framerate=(fraction)0/1

Although if the above was really true I don't see how it would be producing any video at all. But mainly I have a constant stream of errors about my gstreamer clock/timestamps - not sure a problem in itself or just a symptom of something else:

(python:10203): GStreamer-CRITICAL **: gst_segment_to_running_time: assertion 'segment->format == format' failed

test.py: warning: Received frame with suspicious timestamp: 20013129518.988514. Check your source-pipeline configuration.

I've also attached the debug from the server side of creating the shmsink pipeline. Any insight you can give would be appreciated.

[David Röthlisberger]

On Wed, 21 Aug 2019, at 12:47 PM, Rinaldo Merlo wrote:

In order to possibly run multiple instances of stb-tester on one PC I've been experimenting with putting the decklinkvideosrc into a socket like so:

Hi Rinaldo

I assume you mean 1 "stbt run" and 1 or more "stbt tv" -- if you had multiple "stbt runs" trying to control the same device-under-test simultaneously your test scripts would step on each other's toes. :-)

gst-launch-1.0 -v decklinkvideosrc connection=HDMI mode=720p60 device-number=0 '!' videoconvert '!' queue name=_stbt_user_data_queue max-size-buffers=0 max-size-bytes=0 max-size-time=1000000000 '!' decodebin '!' queue name=_stbt_raw_frames_queue max-size-buffers=2 leaky=upstream '!' shmsink wait-for-connection=0 socket-path=/tmp/multiviewer shm-size=20000000 sync=true 

And from there multiple instances of stb-tester can connect to the same socket, so my stbt.conf source is:

source_pipeline = shmsrc socket-path=/tmp/multiviewer ! video/x-raw,format=(string)UYVY,framerate=(fraction)60/1,\

    width=(int)1280,height=(int)720,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,\

    chroma-site=(string)mpeg2,colorimetry=(string)bt709,sync=true ! videoconvert

This is pretty advanced GStreamer usage, and I'm not an expert, but I'm not sure that shmsink is really designed for multiplexing the stream to multiple consumers. Your pipeline is sending the video-frames as raw data (without any metadata like the frame's timestamp or format), so you would need to add some type of payloader & de-payloader to your source & sink pipelines, respectively.

Projects that implement this type of multiplexing include PulseVideo and PipeWire -- you can try them out but we don't provide support for either project on this mailing list.

test.py: warning: Received frame with suspicious timestamp: 20013129518.988514. Check your source-pipeline configuration.

This is the year 2604 so my guess is that it's expecting a timestamp to be present at some particular memory location, but instead there is some other data there (due to the reasons described above).

Kind regards,

David Röthlisberger

Stb-tester.com Ltd.

--

Stb-tester.com Ltd is a company registered in England and Wales.

Registered number: 08800454. Registered office: 13b The Vale,

London, W3 7SH, United Kingdom.

[Rinaldo Merlo]

Actually I did mean stbt run. The HDMI input to my PC blackmagic card comes from a multiviewer (see example screenshot attached) which shows the output of all boxes in the rack - so using this and a RedRat irnetbox IV I am (theoretically) able to run tests simultaneously on up to 16 set-top-boxes using just one PC + card.

I managed to fix the constant stream of gstreamer critical errors by adding a 'do_timestamp=1' parameter to my source_pipeline, so the stbt.conf now looks like this:

source_pipeline = shmsrc socket-path=/tmp/multiviewer do-timestamp=1  ! video/x-raw,format=(string)UYVY,framerate=(fraction)60/1,\

    width=(int)1280,height=(int)720,pixel-aspect-ratio=(fraction)1/1,interlace-mode=(string)progressive,\

    chroma-site=(string)mpeg2,colorimetry=(string)bt709 ! videoconvert

stb-tester is still alerting about the 2064 frame timestamp, so no doubt I am still mangling the pipeline horribly, which I would like to fix, but nevertheless things do seem to be working.