That makes sense that the edges would have less noise if they’re generated directly from the guacamole protocol stream than if they had already gone through a lossy video encoding process. I’m glad you got something that works for you!
On Fri, Mar 27, 2020 at 4:40 PM Adrian Owen <[email protected]> wrote: > Hi Sean, > > > > Thank you so much. I will have time tomorrow to pull down and build. > > > > Moreover my pal has managed to get PNG Snapshots direct from stream. > > 1) Their very clean. The ones from M4V have noise around the edges. > > 2) Running with our –R option (no M4V) guacaenc completes 3 x faster > > > > You have been so kind. I’ll let you know how I get on with H.264 branch. > > > > Many thanks, Adrian > > > > *From:* Sean Reid [mailto:[email protected]] > *Sent:* 27 March 2020 20:23 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > Hi Adrian, > > > > I updated my H.264 branch and rebased it with guacamole-server's master > branch. You'll obviously need to pull this branch and build from source. > > > > It makes a few changes to guacenc to support H.264 in an MP4 container. > > > > First off, you'll only be able to encode one file at a time with H.264, > rather than in a batch. If you've been using guacenc for batches of files, > you might need to write a small script to do those batches instead. > > > > Second, the command line syntax is a little different. You'll want to use > a command that looks like: > > guacenc -i /path/to/recordingfile.guac -o /path/to/destination.mp4 -c > libx264 > > > > The -i is to specify the input file path, the -o is to specify the output > file path (and extension), and -c is to specify the codec you'd like to > use. For this branch, only mpeg4 (which was the codec used for m4v) and > libx264 (which is ffmpeg's H.264 codec) are supported for the -c argument. > > > > Third, I did some quick benchmarks to encode the example recording file > from guacamole-client (recording.guac). I compared the default MPEG4 in M4V > file against the new H.264 in MP4. It took 8.034 seconds to encode to > MPEG4/M4V and 10.029 seconds to encode H.264/MP4 on my machine. This is > about a 24% increase in encoding time. While in your use case, you won't > have to do the initial encode to M4V, which will probably save you time > overall, it might be important to note the increased difficulty in encoding > H.264. > > > > Finally, I hope it goes without saying that none of this code has been > reviewed yet. I'm going to be contributing it to the project at some point, > but as of now, I'm the only one who's ever used it or looked at it, and > there could possibly be issues that haven't been fixed. It's worked well > for me and my uses for the last while and I'm hoping it does for you too. > > > > The branch is located at here: > https://github.com/sreid8/guacamole-server/tree/guacenc_h264 > > > > Good luck, > > Sean > > > > On Thu, Mar 26, 2020 at 5:00 PM Adrian Owen <[email protected]> wrote: > > Thank you Sean. > > > > I look forward to the update! > > > > Adrian > > > > *From:* Sean Reid [mailto:[email protected]] > *Sent:* 26 March 2020 20:36 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > I've been working on a series of patches to support h.264 in MP4 for > guacenc. I have an old branch that has all of it working, but it needs to > be resurrected and rebased against the latest master of guacamole-server. > I'll work on getting that done this weekend and let you know where you can > find it then. > > > > Sean > > > > On Thu, Mar 26, 2020 at 4:17 PM Adrian Owen <[email protected]> wrote: > > > > I run guacenc to get MV4 and then ffmpeg to get H264 MP4 video > > > > Is there way to go straight to MP4? It would take less processing. > > > > Thanks, > > *From:* Sean Reid [mailto:[email protected]] > *Sent:* 26 March 2020 01:32 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > To satisfy my curiosity, do you have an example (even 10 or so minutes > will do) recording that's representative of the data you're encoding that > you could share, along with the command you're using to encode it with > guacenc? I'd be interested in trying to see how long it takes to encode > with a few different codecs that I've been experimenting with for support > in guacenc. > > > > On Wed, Mar 25, 2020 at 8:36 PM Adrian Owen <[email protected]> wrote: > > Hi Sean, > > > > It’s 2 problems in 1. > > > > Snapshots are needed for input for OCR and I also need make guacenc run a > lots faster on High res data rich RDP sessions. > > I hoped if I could solve the snapshots only option, then it would also > complete sooner. > > > > The overall Issue is how many concurrent users can it support with data > gathered in a timely manner. > > > > *From:* Sean Reid [mailto:[email protected]] > *Sent:* 26 March 2020 00:18 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > I don't think we can provide a definitive answer as to whether mpeg4 > (which is the codec guacenc uses for m4v), jpeg, png, or any other codec > will be faster always. Often, the ability for a codec to encode quickly > relative to another depends on the content of the frames it is encoding. In > addition, individual snapshots add a different type of concern that a video > doesn't have: extra IO operations. A video is one big binary file, tons of > images is tons of small binary files. Each image file creation is an extra > create, write, flush, and close IO operation that video won't have. Whether > these extra operations add up to a meaningful amount of overhead is another > question entirely. > > > > To answer both your questions: > > 1. Guacenc *could* write snapshots every second of a recording instead of > encoding video, but it doesn't right now and I don't know that anyone has > talked about providing code to do that. > > 2. It's not possible to know if encoding individual images every second > would be faster than encoding mpeg4 for the reasons I outlined above. > > > > This conversation brings up some other questions for me though. What > problem are you trying to solve? Is it the speed of video encoding? Is it > that you need screenshots rather than a video for OCR? Maybe understanding > the whole problem will help us help you. > > > > On Wed, Mar 25, 2020 at 7:29 PM Adrian Owen <[email protected]> wrote: > > Thanks, It’s what I suspected. And I use the typescript, for SSH/TELNET > already. > > > > So going back to my question. Would guacaenc support writing snapshots > every second? And moreover, if it did that instead of writing M4V would be > a lot faster? > > > > An intense high res 1 Hour RDP, can take guacenc 15-30 minutes to complete? > > *From:* Mike Jumper [mailto:[email protected]] > *Sent:* 25 March 2020 22:26 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > For purely-graphical connections like VNC and RDP, no, OCR would really be > the only option. Once the data leaves the VNC/RDP server, it's just a > fragment of an image and has lost all text meaning. If you enable recording > of keyboard events, you would be able to infer what is being typed, but the > only way to read the graphical content of the screen would be OCR. > > > > For connections driven by text like SSH, telnet, and Kubernetes, you can > leverage Guacamole's support for typescripts. Each typescript is the raw > text data received from the server prior to being rendered, including > console codes, coupled with a separate file containing timing information. > > > > - Mike > > > > On Wed, Mar 25, 2020 at 1:52 PM Adrian Owen <[email protected]> wrote: > > Mike, > > > > Is there a less convoluted way to grab the text displayed? > > > > *From:* Mike Jumper [mailto:[email protected]] > *Sent:* 25 March 2020 20:42 > *To:* [email protected] > *Subject:* Re: guacenc new parameters > > > > On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <[email protected]> wrote: > > I had an idea for another parameter to guacenc. > > > > gaucenc generates an M4V file. > > > > Could it optionally, generate PNG Snapshot images instead. Every second. > 1.file.png, 2.file.png …. > > > > Why? > > > > - Mike > > > >
