[Dprglist] odometery test movie

[David Anderson]

Karim,

Thanks for this in-depth reply.    I think what it has convinced me is 
that I'm going to make a little stand to hold the laptop camera in 
alignment pointed at the desktop screen, and just play videos on the 
desk top.   The downside is that, unlike the "presenter" function, it 
doesn't really control the session.  So when others speak, the video 
goes away.  I guess that can be fixed by asking everyone to "pin" my 
screen during the video, yes?

Karim, your knowledge sometimes astounds me.

cheers,

David


On 7/13/20 1:21 PM, Karim Virani wrote:
> Hey David, regarding your questions about sharing video...
>
> Bottom line - we could switch to Google Meet (from Hangout Meets which 
> I think we are still using) and anyone who wants to share a video 
> should post it on a video streaming service like youtube ahead of 
> time. You can post it as "unlisted" if you don't want it showing up in 
> search engines. This will let us use the Share Chrome Tab feature 
> <https://gsuiteupdates.googleblog.com/2020/04/high-quality-video-audio-meet.html> 
> with its support for high quality video streaming. It's important to 
> *not* use the full screen or application share options here.
>
> If you want the details, read on:
>
> We are asking a lot of our systems when we share video while 
> presenting our desktops. At the very least your system is decoding 
> that video to raw (possibly up scaled) pixels. So you've lost the 
> inter-frame optimizations. If the source is remote you are also 
> consuming downstream bandwidth. Now if you are sharing your desktop, 
> screen updates are being broken down with VNC-like (I'm not sure what 
> remote rendering engine Meets uses) frames. The system tries to 
> optimize things down to simple graphics primitives for a lot of the 
> screen drawing like text and vectors, but bitmaps have to be 
> re-encoded. Your decoded video is now a series of high res bitmaps 
> updated at your native screen refresh rate. Even if your video source 
> is skipping frames, your screen buffer doesn't know that. So now you 
> have an uncompressed high hz sequence of high res bitmaps that have to 
> be re-encoded and the VNC subsystem is usually able to detect and 
> treat this at least as a motion jpeg stream which gives up the 
> interframe differencing optimizations. Now you have a higher 
> bandwidth, lower quality and less optimized video embedded within the 
> screen frames you are uploading to the broadcaster.
>
> If you have a fast processor and high bandwidth upstream internet 
> service you might get away with this. But at best it's still going to 
> be lower quality with extra layers of compression artifacts than your 
> original video. Likely it will stutter badly if there are any 
> bottlenecks in the path.
>
> When you point your webcam at a screen you are already at lower pixel 
> count because the video resolution of most webcams is capped well 
> below screen resolutions. It's also using interframe optimizations and 
> some webcams do this internally and not on the host processor. It's 
> definitely not having to do a decode first and it's not consuming 
> downstream bandwidth.
>
> It's hard to discover the details of how they did it, so I'm 
> speculating here. But Google Meet is claiming it supports high quality 
> video and audio sharing. Since you have to use the Chrome browser for 
> this feature, they might just be using the Casting function built into 
> the browser - which I think is smart enough to echo back the source 
> video stream without recoding it. It's also possible that it is 
> detecting the source video stream and just telling the broadcaster to 
> share the cloud source with all of the meeting participants - skipping 
> the need to upstream from your local computer. So you are only 
> providing start/stop/seekcommands. That at least is how video 
> streaming works for the larger (thousands of participants) conference 
> sharing services.
>
> Anyhow, I'd be happy to test it out with you and see if we get an 
> improvement. We could try this in a one-to-one anytime convenient to 
> you. Google Meet is free to everyone now. But you have to basically 
> "cave in to the man" and adopt the whole google pipeline 
> (Meet/Chrome/Youtube). Though it's possible it will work with the 
> mpegs you post on the SMU server.
>
> Sorry if I went into too much detail. In a previous life I built some 
> of the first mpeg streaming servers - the early 90s.
>
> On Sun, Jul 12, 2020 at 11:58 PM David Anderson via DPRGlist 
> <dprglist at lists.dprg.org <mailto:dprglist at lists.dprg.org>> wrote:
>
>     Hello DPRG,
>
>     Here's the video I mentioned in the meeting Saturday but forgot to
>     post
>     the link:
>
>     http://www.geology.smu.edu/dpa-www/robo/mpeg/rcat-202005-9-2.mpg
>
>     Still haven't figured out how to show video in google meetup. Lou
>     mentioned that also.  Maybe it's not possible.  It did seem to
>     work at
>     last months meeting when I just pointed the laptop camera at the
>     desktop
>     screen, and played the video on the desktop.  But the "presenter"
>     function doesn't seem to be able to keep up.
>
>     Likely I just don't know what I'm doing.
>
>     onward into the fog,
>
>     David
>
>
>     _______________________________________________
>     DPRGlist mailing list
>     DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>     http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200714/2dd7c3c9/attachment.html>