Re: Streaming for MiniDebConf BH 2024

[Carl Karsten]

Yes, I will have to use a converter hdmi-usb because I don't have the
hdmi/sdi capture card.

I suggest usb3 or C else you will only get 5fps, who's is kinda ok but you
will want better.

Also you likely want a device is both video uvc, and USB audio.


On Fri, Apr 19, 2024, 7:13 AM Paulo Henrique de Lima Santana <
p...@debian.org> wrote:

> Hi,
>
> Em 12/04/2024 23:13, Carl Karsten escreveu:
> > before you try to build a production box:
> > https://github.com/CarlFK/veyepar/wiki/System-Stack#what-to-do-first
> >
> > https://debconf-video-team.pages.debian.net/ansible/simple_setup.html
> > this links to
> > https://debconf-video-team.pages.debian.net/docs/opsis.html#opsis
> > Which is out of date.  The new devices are similar, but there is no
> > tty interface (that I know of) and I suspect there are other things to
> > trip over.
>
> Thanks, I'm using these docs to follow.
>
> > Do you know how the camera will connect to the voctomix box?
>
> It's Sony HMC 2000.
> The only camcorder I could find to rent here.
>
> > In your list of equipment, I don't see a Black Magic hdmi/sdi capture
> > card.  You will need some way to stream AV data from the camera into
> > the voctomix box.  USB is possible, but will take some fiddling with
> > the config.
>
> Yes, I will have to use a converter hdmi-usb because I don't have the
> hdmi/sdi capture card.
>
> BTW, I found here in Belo Horizonte a factory of this kind of equipament
> https://neoid.com.br/produtos/
>
> "We are NEOiD, the Brazilian brand dedicated to manufacturing
> high-quality cameras and broadcast equipment at affordable prices."
>
> Best regards,
>
> --
> Paulo Henrique de Lima Santana (phls)
> Belo Horizonte - Brasil
> Debian Developer
> Site: http://phls.com.br
> GPG ID: 0443C450
>

Re: Streaming for MiniDebConf BH 2024

[Carl Karsten]

before you try to build a production box:
https://github.com/CarlFK/veyepar/wiki/System-Stack#what-to-do-first

https://debconf-video-team.pages.debian.net/ansible/simple_setup.html
this links to
https://debconf-video-team.pages.debian.net/docs/opsis.html#opsis
Which is out of date.  The new devices are similar, but there is no
tty interface (that I know of) and I suspect there are other things to
trip over.

Do you know how the camera will connect to the voctomix box?

In your list of equipment, I don't see a Black Magic hdmi/sdi capture
card.  You will need some way to stream AV data from the camera into
the voctomix box.  USB is possible, but will take some fiddling with
the config.

On Fri, Apr 12, 2024 at 7:33 AM Nicolas Dandrimont  wrote:
>
> Hi,
>
> On Mon, Apr 1, 2024, at 15:22, Paulo Henrique de Lima Santana wrote:
> >>> Hi,
> >>>
> >>> I talked a little bit about that on video team channel, but I`m
> >>> writting more here.
> >>>
> >>>  From April 27th to 30th MiniDebConf Belo Horizonte 2024 will take
> >>> place and we would like to have streaming and recording the talks.
> >>>
> >>> So, it's my first time trying to do something similar with you have
> >>> done on DebConf.
> >>>
> >>> What we have/will have:
> >>> - Computers
> >>> - Camcorder (rented)
> >>> - Asus capture box
> >>> - Medium size sound mixer
> >>>
> >>> I will use the next weeks to learn how to build the setup, and
> >>> certainly I will have questions :-)
> >>>
> >>> After https://video.debconf.org, this repository should be my fist place?
> >>> https://salsa.debian.org/debconf-video-team/ansible
>
> Yeah, that seems right.
>
> To get started, you can have a go at the simple setup:
>
> https://debconf-video-team.pages.debian.net/ansible/simple_setup.html
>
> This should get you far enough to have a voctomix ready for streaming.
>
> Please poke us on IRC if things aren't working.
>
> >>> But first, would be possible you provide the streaming frontend server
> >>> to allow people watch on it?
>
> We have minidebconf infra up and running, let us know what IP ranges to open 
> up for streaming and you should be able to get going.
>
> Relevant config to be updated:
> https://salsa.debian.org/debconf-video-team/ansible-inventory/-/blob/master/inventory/group_vars/all/streaming.yml?ref_type=heads#L3
>
> Cheers,
> --
> Nicolas Dandrimont
>


-- 
Carl K

Re: [DebConf 23] Guidance for remote speakers

[Carl Karsten]

On Tue, Aug 1, 2023 at 8:13 AM  wrote:
>
> Hi Lucas (2023.08.01_12:35:03_+)
> > > I think it worked acceptably at DebConf 22. *But* it takes quite a bit
> > > of time from core-video team people to get setup. So, if we're going to
> > > support it, I think it would make sense to batch all the remote-speaker
> > > events in a single room (as close to the video team HQ as possible) on
> > > the same day.
> >
> > That would be definitely doable. The only talk which will be fully remote is
> > the one proposed by Ben (mentioned above). The 2 others have in-person
> > speakers, so if we want we can ask them to present without the remote
> > co-speaker.

Old News:
1. It is doable.  If it was not doable, it would be easy to say No
because it can't be done.
2. It is work that is not well defined, documented, and "it depends"
on details that may not be understood beforehand.
 There are a bunch of things (not well defined or documented) that
need to be done by one or more people.  Historically the work doesn't
get done ahead of time and it falls on the video team who says "I wish
someone had done this thing weeks ago..."

New news:
On site presenter + remote presenter, in front of live audience ... is
new and more complicated.

Good News:
The onsite presenter can do whatever they want with their laptop
hooked up. If they  want to run video conference thing like Jitsi and
hook up their own web cams, microphones, audio devices, etc. as part
of their presentation, no one will stop them.  They can expect just as
much help as any other presenter with hooking up their laptop to the
room's AV system.

News we don't want to hear about:
Relying on more help and brian storming as part of getting set up for
their talk 5 min before their talk starts, will not go well. Trying to
get this worked out the week before is also not a good plan.  No one
should expect anything to be working until the start of the opening
session.  In the past, things have happened like
Our equipment is sitting in customs waiting for someone to show up
with a nice enough car.   Wat?
The local company supplying the equipment does not show up until the
morning of the first talk.  Grrr...
The video team not allowed to setup the room until the scheduled time
of the room reservation, which was the scheduled time of the talk.
/o\

Encouraging news:
I would propose allowing remote talks with the following requirement:
The presenter designates a person who will be at the event to be their
advocate.

It is this person's responsibility to "make the talk happen."   If
nothing else, they will show up with their laptop and play a video.
They can do Q by forwarding the question to someone offsite (the
remote presenter.)  If they want to ask the video team's help for
something different, they can work that out.The "something
different" should be the thing that has been done a few times and
someday may evolve into normal offering.

Last year there was a remote talk that did not happen.   I'm not clear
why it did not happen, but if there had been a person in the room
making sure the talk happened, it probably would have happened.


>
> I don't know if it's on your list but the tech-ctte meeting will also
> have most of the panel remote.
>
> > > I advocate requiring pre-recording talks for remote presenters.
> > > With a deadline during DebCamp to deliver recordings, so that they can
> > > be checked and re-recorded/edited if necessary.
> >
> > Sure, we can request that.
>
> We also need a commitment from the content team to take the lead in
> reviewing these recordings and working with the presenters.
> Ideally one person can take the lead on this, I guess.

Yes.

Having an on site person does nothing to ensure the video quality is
ok.  It would be nice if that person worked one on one with the
presenter, and I would certainly keep them in the loop about the
review and critique process.

After a few years, maybe there will be a "remote presenter advocate
pool"  that can take on remote talks.  People who have done this a few
times and know what is going on.


>
> Historically, this has fallen on the video team, during DebCamp when we
> are usually busy trying to get set up for the event, and don't have time
> to do the work.
>

Yes.

The video team's priority is to make sure the whole event happens with
a high degree of certainty.We will never reach 100% certainty, so
there are always things we can do to get closer, like installing
monitoring or improving the docs or training new people.

An individual talk will likely never be a top priority until its
scheduled time, and then it is too late to fix problems.


-- 
Carl K

Re: Open Hardware Camera for Conference Recording

[Carl Karsten]

If the camera is not going to contain the A2D hardware, then we shouldn't
bother talking about such things here, it will just distract from talking
about the camera.

This does not mean we are not interested.  I am interested in smaller and
cheeper, currently I spend about $600USD for a used Panasonic AG-HMC150P.

I am sure you are curious, so here is how integrated hardware solves the
following issues that I can think of.

delay config: We sometimes do use separate audio hardware, and we are able
to work out the delays to accommodate the different latencies so that
everything remains in sync.  The problem is different hardware has
different latencies and it isn't well documented so changes risk problems
that are not quickly solved.   Integrated audio means never having to think
about keeping the two in sync.

quality:   typically the A2D on a camera is better than the typical usb
audio device. the cameras we use have compressors, so clipping is almost
non-existent.

hardware deployment:  the number of components for a typical setup is
enough that it takes significant time to assemble, and it is more than a
person can keep track of in their head, so inventory management and check
lists are part of the process. Integrated audio means less things to pack
and assemble.


On Sat, Jan 16, 2021 at 12:09 PM Sebastian Pichelhofer 
wrote:

>
>
> On Fri, Jan 15, 2021 at 3:57 PM Kyle Robbertze 
> wrote:
>
>> Hi,
>> On 2021/01/15 15:39, Sebastian Pichelhofer wrote:
>> > [...]
>> >  >  >
>> >  >  > As this camera could be a perfect fit for lecture and
>> > conference
>> >  >  > recording we want to learn more about your
>> streaming/recording
>> >  > setup and
>> >  >  > your requirements and discuss if what we have in mind
>> would be
>> >  >  > interesting to you.
>> >  >
>> >  > Our current set-up is documented here:
>> >  >
>> >  > https://debconf-video-team.pages.debian.net/docs/room_setup.html
>> > 
>> >  >
>> >   > > >
>> >  >
>> >  > We currently work at 720p capture at 50 or 60 fps (filming
>> > country
>> >  > dependant) from the cameras, streaming and recording.
>> >  >
>> >  >
>> >  > Thanks!
>> >  >
>> >  > What cameras do you use/prefer currently?
>> >  > IIRC at FOSDEM these were prosumer HD camcorders.
>> >
>> > Sony PXW-X70/4k
>> >
>> >  > Is interlacing an issue with these devices?
>> >
>> > We always shoot progressive and haven't run into any interlacing
>> issues
>> > that I know of
>> >
>> >
>> > OK.
>> >
>> > So a camera that outputs a low latency live stream over Ethernet in a
>> > format that voctomix would understand would be interesting I assume?
>>
>> Very much so. Ideally with mixed in audio so we can let the camera
>> handle the audio/video sync before it gets to Voctomix.
>>
>
> Very good!
>
> We do not have or plan to develop an audio related interface ourselves but
> in theory could attach any existing USB audio device that works under Linux.
> We will test and verify this is works properly with audio/video sync.
> On the other hand I assume that you would be just as happy with the audio
> device not connected to the camera but voctomix directly as long as
> everything remains in sync?
>
> Regards Sebastian
>
>
>
>> Cheers
>> Kyle
>>
>>
>> --
>> ⢀⣴⠾⠻⢶⣦⠀
>> ⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
>> ⢿⡄⠘⠷⠚⠋⠀ Debian Developer
>> ⠈⠳⣄ https://wiki.debian.org/KyleRobbertze
>>
>

-- 
Carl K

Re: Open Hardware Camera for Conference Recording

[Carl Karsten]

 raw video over USB3 (still in development). - this is most interesting to
me.

If the video stream can be consumed by a gstreamer element, good.  The
quickest way to see how that fits into the system is:

https://github.com/CarlFK/veyepar/wiki/System-Stack#i-just-want-to-see-if-my-device-works-with-voctomix

I would be happy to help someone grind through the setup to you can have a
real system to test with.



On Fri, Jan 1, 2021 at 1:03 PM Sebastian Pichelhofer  wrote:

> Dear Deb Conf Video Team
>
> We (www.apertus.org) are developing open hardware and free software
> cameras and technology and are considering advancing one particular
> platform from a prototype to a hardware kit to produce: AXIOM Micro
> https://wiki.apertus.org/index.php/AXIOM_Micro
>
> It has an image sensor with slightly above Full HD resolution, swappable
> lens mount and with two plugin module slots can output HDMI live video
> and/or raw video over USB3 (still in development).
>
> As this camera could be a perfect fit for lecture and conference recording
> we want to learn more about your streaming/recording setup and your
> requirements and discuss if what we have in mind would be interesting to
> you.
>
> Please do not hesitate to contact me if you have questions/ideas!
>
> Is there anyone else you would suggest to get in touch with?
>
> Regards Sebastian
>
>
>

-- 
Carl K

Re: private key in the wild

[Carl Karsten]

On Fri, Dec 27, 2019 at 3:06 AM Giovanni Mascellani  wrote:

> Hi,
>
> Il 27/12/19 09:51, Carl Karsten ha scritto:
> > I like it because it is an easier file to edit.  sound good?
>
> I believe you still have to edit authorized_keys to put the "restrict"
> option, otherwise a number of other authorizations are retained (see the
> man page), and I believe you don't want.


restrict,command="/bin/false" ssh-rsa B3Nza...



> Also, using ForceCommand will
> apply to all users, while I believe you still want to access that box
> with another user for administration.
>
>
It is just for the one user:

Match User {user}MaxSessions 60PasswordAuthentication no
ChrootDirectory %hX11Forwarding noAllowTcpForwarding yes
PermitTunnel noPermitTTY noBanner noneForceCommand
/bin/false


   1. make the user's home dir owned by root: chown root: /home/user
   2. add to the front of ~/.ssh/authorized_keys: restrict,command="/bin/false"
   ssh-rsa B3Nza...

https://salsa.debian.org/debconf-video-team/ansible/blob/0815be8485ead04766e20bae975160d7b936acdf/roles/sidedoor/README.md#securing-the-server-restrict-what-that-account-can-do

I think scp / sftp is still available (it is built into Openssh) so I was
hoping to restrict it to an 'empty' dir

ChrootDirectory %h

without this:
root@cnt1:/etc/sidedoor# scp -P 14322 config  r...@sd1.sytes.net:
lost connection

enable  ChrootDirectory %h
root@cnt1:/etc/sidedoor# scp -P 14322 config  r...@sd1.sytes.net:
/bin/sh: No such file or directory
lost connection

I'm wondering what/where this is set: /bin/sh:
I am guessing the error is because /home/runr/bin/sh doesn't exist, but
this seems like a sloppy way to be secure.



> Giovanni.
> --
> Giovanni Mascellani 
> Postdoc researcher - Université Libre de Bruxelles
>
>

-- 
Carl K

local live stream

[Carl Karsten]

I need a monitor in another room playing the live stream over the LAN.

This was done at LCA 2019, but I can't find the config.  I know "it's easy"
but I'd like to see it in ansbile and if I have to build this from scratch
im open to suggestion, like what player?

I would also like a new option: instead of playing the mixed stream,
connect to one of the "source relays" or whatever it is called so it
monitors a source.  I've done this once, but on the fly, no chance of it
being saved.


-- 
Carl K

Re: Shipping "some equipment" to PyConZA (was: meeting etc.)

[Carl Karsten]

On Wed, Sep 11, 2019 at 2:03 PM Carl Karsten  wrote:

>
>
> On Wed, Sep 11, 2019 at 6:57 AM Nicolas Dandrimont 
> wrote:
>
>> Ohai,
>>
>> * Wouter Verhelst  [2019-09-11 12:56:40 +0200]:
>>
>> > Hi,
>> >
>> > (said this on IRC too, but for the benefit of those who don't follow
>> that...)
>> >
>> > On Tue, Sep 10, 2019 at 05:53:24PM +0200, Nicolas Dandrimont wrote:
>> > > Hey,
>> > >
>> > > We're running video for a Debian conference in Switzerland two
>> weekends after
>> > > PyConZA.
>> >
>> > Yeah, that's fairly close.
>> >
>> > > If the equipment needs overlap, I'm not too confident that shipping
>> > > our hardware halfway around the world will work out considering
>> postal and
>> > > customs delays as well as just plain volunteer delays, etc.
>> >
>> > PyConZA is considering to buy their own blackmagic cards. They are
>> > planning to rent computers and cameras, so that shouldn't be an issue.
>> >
>> > So if that happens, this would only require the opsises, or something to
>> > replace them.
>>
>> How many of them? I only have two of them in Paris, and to be confident I
>> kinda
>> need two in Vaumarcus.
>>
>> > > We also don't have a good story for doing temporary imports using
>> commercial
>> > > shipment companies. I don't think I'll be able to come up with one in
>> less
>> > > than a month (but someone should definitely feel free to try).
>> >
>> > Can you clarify what the issue here is?
>>
>> "Commercial off the shelf" (UPS/FedEx/...) shipping companies don't know
>> how to
>> handle temporary import of goods in a country. You'll have to pay VAT
>> (and the
>> hefty customs management fees) on the declared value of the goods on
>> entry in
>> the country of destination, and again when entering back the country of
>> origin
>> (and then, if you're bored, you get to argue with both tax offices that
>> the
>> goods have been reexported/reimported to get that reimbursed).
>>
>> The single quote that I obtained for so-called "Carnet shipment services"
>> (where the shipment company handles the temporary import procedure) to
>> ZA, back
>> in 2016, was...  prohibitive (multiple times what UPS had quoted, which
>> was
>> even more than just getting extra luggage).
>>
>
> A few years ago I've spent some time looking into this and gave up. I
> remember being appalled by such fees too, and realized these companies are
> optimized for large scale commercial transactions, not small almost
> personal use.
>
> I remember one company quoting $1000 + x% of estimated value just to
> prepare the paperwork for me to drive equipment in my car to Canada.
>


I did it myself: spend an hour or 2 to find the form, print, fill it out,
> hand it to a customs agent as I crossed the border.
>

Note: what I did myself was not carnet - it was form ABC-123 something that
only the US cares about so I won't have to pay to bring the equipment back
into the US,


>
> Similar experience with carnet service.  quick google shows $230 for
> $10,000 worth, but I'm pretty sure there more fees for what is needed to
> get stuff to PyConZA on time.
>
> quick google found these:
> https://www.uscib.org/register-and-apply-ud-859/
> https://www.atacarnet.com/fees
>

Just talked to one - $600 for carnet, which includes a bond that covers
taxes/tarifs etc for $1200 worth of stuff being used and returned.
Shipping will be it's own fee.




>
>
>
>
>>
>> Cheers,
>> --
>> Nicolas Dandrimont
>>
>> lp1 on fire
>> (One of the more obfuscated kernel messages)
>>
>
>
> --
> Carl K
>


-- 
Carl K

Re: Shipping "some equipment" to PyConZA (was: meeting etc.)

[Carl Karsten]

On Wed, Sep 11, 2019 at 6:57 AM Nicolas Dandrimont  wrote:

> Ohai,
>
> * Wouter Verhelst  [2019-09-11 12:56:40 +0200]:
>
> > Hi,
> >
> > (said this on IRC too, but for the benefit of those who don't follow
> that...)
> >
> > On Tue, Sep 10, 2019 at 05:53:24PM +0200, Nicolas Dandrimont wrote:
> > > Hey,
> > >
> > > We're running video for a Debian conference in Switzerland two
> weekends after
> > > PyConZA.
> >
> > Yeah, that's fairly close.
> >
> > > If the equipment needs overlap, I'm not too confident that shipping
> > > our hardware halfway around the world will work out considering postal
> and
> > > customs delays as well as just plain volunteer delays, etc.
> >
> > PyConZA is considering to buy their own blackmagic cards. They are
> > planning to rent computers and cameras, so that shouldn't be an issue.
> >
> > So if that happens, this would only require the opsises, or something to
> > replace them.
>
> How many of them? I only have two of them in Paris, and to be confident I
> kinda
> need two in Vaumarcus.
>
> > > We also don't have a good story for doing temporary imports using
> commercial
> > > shipment companies. I don't think I'll be able to come up with one in
> less
> > > than a month (but someone should definitely feel free to try).
> >
> > Can you clarify what the issue here is?
>
> "Commercial off the shelf" (UPS/FedEx/...) shipping companies don't know
> how to
> handle temporary import of goods in a country. You'll have to pay VAT (and
> the
> hefty customs management fees) on the declared value of the goods on entry
> in
> the country of destination, and again when entering back the country of
> origin
> (and then, if you're bored, you get to argue with both tax offices that the
> goods have been reexported/reimported to get that reimbursed).
>
> The single quote that I obtained for so-called "Carnet shipment services"
> (where the shipment company handles the temporary import procedure) to ZA,
> back
> in 2016, was...  prohibitive (multiple times what UPS had quoted, which was
> even more than just getting extra luggage).
>

A few years ago I've spent some time looking into this and gave up. I
remember being appalled by such fees too, and realized these companies are
optimized for large scale commercial transactions, not small almost
personal use.

I remember one company quoting $1000 + x% of estimated value just to
prepare the paperwork for me to drive equipment in my car to Canada.  I did
it myself: spend an hour or 2 to find the form, print, fill it out, hand it
to a customs agent as I crossed the border.

Similar experience with carnet service.  quick google shows $230 for
$10,000 worth, but I'm pretty sure there more fees for what is needed to
get stuff to PyConZA on time.

quick google found these:
https://www.uscib.org/register-and-apply-ud-859/
https://www.atacarnet.com/fees




>
> Cheers,
> --
> Nicolas Dandrimont
>
> lp1 on fire
> (One of the more obfuscated kernel messages)
>


-- 
Carl K

Re: DebConf19 Video Equipment Hire List

[Carl Karsten]

On Fri, Jun 7, 2019 at 7:58 AM Paulo Henrique de Lima Santana
 wrote:
>
> Hi all,
>
> We are getting some difficult to get rent price for equipaments from
> local companies.

if you need help finding more companies, talk to venue management,
they will likely know the local companies other events have used.

> I have one, even so, without details about brands, models, etc. I am
> waiting more 2.
>
> Omni-Directional Microphone
> Microphone clip (attach to mic stand) for item #1
mic and clip normally come as a set, list it as one item:

Omni-Directional Microphone and clip.

> Heavy duty Camera Tripod – Pan / Tilt head

"Heavy duty" is not really accurate, and may result in spending more
money than needed.

Tripod and head appropriate for a 2kg video camera

> RF Headset microphone / Receiver Pair
> RF Hand-held microphone / Receiver Pair
> Stereo DI box (2x 1/4” TRS socket to 2xXLR male)
> Sound Mixer

specify number of channels (inputs)
8 channel audio mixer

> Microphone stand
>
> Cables are ok.
>
> I suggest you take all equipaments you have to Curitiba, as the
> microphones, DI box.
>
> Best regards,
>
> --
> Paulo Henrique de Lima Santana (phls)
> Curitiba - Brasil
> Debian Developer
> Diretor do Instituto para Conservação de Tecnologias Livres
> Membro da Comunidade Curitiba Livre
> Site: http://www.phls.com.br
> GNU/Linux user: 228719  GPG ID: 0443C450
>
> Organizador da DebConf19 - Conferência Mundial de Desenvolvedores(as) Debian
> Curitiba - 21 a 28 de julho de 2019
> http://debconf19.debconf.org
>


-- 
Carl K

ansible MR review today plz?

[Carl Karsten]

Can someone review my MR in the next 6-8hours?

I've done a few passes of testing, which are kludged because it relies
on files being in master which aren't there yet, like:
http://video-setup.debian.net/d-i/preseed_local_debian.cfg
redirects to 
https://salsa.debian.org/debconf-video-team/ansible/raw/master/roles/tftp-server/files/d-i/preseed_local_debian.cfg

So I have to hack things and hand hold a new person to walk them
around the hacks which is some testing but far from ideal.

I have someone that will give it a run tonight.

They live in the same city as the next event I'll be doing:
http://pyohio.org July 27-28  so it would be super helpful if they
knew more about all the things.

pollo is the obvious person, but not soon:
CarlFK: pollo: have some time to look at this and help me resolve the
'local file' issue?
pollo: not before the marseille mini-dc may 21-28th
pollo: I have $work stuff I really want to finish before leaving :(



-- 
Carl K

Re: tallylights

[Carl Karsten]

Here is what was used at LCA, it supports tomu and I think something else:

https://github.com/CarlFK/voctomix-outcasts/blob/master/voctolight.py

On Mon, Feb 4, 2019 at 7:45 AM derpeter  wrote:

> Oh and another reason to work together, the code is already part of
> debian ;-)
>
> https://salsa.debian.org/debian/voctomix/tree/debian/example-scripts/voctolight
>
> we also have systemd units
>
> https://github.com/voc/cm/tree/master/ansible/roles/tally/templates/systemd-units
>
> Maybe the next step would be either make this a separate debian package?
> Or change the voctomix package in a way that it installs this service ?
>
> derpeter
>
> On 04.02.19 13:13, derpeter wrote:
> > Hey debian video team,
> >
> > i was pointed to your blog post about building a new tally light.
> >
> > We have already build much of what you describe in blog.
> >
> > See https://c3voc.de/wiki/projects:tallycom
> >
> > https://c3voc.de/wiki/projects:tallycom:bestand
> >
> > The script already interacts with the voctocore :-)
> >
> > I also have already a version with a small OLDED screen on my desk an
> > proof of concept mumble setup running on the pi.
> >
> > For sending messages to the display i plan to use mumble. I also have
> > already hacked some basic support for the display in go to merge it
> > into the mumble client (which is also go).
> >
> > We also have already tested some headsets to use for the intercom part.
> >
> > As our goals seem to be very similar, lets have a mumble soonisch and
> > join forces!
> >
> >
> > mfg derpeter
> >
>
>

Re: Idea for Debconf talks: using mobiles for Q?

[Carl Karsten]

On Thu, Jan 31, 2019 at 4:33 PM Andy Simpkins 
wrote:

> On 31/01/19 19:13, Adam Dane wrote:
> > Mr. Simpkins,
> >
> > I'm a Debian user and occasional watcher of conference videos. One thing
> > I've noticed is that during Q at the end of a talk, there's often a
> > problem with microphones. Either there aren't any (and we hope the
> > presenter repeats the question), or there are runners to bring them to
> > people which delays the Q, or there are standing microphones that
> > people queue up for.
> >
> > But it's 2019, and most people have a radio-transmitting microphone
> > right in their pocket: a mobile! If there would be a way to let audience
> > members use their phones to ask questions, it could make the operation
> > much simpler and smoother.
> >
> > Anyway, that's the idea. It would take a bit of work to do, but it seems
> > plausible. The basic design in my head follows, but I don't really know
> > if it's the best way.
> >
> > 1. User has an app installed that connects to a channel for the talk,
> > and they can queue to ask questions at the end.
> > 2. At the end, the app assigns a color to each queued person. They hold
> > their mobiles up so the speaker can see them, and the speaker can call
> > on them by color.
> > 3. When called on, the app turns the mic on and transmits the audio to
> > the audio system, so it can be played over the PA and recorded on the
> > video.
> >
> > I'm not sure how you prevent audio feedback, but I assume that there's a
> > way to do that, since regular wireless microphones don't have feedback
> > if configured correctly.
> >
> > Thanks for your work on Debian, and for your work on Debconf,
> >
> > Adam Dane
> >
>
> Hi Adam,
>
> I have copied this to the video team mailing list for other people to
> potentially respond as well.
>
> First of all thanks for the email.  It is always good to know that there
> are people watching the videos.
>
> You may or may not be aware that there is an IRC channel for each talk
> room available for Live Q, however that is text only.  This works for
> people outside the venue as well as inside, and typically questions are
> verbally asked by whoever is operating video equipment at the back of
> the room...
>
> As you have already noticed people have a tenancy to just shout out a
> question - I am afraid I very much doubt that having an app on a phone
> will cause them to wait for their turn either :-)
>
> On several occasions we have tried to get people to queue up in front of
> a microphone in order to ask a question - this ensures that there is
> both a microphone correctly set up, in position and a camera to record
> the question.  Unfortunately we found that this puts a lot of people off
> from asking their question in the first place.
>
> That said your idea of using a phone's mic could speed up the time
> waiting for a mic 'runner'...
>
> I am not sure that the holding up of phones with colours would help much
> - are you suggestion that the colour would make it easier to identify
> the location of the person asking the question?  In any case I would be
> willing to trial the idea and see if it works.
>
> I do foresee some problems with your proposal (listed below) but instead
> of simply dismissing your suggestion out of hand would you be willing to
> put together a demonstration?  There would be no need to put together a
> finished product - just a proof of concept that reliably works on a
> small WiFi network containing just your phone, a WiFi access point, and
> a PC with wired connection to the AP to act as the server (and any user
> interface you might need to 'drive the demo).
>
>
> Best Regards
> /Andy
>
>
> #1 A mobile phone app - typically this would mean Android or iPhone.  We
> like to eat our own dog food so would be looking for this to run on a
> Debian system.  Perhaps a website using web RTC could be a good solution
> we wouldn't even need to write an app specific for different phones.
> The user could simply point their phone's web browser at the desired
> website (and authorise the use of their microphone).
>
> #2 WebRTC is probably good enough inside the talk room itself (although
> in a busy presentation we may struggle for WiFi bandwidth).  Outside of
> the talk room we may struggle with latency - when watching a 'live'
> stream there is often as much as 40s delay between real time and the
> output buffer from a *local* video stream server.  This is delay is
> typically caused by buffering at the video mixer, the end client machine
> as well as a small delay during transcoding.
>
> For this reason alone it may be best to limit participation to within
> the talk room.
>
> #3 Finally integration.  We would need some mechanism to integrate into
> our existing work flow.  This may be quite a complex task in itself.
> but let us ignore how to resolve this issue pending on a successful
> proof of concept demo...
>
>

I like the concept, but it needs work.

Most have phones, but not everyone.  to be blunt 

Re: Preparing UTFPR for the video team

[Carl Karsten]

On Fri, Aug 17, 2018 at 12:51 PM Louis-Philippe Véronneau
 wrote:
>
> >>> * minipc
> >>> Specs?
> >>> i3 2gig of ram is acceptable. 10gig of disk per hour of recording.
> >>> pci-e slot for the capture card.
> >>
> >> In our recent tests, a 2015 i5 was not sufficient to run voctomix
> >> properly. I would highly recommend you get a machine with a recent i7 CPU.
> >
> > What tests?
> >
> > I just used a 2009 i3 to record 2 days of PyOhio.
> >
> > I have it running now with 2 gst videotestsrc/audiotestsrc which are
> > more cpu bound than reading from the BM or network card.
> >
> > core, gui, 2 sources, 2 file sync.
> > htop shows all 4 cores around 60%
>
> We used a 2015 i5 at DebConf18 and we had a lot of trouble.
> We had to
> reduce the preview quality a lot since we were loosing frame and were
> experiencing audio desync because of a high CPU usage.
>

2015 - there have been some significant performance improvements in
Voctomix.  I think this invalidates your tests.

> I think the main difference between our setups is we have a 2nd camera
> and thus 3 sources.

voctocore - 60%
voctogui - 10 processes at 5% = 50%
ffmpeg file sink 30%
each source = 20%

3 sources - no cores maxed:

juser@cnt1:~$ sudo mpstat 5 1
Linux 4.9.0-7-amd64 (cnt1) 08/17/2018 _x86_64_(4 CPU)
01:40:05 PM  CPU%usr   %nice%sys %iowait%irq   %soft
%steal  %guest  %gnice   %idle
01:40:10 PM  all   53.140.00   13.780.160.000.69
0.000.000.00   32.23
juser@cnt1:~$ uptime
 13:56:19 up 16 days, 55 min, 11 users,  load average: 5.04, 7.09, 8.67

load swings between 4 and 8 about every minute.  seems odd.

4 sources seems doable on this box - 10% idle.
5 sources ... seems to be working, but no:

Average: CPU%usr   %nice%sys %iowait%irq   %soft
%steal  %guest  %gnice   %idle
Average: all   76.480.00   21.560.050.000.95
0.000.000.000.95
Average:   0   80.560.00   18.440.000.000.60
0.000.000.000.40
Average:   1   74.100.00   23.490.000.001.20
0.000.000.001.20
Average:   2   72.800.00   24.800.200.001.40
0.000.000.000.80
Average:   3   78.310.00   19.480.000.001.00
0.000.000.001.20
juser@cnt1:~$ uptime
 14:45:02 up 16 days,  1:44, 11 users,  load average: 31.60, 25.00, 16.68


>
> From our tests the linux kernel patches for Specter (KPTI) also has a
> large impact.

I was thinking video stuff might be impacted.  current kernels are patch, right?

juser@cnt1:~$ uname -a
Linux cnt1 4.9.0-7-amd64 #1 SMP Debian 4.9.110-1 (2018-07-05) x86_64 GNU/Linux



>
> >>> * Cameras (borrowed from the university
> >>> What model?
> >>> they should have balanced audio in, and SDI or HDMI output.
> >>
> >> SDI is preferable to HDMI, since you'll have to use HDMI extenders if
> >> you go with HDMI.
> >
> > I use HDMI, and I don't use extenders.
>
> But you don't have an audience camera that is 50+ meters away from the
> mixing PC :P

Ah right.

If no one has done video before, I would start small.  1 camera, 1
Opsis, no streaming, no tally lights, no bgloop,   basically what I
did for PyOhio.  this will be about as educational as trying to run
the full stack of features.

My crystal ball predicts:
If someone can get possession of all the equipment 2 weeks before and
spend 4-8 hours setting it up with help from IRC, 80% chance of
success at the event.

If all that has to be done a day or two before, it drops to 40%.

If they try and do everything DC does...  20%.

I would much rather the crew have done an event successfully than
failed.  There are pros n cons to both, but understanding how much
work it is to achieve results is more valuable than collecting
problems that need to be fixed next time.  Because there are never
enough next times.







>
> --
>   ,''`.
>  : :'  : Louis-Philippe Véronneau
>  `. `'`  po...@debian.org / veronneau.org
>`
>


--
Carl K

Re: Preparing UTFPR for the video team

[Carl Karsten]

On Thu, Aug 16, 2018 at 7:27 PM Louis-Philippe Véronneau
 wrote:
>
> On 2018-08-16 19:30, Carl Karsten wrote:
> > * Opsis
> > This will need a small computer, really anything with usb2 and gig
> > eathernet that can run linux.
>
> The opsis board we gave them has a Minnowboard Turbot inside its case.
>
> > * minipc
> > Specs?
> > i3 2gig of ram is acceptable. 10gig of disk per hour of recording.
> > pci-e slot for the capture card.
>
> In our recent tests, a 2015 i5 was not sufficient to run voctomix
> properly. I would highly recommend you get a machine with a recent i7 CPU.

What tests?

I just used a 2009 i3 to record 2 days of PyOhio.

I have it running now with 2 gst videotestsrc/audiotestsrc which are
more cpu bound than reading from the BM or network card.

core, gui, 2 sources, 2 file sync.
htop shows all 4 cores around 60%

/proc/cpuinfo
model name: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz
load average: 6.44, 6.33, 5.84
juser@cnt2:~$ free -h
  totalusedfree  shared  buff/cache   available
Mem:   1.8G888M151M254M798M487M

juser@cnt1:~$ ps auxw --sort -pcpu
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
juser22156 78.9  5.4 2278132 100580 ?  Rl   00:39  27:03
/usr/bin/python3 /usr/bin/voctogui
juser22047 58.4  6.4 2713532 120364 ?  Ssl  00:38  20:21
/usr/bin/python3 /usr/bin/voctocore -v
juser22111 27.9  4.1 669180 76600 ?Sl   00:38   9:44
ffmpeg -nostdin -i tcp://localhost:11000 -ac 2 -channel_layout 2c -
juser22128 18.2  1.6 529620 31624 pts/2Sl+  00:38   6:21
/usr/bin/python3 /usr/bin/voctomix-ingest
juser22142 17.4  1.7 529628 31672 pts/3Sl+  00:38   6:03
/usr/bin/python3 /usr/bin/voctomix-ingest --port 10001
root   590  0.8  3.3 319148 61888 tty7 Ssl+ Aug01 188:39
/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -n
juser  961  0.5  0.9 838392 17692 ?Ssl  Aug01 116:35 /usr/bin/conky





> > * Splitter HDMI
> > not needed.
> >
> > * Cameras (borrowed from the university
> > What model?
> > they should have balanced audio in, and SDI or HDMI output.
>
> SDI is preferable to HDMI, since you'll have to use HDMI extenders if
> you go with HDMI.

I use HDMI, and I don't use extenders.

>
> The camera should be able to do 720p.
>
> > You should have the talk schedule figured out a week or so in advance,
> > and put together the title and footer svg files.   you can do this
> > after the event, but it is much less likely it will get done.
> >
> >
> >
> > On Thu, Aug 16, 2018 at 5:42 PM Rodrigo Siqueira
> >  wrote:
> >>
> >> We don't have the capture board yet; we will try to borrow or buy it. Do
> >> we need more equipment than that? Does someone have any advice on this
> >> first attempt?
>
> If you buy capture cards, please try to get the same cards we have. Ours
> are Blackmagic Decklink Mini Recorder and cost around 150USD/card.
>
> It might also be a good idea to think about getting tally lights [1]. We
> bought serial PCI-e cards for our mixing computers and pair those with
> serial to ethernet adapters and a serial led at the end.
>
> In theory, the 'Hardware' section of our documentation [2] lists
> everything you need.
>
> [1]
> https://debconf-video-team.pages.debian.net/docs/hardware.html#tally-lights
> [2] https://debconf-video-team.pages.debian.net/docs/hardware.html
>
> --
>   ,''`.
>  : :'  : Louis-Philippe Véronneau
>  `. `'`  po...@debian.org / veronneau.org
>`-
>


--
Carl K

Re: Preparing UTFPR for the video team

[Carl Karsten]

* Opsis
This will need a small computer, really anything with usb2 and gig
eathernet that can run linux.

* minipc
Specs?
i3 2gig of ram is acceptable. 10gig of disk per hour of recording.
pci-e slot for the capture card.

* Splitter HDMI
not needed.

* Cameras (borrowed from the university
What model?
they should have balanced audio in, and SDI or HDMI output.

You should have the talk schedule figured out a week or so in advance,
and put together the title and footer svg files.   you can do this
after the event, but it is much less likely it will get done.



On Thu, Aug 16, 2018 at 5:42 PM Rodrigo Siqueira
 wrote:
>
> Hi,
>
> My name is Rodrigo Siqueira and I'm part of the local video team for
> debconf19.
>
> We already want to organize our local video team; as a result, we have a
> plain to make a first attempt to setup the video configuration at UTFPR
> for an event named FTSL (Free Software Technology Forum). In this sense,
> we have the following hardware with us:
>
> * Opsis
> * minipc
> * Splitter HDMI
> * Cameras (borrowed from the university)
>
> We don't have the capture board yet; we will try to borrow or buy it. Do
> we need more equipment than that? Does someone have any advice on this
> first attempt?
>
> Finally, we want to use the opportunity to produce a small report for
> the video team about the equipment/structure in the UTFPR. In this
> sense, could anyone list all the information that we should get?
>
> Thanks
> Best Regards
>
> --
> Rodrigo Siqueira
> http://siqueira.tech
> Graduate Student
> Department of Computer Science
> University of São Paulo
>


-- 
Carl K

Re: Audio Hardware Purchase Proposal

[Carl Karsten]

I would suggest putting the Opsis and such in a half rack case - like this
one:

http://gatorcases.com/products/racks-portable/half-rack-cases/g-tour-rack-half-rack-cases/6u-half-rack-with-8-depth-g-tour-6uhr/
$220 usd

6u =
Opsis,
turbot,
2 mic receivers,
2u draw fro mics and short cables

http://gatorcases.com/products/rack-accessories/half-rack-accessories/rackworks-half-rack-accessories/half-rack-standard-width-2u-drawer-grw-halfrkdrw2/

I have a full sized 4u case that I used once or twice, and I found it
annoyingly large given I didn't really need that much space.

ps - my understanding of "front of house" is the spot in the audience area
where the mixers are.  we can debate what meaning of house and its
origination, or just try to figure out how to communicate with venue staff.





On Sun, Feb 4, 2018 at 4:32 PM, Kyle Robbertze  wrote:

> The video team has been discussing the purchase of audio hardware for
> some time. During the Paris sprint in 2016 [1], we drew up a list of
> hardware that we would like to own [2]. Included in this list was audio
> gear that we currently hire, but would like to own. During DC17, Andy
> and I broke this list down into three flight-cases and started
> estimating prices for the equipment we need. We finished this during the
> Cambridge sprint in 2017 [3] and Andy mocked up images of the
> front-of-house rack. This rack is the box that will sit at the front of
> the talk room next to the speaker, which will contain the Opsis/Turbot
> chassis and microphone receivers.
>
> [1] https://wiki.debconf.org/wiki/DebConf17/Videoteam/Sprint1
> [2]
> https://wiki.debian.org/Teams/DebConf/Video/VideoTeamDocs/
> NewVideoTeamHardware[3]
> https://wiki.debian.org/Sprints/2017/DebConfVideoteamSprint20Nov2017
>
> There is a lot of hardware on the list, and I think it best that we buy
> it in stages, one rack at a time. The easiest to begin with would be the
> Opsis/Turbot chassis, as we already have much of what is needed. It also
> contains the Opsis HDMI capture board and the single board PC to run it.
> Having both items in a single chassis will allow us to treat it as one
> unit and place it in the front-of-house rack when that is built. The
> list can be found on the wiki [2] with explanations around each piece
> listed. I will list only this set equipment with associated costs here.
>
> * 1x 1U chassis ($0)
> * 1x Opsis ($0)
> * 1x Turbot ($149)
> * 1x Small PC PSU ($35)
> * 1x Milkymist IO Expansion board for Opsis ($65) - This is currently
> non-functional on the Opsis, but work is planned for using it as audio
> I/O once the Opsis can support audio output over USB
> * 1x DI Box Stereo, unbalanced -> balanced, TRS -> XLR ($20)
> * 1x Small SSD (120GB) ($60)
> * 1x 50cm HDMI cable ($8)
> * 1x Bulkhead RJ45 coupler ($10)
> * 1x RJ45 patch cable ($3)
> TOTAL: $350
>
> The USB sockets on the chassis are connected to the Turbot board so that
> it can be managed directly if needed. The Turbot uses the SSD to store
> its OS and the sponsor loops, etc. The Turbot's HDMI output is connected
> to the Opsis input 2.
>
> This chassis can be placed at the front of the room and used as an
> appliance. It is connected to the network, and it can be provisioned
> using Ansible and PXE, similarly our current setup. It will be easy to
> integrate into the front-of-house rack when we purchase that because it
> is a standard 1U form-factor.
>
> Another useful box that could be bought at the same time is the sound
> mixer ($690). This contains the following:
>
> * 1x Mixing desk, suggest Behringer X2442USB ($460)
> * 1x Flight case ($190)
> * 1x Gooseneck Lamp 12V BNC - LED ($30)
> TOTAL: $680
>
> These prices are based on web searches and are not necessarily the
> cheapest out there. We will need to adjust them once we find a supplier
> who can quote us properly.
>
> The final rack is the front-of-house rack, which is tricky because the
> wireless microphone receivers need to be compatible with many different
> regions and legal requirements. The Shure AD4Q Four-Channel wireless
> receiver appears to be compatible with all ITU regions, subject to
> confirmation. The rack includes the following equipment:
>
> * 1x Shure AD4Q Four-Channel Digital Wireless Receiver ($6000)
> * 2x Shure AD1 Bodypack Transmitter with TA4 connector ($1600)
> * 2x Shure WH20 Headset Mic TA4 connector ($260)
> * 2x AD2/B58 Handheld Wireless Microphone ($1878)
> * 2x 1U draw with foam insert (store mics) ($140)
> * 1x 4U flight case ($220)
> * 1x 4U Tray ($130)
> * 1x Opsis / Turbot PC / SSD & PSU in 1U Box (see above list)
> * 1x Euro 4 way mains block ($15)
> * 2x Bulkhead RJ45 coupler ($20)
> * 6x Panel mount XLR Male socket ($12)
> * 3x Bulkhead HDMI ($54)
> * 4x Bulkhead BNC  coupler ($16)
> * 1x Switched IEC Filtered Power Inlet Socket ($10)
> * 1x Gigabit switch (5 port unmanaged) ($35)
> * 3x 50cm HDMI cable ($32)
> * 4x 50cm BNC 50R coax cable ($60)
> * 5x RJ45 patch cable ($12)
> * 3x 1m