Getting restart with the Opsis

[David LeP0le]

Hello,

i was some kind of early adopter of the numato opsis.

I get it on crowdsupply. I let it in my studio for year and i try to re use it now since 3 days, concentrate on it.

What i feel is like it's a quickly difficult card to work with.

It's not easy to find the good information to use it really.

Best place is unfortunenately not the website of the project.

i mean : https://hdmi2usb.tv/

There it's a place to learn that the card can do a lot but no way to learn other things except flashing thing.

In that case it's possible to have a way to something.

It's quite amazing.

I need to search something really hidden and i find some help there:

https://debconf-video-team.pages.debian.net/docs/opsis.html

but it's quite difficult to figure out how to simply use the card and the switch...

So The displayport are simply optionals.

So it's trickky to understand because there is 5 years since the opsis is out...

It's not easy to drive a opensource project like that...Ok

BUT it's impossible to let the final-user only in a programming zone, with no other perspectives.

i think there is a problem.

So i don't want to be rude, i'd just want something to work.

Maybe it's possible to get exemple of setup and a firmware adapt for different setup...with differerent repo in function of uses and projects

It's communication and education.

I'm just trying to use the opsis and i'm just a professionnal of making picture for shows and film, so i'm some kind of final user.

That's why i expect efficency, and clear way to work with.

It mean : plug that, plug this, use that raspberry or laptop with that setting, and a minima tricks to work with all the port i mean ethernet so old tech, and displayport...

And after what soft to tallk with the card with all the links and howto get something stable. clear repo for ubuntu, or debian, it's not easy like it is now.

A tuto for starting something from scratch... at the bottom level to more complicated examples.

Really i want to help at my level.

THE SITUATION

So  i use the hdmi ports i understant how to start the inputs and outputs

I understand how to play with the matrix (these commands need to be on a page of https://hdmi2usb.tv/ and how to get there, install and so on)

The problems i got:

when i plugs cameras i need to set the videomode to PAL or NTSC so 12 or 13 720X576 give the best results, i can get 2 cam working in that mode

BUT no screen sync, if i plug my computer it detects the opsis 1280x720 but orange screen on my display, x c 0 0 or other changes give nothing else.

Secondary mde change nothing... And the encoder status announce 0fps and 0 quality...

You understand it's quite impossible to use it for a show...

Which solution can we build to give a chance to this opsis...

Thanks

Regards

[Carl Karsten]

first a note about labels  there is a bug https://github.com/timvideos/HDMI2USB-litex-firmware/issues/483

so we will only use the "1,2" labels when cut/pasting output, like my Opsis shows:

output1: 1280...@50.00Hz from input2 (underflows: 0)

otherwise we will talk about input 0 and 1

Orange means there is no data on input 1

I should mention this is also new, so people may tell you it is from an orange hdmi input if they have not used this version.

good news: you have successfully flashed new firmware.

Red means there is no data on input 0

With only a display device (lcd) plugged into output0, you should see:

x c 0 0 = red

x c 1 0 = orange

x c p 0 = test pattern

I tried to make a quick demo of how to use the UVC over usb, and that failed for me. 

I have not had time to debug.

if you do:

x c p e

you should get the test pattern on /dev/video0 (or whatever your linux system assigns it)

Are you able to see the test pattern on some app that will read from a uvc viddo device?

This has worked in the past:

gst-launch-1.0 \

-v \

v4l2src device=/dev/video0 !\

decodebin !\

queue ! videoconvert !\

fpsdisplaysink sync=false

This gives me a black stream.

I need to revert my firmware to

Jun 2 2019

v0.0.4-487-g5940dcb

or

Sep 30 2018

v0.0.4-340-g3fb4e7c

as I know one of those had working uvc.

but no time today :(

 

x c 0 0 or other changes give nothing else.

Secondary mde change nothing... And the encoder status announce 0fps and 0 quality...

You understand it's quite impossible to use it for a show...

Which solution can we build to give a chance to this opsis...

Thanks

Regards

--
You received this message because you are subscribed to the Google Groups "hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/hdmi2usb/1b6648c9-24d9-46eb-9952-85e8aa9074cb%40googlegroups.com.

--

Carl K

[Carl Karsten]

quick tip about debugging v4l device:

sudo modprobe vivid

sudo dmesg

[364212.353006] vivid-000: V4L2 capture device registered as video2

gst-launch-1.0 \

-v \

v4l2src device=/dev/video2 !\

decodebin !\

queue ! videoconvert !\

fpsdisplaysink sync=false

You should see color bars and some very small text (too small for me to read) in the upper corner.

This helps confirm that the gst command can display video data.

It does not confirm that the Opsis is not working, just helps eliminate possibilities.

--

Carl K

[David LeP0le]

Hello,

i test many things. First thanks to being here...

On the irc channel i think you give me a solution by talking about udev rules,

For me i can not install hdmi2usb-mode-switch

sudo apt install hdmi2usb-mode-switch
it give an error of dependencies:

Les paquets suivants contiennent des dépendances non satisfaites :
 hdmi2usb-mode-switch : Dépend: ixo-usb-jtag (>= 0.0.1) mais il n'est pas installable
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

So i find the rules there :https://github.com/litex-hub/litex-buildenv-udev

and i build it from the script.

Now it seem to work.

In guvcview, i can catch something but it's unstable.

I want to use OBS https://obsproject.com/ but no picture, obs list the opsis but nothing happen...

SITUATION

I succeed to get to cam working and possibilties to switch cams  on 2 differents screens.

Unfortunatly only working in PAL mde mode 13.

If i want a conference style one cam and one cam everythings need to be in video_mode pal, even if i set a secondary mode in 1280x720 50hz or 60hz.

If i got a good size from my computer screen, the cam is glitchy.

So i continue experiments.

[Andrew Ruthven]

On Tue, 2020-05-26 at 12:33 -0500, Carl Karsten wrote:
>
> I need to revert my firmware to
> Jun 2 2019 v0.0.4-487-g5940dcb
> or
> Sep 30 2018 v0.0.4-340-g3fb4e7c
>
> as I know one of those had working uvc.
>
> but no time today :(

I decided to tinker with my Opsis board over the past few days, and
with thanks for Carl for some help in IRC I have it up.

I have found that to get uvc working I needed to use v0.0.4-487-
g5940dcb - all newer images fail when I run gst-launch-1.0 with the
following error:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device
'/dev/video0' failed during initialization
Additional debug info:
gstv4l2object.c(3758): gst_v4l2_object_set_format_full ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Call to TRY_FMT failed for MJPG @ 1280x720: Input/output error
Execution ended after 0:00:05.232390828
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

I am running Debian Bullseye on my laptop. I have also tested with
mplayer and vlc and get similar errors.

Is there another way to display the encoded content since the newer
firmware images have been used at conferences, they must be working!

Cheers,
Andrew

--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |

[Carl Karsten]

Jan 20 2020 v0.0.4-721-gc27ca25 -

I have seen UVC over usb work.  a friend used it with a DLSR to show art pieces he was selling at a "live art show"

I will also say there is something "different" about it. it doesn't "just work" like other versions.  maybe it needs an extra parameter in the gst pipeline.

What does just work is the ingest.py and voctomix.  You may as well take a run at setting that up as it is good to be familiar with if you are doing any of this.

get the base installed and working, with test patterns and I'll help you swap in the Opsis bit:

easiest is to build up a machine from bare metal, if you have one handy (i3 cpu is fine)

https://debconf-video-team.pages.debian.net/ansible/usb_install/usb_quick_start.html

--
You received this message because you are subscribed to the Google Groups "hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hdmi2usb/4d3d51bcee1f502e70bfa37d3135d5587a04071a.camel%40etc.gen.nz.

--

Carl K

[Ewen McNeill]

On 2020-06-22 23:09, Andrew Ruthven wrote:
> On Tue, 2020-05-26 at 12:33 -0500, Carl Karsten wrote:
>> I need to revert my firmware to
>> Jun 2 2019 v0.0.4-487-g5940dcb
>

> I have found that to get uvc working I needed to use v0.0.4-487-
> g5940dcb - all newer images fail when I run gst-launch-1.0 with the

> following error: [...]

>
> Is there another way to display the encoded content since the newer
> firmware images have been used at conferences, they must be working!

I'm not sure that anything newer than v0.0.4-487-g5940dcb (2019-06-02)
*has* been used at conferences *for video capture*. ISTR both Carl and
Ryan saying that they'd stuck with an "older" release for their
production captures, and there are some issues in the GitHub project
about problems with newer versions.

FWIW, the LCA2020 uses of the Opsis was pretty minimal, as there were
issues getting them to interoperate with the venue SDI video senders
(built into the venue rooms), and IIRC those SDI video senders were
1080p rather than 720p (the Opsis can't do 1080p60 for capacity
reasons). So instead a commercial product was used to do video capture
at LCA2020. IIRC the Opsises were used only for one side element (and
"speaker video testing" (pass through to projector) at LCA2020, rather
than being more fully used for video capture at previous LCA, etc.

Carl might remember more of those details. But I wouldn't assume "newer
than v0.0.4-487-g5940dcb" "must have" been working at conferences.

As Carl's later reply says, maybe there's some additional parameter
tweaks required. But it's also possible something in the USB video
stream got subtly broken by later builds (which pulled in lots of
upstream Litex changes), so I wouldn't immediately rule out the idea
that the USB video output is somehow invalid in later builds.

(FTR, I don't have an Opsis. The only work I've done with them was at
LCA2020's video prep week; and that only got so far before logistical
issues caused us to run out of time.)

Ewen

[Andrew Ruthven]

On Tue, 2020-06-23 at 10:16 +1200, Ewen McNeill wrote:
> On 2020-06-22 23:09, Andrew Ruthven wrote:
> > Is there another way to display the encoded content since the newer
> > firmware images have been used at conferences, they must be
> > working!
>
> I'm not sure that anything newer than v0.0.4-487-g5940dcb (2019-06-
> 02)
> *has* been used at conferences *for video capture*. ISTR both Carl
> and
> Ryan saying that they'd stuck with an "older" release for their
> production captures, and there are some issues in the GitHub project
> about problems with newer versions.

Ah, that is interesting. I was going by the "Use at" column on this
spreadsheet:

https://docs.google.com/spreadsheets/d/e/2PACX-1vTmqEM-XXPW4oHrJMD7QrCeKOiq1CPng9skQravspmEmaCt04Kz4lTlQLFTyQyJhcjqzCc--eO2f11x/pub

> FWIW, the LCA2020 uses of the Opsis was pretty minimal, as there
> were
> issues getting them to interoperate with the venue SDI video senders
> (built into the venue rooms), and IIRC those SDI video senders were
> 1080p rather than 720p (the Opsis can't do 1080p60 for capacity
> reasons). So instead a commercial product was used to do video
> capture
> at LCA2020. IIRC the Opsises were used only for one side element
> (and
> "speaker video testing" (pass through to projector) at LCA2020,
> rather
> than being more fully used for video capture at previous LCA, etc.

Interesting, and also disappointing. But I can certainly understand
that if 1080p is required that makes life difficult with the Opsis.

> Carl might remember more of those details. But I wouldn't assume
> "newer
> than v0.0.4-487-g5940dcb" "must have" been working at conferences.

As stated, I was using the information on the Google spreadsheet for my
statement.

> As Carl's later reply says, maybe there's some additional parameter
> tweaks required. But it's also possible something in the USB video
> stream got subtly broken by later builds (which pulled in lots of
> upstream Litex changes), so I wouldn't immediately rule out the idea
> that the USB video output is somehow invalid in later builds.

The difference between the working v0.0.4-487-g5940dcb build and the
"broken" v0.0.4-489-geaab51f build in the git repo is a one line change
that looks highly unlikely to be the cause. That was the first thing I
went to check.

My expectation is that other modules which are pulled in for the build
have caused the breakage or change in behaviour.

Perhaps the build process should use versioned dependencies on other
modules? If that is possible of course.

[Ewen McNeill]

On 2020-06-23 10:48, Andrew Ruthven wrote:
> My expectation is that other modules which are pulled in for the build
> have caused the breakage or change in behaviour.
>
> Perhaps the build process should use versioned dependencies on other
> modules? If that is possible of course.

For "library" dependencies (for want of a better description) they are
mostly git submodules, so effectively pinned that way. But due to the
way that litex-buildenv and the hdmi2usb git repos ended up somewhat
linked (litex-buildenv was forked from the hdmi2usb one), I think
there's ended up being "build dependencies" changes for other reasons
(in litex-buildenv, which then got pulled back into hdmi2usb to try to
keep the two in sync).

The tools were effectively pinned through being packaged in conda, and
the download scripts often pinning a specific revision. But those too I
suspect got updates pulled in via litex-buildenv changes.

The main upstream dependencies (litex related things) has had a *lot* of
refactoring in the last 6-9 months, which means any given update in that
dependency pull in quite a bit of change. (I spent quite a while
debugging one fallout of that in litex-buildenv on another small board.)

Ultimately I think the lack of a good regression test setup for the
Opsis (beyond "it builds", which I think is all the cloud CI can do)
probably means these issues are discovered rather late (and "production
uses", eg, at conferences, often end up sticking with a "known good"
release if they're being prepped on a tight time schedule). The
relative lack of developer attention certainly doesn't help (eg, Tim who
started the project has about 10 other projects, and what seems like 3
full time jobs as well!).

If the "breaking revision" is a one line change that seems unrelated,
the most likely cause is that build pushed something else to be laid out
differently, which rippled through the behaviour due to insufficient
constraints. And those bugs are hard enough to figure out in software,
let alone hardware :-)

Off the top of my head my best guess for what to do to debug it would be
to try to figure out how the video stream (over USB) is corrupted, and
see if there's some pattern in that effect that might give a hint to how
it's going wrong (eg, dropped bits/bytes, duplicated bits/bytes,
reordering, etc). But I have neither the time, nor the hardware, to do
anything about that myself.

Ewen

[Carl Karsten]

Jan 20 2020 v0.0.4-721-gc27ca25

it was used in production for a day about 2 weeks ago, so I've marked it as stable.

I would use it untli there is a soild bug report against it.

the issues we (including me) are bumping into haven't really been demonstrated in a controlled way, like

this works with this build, but the same test fails with this new build.  I always fumble around trying to test it manually, because yeah, we don't have good tests.  but we are close! or something....  

This next part, I would not bother engaging in this project unless you plan on hacking on the hdmi2usb code.  I suspect it will take someone horus to get it set up and you need a relay board to power cycle the opsis.  The relay board has it's own issues, so either you end up debugging the relay board, you you find a better one, figure out how to make the test code work with both, or get me to buy a better one.    This is a bit of work that is pretty far down on my priority list.  now the the wordy disclaimer is out of the way...

We have been muddling with constructing a regression test setup.  We is really just me, Tim is aware of it when it sends him random emails that he has learned to ignore because my tests setup is broken and sending him failed test runs because of a permissions issue or something not related to the the thing being tested.

https://github.com/CarlFK/litex-buildenv-jenkins

Also it is current turned off because I was shuffling hardware around.  The good news is everything is mounted inside a 1u case, so I should be able to power it up and run the Jan 20 2020 aka 4-721 build though all the tests.

btw - there is a bug/feature/whatever in debian buster:

Opsis comes up as 2 video devices on buster
https://salsa.debian.org/debconf-video-team/ansible/-/issues/41
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930860

Which I think is going to throw a wrench in my "use vocto to test" plan.

If you are up for some yac shaving, I would dig into the udev rules and how this new feature impacts them.

--
You received this message because you are subscribed to the Google Groups "hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hdmi2usb/e9ddc76c-14e5-daab-fa89-beed5cd9bc29%40mcneill.gen.nz.

--

Carl K

[Andrew Ruthven]

Hey,

As suggested by Carl I've built up a test box using voctomix, and
confirmed that my Opsis board running HDMI2USB v0.0.4-721-gc27ca25
works with Voctomix GUI. I've been able to simplify the GStreamer
pipeline that is displayed by voctomix-ingest and now have it working
on my laptop. This is the simplest case:

gst-launch-1.0 \
-v \
v4l2src device=$device !\
jpegdec !\
fpsdisplaysink sync=false

Using decodebin doesn't work, it needs to be jpegdec.

Something to note, if you connect to the serial interface (/dev/ttyACM0
for me) first, then you trigger a bug[0] and an Input/Output error is
displayed.

Cheers,
Andrew

[0] https://github.com/timvideos/HDMI2USB-fx2-firmware/issues/14

[Andrew Ruthven]

Hey,

On Mon, 2020-06-22 at 19:01 -0700, Carl Karsten wrote:
> Jan 20 2020 v0.0.4-721-gc27ca25
> it was used in production for a day about 2 weeks ago, so I've marked
> it as stable.

Thank you.

> the issues we (including me) are bumping into haven't really been
> demonstrated in a controlled way, like
> this works with this build, but the same test fails with this new
> build. I always fumble around trying to test it manually, because
> yeah, we don't have good tests. but we are close! or
> something....

Having a regression suit that tests against the actual boards sounds
like a fantastic idea! And yeah, testing with hardware is hard.

> btw - there is a bug/feature/whatever in debian buster:
>
> Opsis comes up as 2 video devices on buster
> https://salsa.debian.org/debconf-video-team/ansible/-/issues/41
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930860
>
> Which I think is going to throw a wrench in my "use vocto to test"
> plan.

This didn't affect my testing. It appears that GStreamer uses the first
device by default, which is the one which has the video stream. The
second one has the metadata. I plugged the board, ran:

/usr/bin/voctomix-ingest --video-source hdmi2usb

And it worked perfectly.

[Carl Karsten]

Ah right. 

production is a problem as we use a udev rule fired by the detection of the usb device being plugged in, and our current code ends up using the metadata device ends up being the one used.

To see all that in action:

https://github.com/CarlFK/veyepar/wiki/System-Stack#how-to-do-next

and then put your box in the [opsis] role:

https://github.com/CarlFK/video-stack-bin-chicken/blob/master/cboxs/hosts#L33

I am thinking of committing this config somewhere so there is a "Use Opsis with Voctomix" example but I am not sure where it should live.  the "what next" hasn't been accepted into the debian video team repo, which is where I would expect this to be too.  my system stack wiki page is getting a bit bloated.   I am also not sure this example needs to exist like that as it is easy enough to create once you get familiar enough with ansible to setup a production config, and "now" is about the right time to figure that out.   I think :p

--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz              |
Catalyst Cloud:                | This space intentionally left blank
   https://catalystcloud.nz    |

--
You received this message because you are subscribed to the Google Groups "hdmi2usb - A HDMI capture solution" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hdmi2usb+u...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/hdmi2usb/8211c20009d44075ecb4be428d27da326f51f1a8.camel%40etc.gen.nz.

--

Carl K