Mailing List Archive

USB vendor=534d device=2109
Just curious if anyone has fooled around with one of these device with
mythtv?

Tim
Re: USB vendor=534d device=2109 [ In reply to ]
On Fri, Jul 17, 2020 at 4:05 PM Timothy Krantz <tkrantz@stahurabrenner.com>
wrote:

> Just curious if anyone has fooled around with one of these device with
> mythtv?
>
> Tim
>

I would not expect everyone yo go run lsusb on their systems to see if they
have one.. What is it?
Re: USB vendor=534d device=2109 [ In reply to ]
On Fri, 17 Jul 2020 16:41:20 -0500, you wrote:

>On Fri, Jul 17, 2020 at 4:05 PM Timothy Krantz <tkrantz@stahurabrenner.com>
>wrote:
>
>> Just curious if anyone has fooled around with one of these device with
>> mythtv?
>>
>> Tim
>>
>
>I would not expect everyone yo go run lsusb on their systems to see if they
>have one.. What is it?

It looks like it is a cheap USB 2 HDMI capture device:

http://spawn.link/microsilicon-hdmi-capture-device-534d2109/

and that page says it does work with Linux.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
I sent this yesterday and I do not believe it went through. Apologies if this is a duplicate....
>> Just curious if anyone has fooled around with one of these device with mythtv?
>> Tim

> I would not expect everyone yo go run lsusb on their systems to see if they have one.. What is it?

You are correct of course. As Stephen said it is a small USB HDMI capture device sold under MANY different names.

Tim

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 7/21/20 6:16 AM, Timothy Krantz wrote:
> I sent this yesterday and I do not believe it went through. Apologies if this is a duplicate....
>>> Just curious if anyone has fooled around with one of these device with mythtv?
>>> Tim
>
>> I would not expect everyone yo go run lsusb on their systems to see if they have one.. What is it?
>
> You are correct of course. As Stephen said it is a small USB HDMI capture device sold under MANY different names.
>
> Tim

I was given one of these by a friend to evaluate as a replacement for an
HDPVR. The short version of the story is my cable box reverts to 480p
mode as soon as recording is attempted. I remove power from the cable
box to have it reboot and it will return to 1080i mode. Again, if
recording is attempted then the box displays "d2" and returns to 480p
mode. My guess is because this device does not support HDCP.

My friend was able to successfully capture and playback (recent
Ubuntu/5.4.0-42-generic #46-Ubuntu) from this device, I was not (LinHes
4.9.159-1-ARCH). Neither of us could get audio working using this command:

$ ffmpeg -f v4l2 -input_format mjpeg -i /dev/video4 -c:v copy -c:a copy
test.mpg

More details below:

https://pastebin.com/pahhKPiP

$ ffmpeg -f v4l2 -list_formats all -i /dev/video4
[video4linux2,v4l2 @ 0x55bc6a350940] Compressed: mjpeg :
Motion-JPEG : 1920x1080 1600x1200 1360x768 1280x1024 1280x960 1280x720
1024x768 800x600 720x576 720x480 640x480
[video4linux2,v4l2 @ 0x55bc6a350940] Raw : yuyv422 :
YUYV 4:2:2 : 1920x1080 1600x1200 1360x768 1280x1024 1280x960 1280x720
1024x768 800x600 720x576 720x480 640x480

$ v4l2-ctl -l -d /dev/video4
brightness (int) : min=-128 max=127 step=1 default=-11 value=-11
contrast (int) : min=0 max=255 step=1 default=148 value=148
saturation (int) : min=0 max=255 step=1 default=180 value=180
hue (int) : min=-128 max=127 step=1 default=0 value=0

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 7/29/20 11:01 AM, Bob wrote:
> I was given one of these by a friend to evaluate as a replacement
> for an HDPVR. The short version of the story is my cable box reverts
> to 480p mode as soon as recording is attempted. I remove power from
> the cable box to have it reboot and it will return to 1080i mode.
> Again, if recording is attempted then the box displays "d2" and
> returns to 480p mode. My guess is because this device does not
> support HDCP.
>
> My friend was able to successfully capture and playback (recent
> Ubuntu/5.4.0-42-generic #46-Ubuntu) from this device, I was not
> (LinHes 4.9.159-1-ARCH). Neither of us could get audio working using
> this command:
>
> $ ffmpeg -f v4l2 -input_format mjpeg -i /dev/video4 -c:v copy -c:a
> copy test.mpg


I'll say that I had better luck with my device. I got one mostly for
poking around, as the price couldn't be beat.

As for the cable box reverting to 480p upon recording, I'm not sure
what'd be going on there. Unless perhaps the cable box falls back to a
480p failsafe if it doesn't detect a valid HDMI connection? The Fire
Stick I've been testing on seems to behave just fine.

gucview is a good simple app to test recording. And also apparently to
tell the device what resolution it should be streaming in, etc.

But if you really want to test out the device as it's expected to be
used, start with obs-studio. For the most part it will just work, but
on my test machine (Ubuntu 20.04) I had to make a specific adjustment to
get audio recording to work:

1. Run pavucontrol (the pulse audio mixer)
2. Go to Configuration -> USB Video -> Profile: Multichannel input
(for me, it was set to "Mono Input" by default, which gave me no sound)
3. Go to Input Devices -> USB Video Multichannel -> Port: Multichannel Input

At least on my system, this was required to get any evidence that there
was any audio. If your HDMI input to the device is playing audio
currently, in pavucontrol, you should see the VU meter fluctuating with
the received audio levels. Feel free to celebrate just a bit.

Now in obs, you'll want to add a Video Capture Device (V4L2) input in
the "Sources" frame.

Again in obs, go to Settings -> Audio -> Devices -> Mic/Auxiliary Audio
2. Make sure that "USB Video Multichannel" is selected here. Also at
the top set Sample Rate to 48kHZ and Channels to 5.1, assuming that this
is valid for your source.

In the main obs window, in the Audio Mixer frame, you should see
"Mic/Aux 2" with a fluctuating VU meter and you should see above it
video from what you're recording.

If you click the Start recording button, obs will capture a video of
what you're seeing, with audio, at the resolution and the audio profile
that you have configured.

Once you're comfortable with obs working, let's try something from the
command line with ffmpeg:

ffmpeg -f v4l2 -input_format mjpeg -i /dev/video0 -f pulse -i default
-c:v copy -c:a copy mmm.mkv

Here you have specified /dev/video0 for the video input and the default
pulse input (which we configured previously) for the audio input.

After recording for a bit, we can check it out:
Input #0, matroska,webm, from 'mmm.mkv':
Metadata:
ENCODER : Lavf58.29.100
Duration: 00:00:03.19, start: 0.000000, bitrate: 41998 kb/s
Stream #0:0: Video: mjpeg (Baseline), yuvj422p(pc,
bt470bg/unknown/unknown), 1920x1080, 30 fps, 30 tbr, 1k tbn, 1k tbc
(default)
Metadata:
DURATION : 00:00:03.189000000
Stream #0:1: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
(default)
Metadata:
DURATION : 00:00:03.155000000


We can confirm that it's 1920x1080 video with an audio channel. I
couldn't get an audio channel out of only specifying /dev/video0 for the
input, and I'm not 100% sure why. Note however, that the audio is only
in stereo. And it's PCM, so it's not even compressed. I'm not sure
what sort of magic OBS does to get the audio in anything beyond stereo.
The video is about 42mbit/sec, so that'll eat up disk space quickly
unless it's transcoded.
Or if you've got an Nvidia GPU and the appropriate ffmpeg build, you may
be able to offload video encoding to it with the "-c:v h264_nvenc"
option. I haven't been able to verify this as all my testing has been
in a virtual machine. If you have a fast enough machine, you may be
able to get away with CPU-based h246 encoding on the fly. If not, you
could play with other codecs / parameters until you find something that
looks good and doesn't excessively tax the system. Or just rely on
MythTV's after-the-fact transcoding options.


If you're fine with stereo sound, then you might be good to go with a
setup such as the above. And to be honest, despite the output file from
obs having 5.1 channels, I'm not completely certain that it's not just
faking it. The obs documentation states that "There is an automatic
channel rematrixing when either downmixing or upmixing is mandated by a
difference in channel layouts between source and output." So it's
possible that the LFE channel was just logically produced based off of
the stereo input by obs. I'd probably need a 5.1 test tone to see for
sure what's going on, but as far as I can tell YouTube doesn't even
support 5.1 audio on the Fire Stick, so I'm really sure the best way
forward here. If I really wanted to be sure, maybe I could put a true
5.1 audio-containing video file on a thumb drive and capture that from
something that outputs it over HDMI, assuming I know for sure that the
device outputs 5.1 audio.


Anyway, that's about what I know at this point. I haven't fully
investigated this device's ability to be used with MythTV, but after my
brief testing it seems promising. Perhaps as an "External Recorder" as
the Hauppauge HD-PVR2 and Colossus2 devices are available to be used?


-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 7/29/20 7:02 PM, Will Dormann wrote:
> 1. Run pavucontrol (the pulse audio mixer)
> 2. Go to Configuration -> USB Video -> Profile: Multichannel input
> (for me, it was set to "Mono Input" by default, which gave me no sound)
> 3. Go to Input Devices -> USB Video Multichannel -> Port: Multichannel Input
>
> At least on my system, this was required to get any evidence that there
> was any audio. If your HDMI input to the device is playing audio
> currently, in pavucontrol, you should see the VU meter fluctuating with
> the received audio levels. Feel free to celebrate just a bit.


Just to clarify this a bit, as I was having a bit of trouble reproducing
using my own steps. Despite my capture device having only 4 pins, it
has blue plastic inside of the connector, implying that it's USB 3.0. I
figured it was just the manufacturer trying to justify charging a couple
bucks more because it's "USB 3.0" because look at the blue.

Perhaps it's just a quirk of how VMware works, but I can say that in my
testing, when the VM is configured to have a USB port that is:
USB 2.0: There is no audio, and the video preview in obs is pretty choppy.
USB 3.1: There is audio, and the video preview in obs is quite less
choppy. (I blame VMs not having real video acceleration for this)


In my mind, anything with only 4 conductors shouldn't benefit by being
in a USB 3.0+ port as opposed to 2.0. But I suppose in my case I can't
rule out that the VMware implementation of the virtual USB 2.0 port spec
isn't terribly efficient, and that plugging it into a virtual USB 3.1
port just allows it to perform closer to the maximum USB 2.0 speed.


Anyway, long story short, if you're noticing audio trouble, confirm both:
- The USB audio input is configured for "Multichannel" as opposed to "Mono"
- The device is in a good-enough USB port.


I've confirmed that my VM can go straight from being powered off to
being able to capture with ffmpeg a 1920x1080 video with stereo sound
from a Fire Stick using the steps I've described. The obs steps are
just to test things out without having to do it blind. The only odd
behavior I've seen is that sometimes when the capture device is first
plugged into a USB port, the Fire Stick can pause the content being
played (perhaps the same sort of trigger as what caused your cable box
to switch to 480p mode?). But in a real non-VM machine, I'd expect it
to remain plugged in to things so perhaps that wouldn't be a problem.


-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 7/29/20 7:02 PM, Will Dormann wrote:

> If you're fine with stereo sound, then you might be good to go with a
> setup such as the above. And to be honest, despite the output file from
> obs having 5.1 channels, I'm not completely certain that it's not just
> faking it. The obs documentation states that "There is an automatic
> channel rematrixing when either downmixing or upmixing is mandated by a
> difference in channel layouts between source and output." So it's
> possible that the LFE channel was just logically produced based off of
> the stereo input by obs.



For what it's worth, I've confirmed (with a 5.1 speaker test video file)
that obs is indeed faking it by upmixing. Here's a very-recent Linux
kernel patch that makes the audio stereo (as opposed to mono) from this
device (which is apparently a MacroSilicon MS2109 it seems):
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e337bf19f6af38d5c3fa6d06cd594e0f890ca1ac

So if you're on a Windows or OSX system, or a Linux device with a kernel
that's about 2 weeks old or older, you can probably only ever expect to
get mono audio out of this device. If you've got a very recent Linux
kernel, you might be able to get stereo. With yesterday's 5.8.0 kernel,
I have confirmed that the audio coming from the MS2109 is indeed stereo.
But the left and right channels are swapped (as the above kernel commit
suggests), and there seems to be some other bug that prevents any
/dev/video* device from appearing when the device is plugged in.
<https://bugs.archlinux.org/task/67460>
In my testing, removing the virtual sound card device from my VM allows
it to capture video and swapped-stereo sound.

So yeah, it seems not quite ready for prime time. But given the
appropriate efforts spent, it could potentially be viable as a
super-cheap HDMI video capture device.



-WD


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 8/3/20 12:11 PM, Will Dormann wrote:
> So yeah, it seems not quite ready for prime time. But given the
> appropriate efforts spent, it could potentially be viable as a
> super-cheap HDMI video capture device.

So, I did a new experiment today and put my cable box in 720P mode. When
I started to capture the cable box stayed in 720P mode. Previously I had
the cable box in 1080i and once I started to capture the cable box would
change to 480p. In this case (720P), the captured output was will
1920x1080. Do you think this may be a driver issue or is there an ffmpeg
option I need to use?

Thanks for sharing notes.

Bob
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 8/10/20 11:00 AM, Bob wrote:
> On 8/3/20 12:11 PM, Will Dormann wrote:
>> So yeah, it seems not quite ready for prime time.  But given the
>> appropriate efforts spent, it could potentially be viable as a
>> super-cheap HDMI video capture device.
>
> So, I did a new experiment today and put my cable box in 720P mode. When
> I started to capture the cable box stayed in 720P mode. Previously I had
> the cable box in 1080i and once I started to capture the cable box would
> change to 480p. In this case (720P), the captured output was will
> 1920x1080. Do you think this may be a driver issue or is there an ffmpeg
> option I need to use?


If the cable box itself is switching to 480p, then it's hard to point
the figure at the specific culprit. I get the impression that something
"unexpected" happens during the capture process. It's just speculation,
but it could be as simple as the target device "going away" even for
just a moment. For example, I only saw it happen some of the time, but
I've seen my Fire TV stick go into "pause" mode when I started some form
of capture. A potential logic for this might be:
- If the Fire stick ever notices an HDMI signal go away, don't blindly
continue playing (because it may not be connected to a TV)
In the case of your cable box, it could be:
- If the box ever notices an HDMI signal go away, revert to the lowest
common denominator for outputting the video signal (because the
connected device might not support the current video properties).

If this is the case, then there could be a couple of potential solutions:
- See if there is a way to disable the 480p fallback in the cable box
settings. Either through disabling any auto-negotiate options, or
explicitly setting the resolution, if possible.
- Plug the cable box into an intermediate HDMI device, such as an audio
receiver or an HDMI splitter.

Other things to test out may be to see if other capture options, such as
pavucontrol or obs cause the same resolution switch on the box. If they
behave the same, then the problem could be on the device/driver level.
If not, then there may be some userspace trickery that could avoid this
problem.


-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: USB vendor=534d device=2109 [ In reply to ]
On 8/3/20 3:11 PM, Will Dormann wrote:
> But the left and right channels are swapped (as the above kernel commit
> suggests), and there seems to be some other bug that prevents any
> /dev/video* device from appearing when the device is plugged in.
> <https://bugs.archlinux.org/task/67460>

FWIW, this bug is addressed in:
<https://mailman.alsa-project.org/pipermail/alsa-devel/2020-August/172096.html>


-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org