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:sean.re...@gmail.com] Sent: 27 March 2020 20:23 To: user@guacamole.apache.org 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 <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> wrote: Thank you Sean. I look forward to the update! Adrian From: Sean Reid [mailto:sean.re...@gmail.com<mailto:sean.re...@gmail.com>] Sent: 26 March 2020 20:36 To: user@guacamole.apache.org<mailto:user@guacamole.apache.org> 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 <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> 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:sean.re...@gmail.com<mailto:sean.re...@gmail.com>] Sent: 26 March 2020 01:32 To: user@guacamole.apache.org<mailto:user@guacamole.apache.org> 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 <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> 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:sean.re...@gmail.com<mailto:sean.re...@gmail.com>] Sent: 26 March 2020 00:18 To: user@guacamole.apache.org<mailto:user@guacamole.apache.org> 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 <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> 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:mjum...@apache.org<mailto:mjum...@apache.org>] Sent: 25 March 2020 22:26 To: user@guacamole.apache.org<mailto:user@guacamole.apache.org> 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 <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> wrote: Mike, Is there a less convoluted way to grab the text displayed? From: Mike Jumper [mailto:mjum...@apache.org<mailto:mjum...@apache.org>] Sent: 25 March 2020 20:42 To: user@guacamole.apache.org<mailto:user@guacamole.apache.org> Subject: Re: guacenc new parameters On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <adrian.o...@eesm.com<mailto:adrian.o...@eesm.com>> 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
