You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@guacamole.apache.org by Adrian Owen <ad...@eesm.com> on 2020/03/15 17:55:16 UTC
guacenc new parameters
Hi,
ffmpeg allows getting a section of a video file by specifying start seconds and end seconds,
Now the Guacamole video steam may not know seconds but:
Could Guacenc support extra parameters: StartPoint Endpoint?
And then only generate MV4 between those points.
This is a theoretical question,
Many thanks, Adrian
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
Input images to OCR system.
From: Mike Jumper [mailto:mjumper@apache.org]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
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 <ad...@eesm.com> 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:sean.reid8@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 <ad...@eesm.com> wrote:
>
> Thank you Sean.
>
>
>
> I look forward to the update!
>
>
>
> Adrian
>
>
>
> *From:* Sean Reid [mailto:sean.reid8@gmail.com]
> *Sent:* 26 March 2020 20:36
> *To:* 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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 01:32
> *To:* 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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 00:18
> *To:* 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 <ad...@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:mjumper@apache.org]
> *Sent:* 25 March 2020 22:26
> *To:* 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 <ad...@eesm.com> wrote:
>
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
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.reid8@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 <ad...@eesm.com>> wrote:
Thank you Sean.
I look forward to the update!
Adrian
From: Sean Reid [mailto:sean.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 20:36
To: user@guacamole.apache.org<ma...@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 <ad...@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.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 01:32
To: user@guacamole.apache.org<ma...@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 <ad...@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.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 00:18
To: user@guacamole.apache.org<ma...@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 <ad...@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:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 22:26
To: user@guacamole.apache.org<ma...@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 <ad...@eesm.com>> wrote:
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
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 <ad...@eesm.com> wrote:
> Thank you Sean.
>
>
>
> I look forward to the update!
>
>
>
> Adrian
>
>
>
> *From:* Sean Reid [mailto:sean.reid8@gmail.com]
> *Sent:* 26 March 2020 20:36
> *To:* 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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 01:32
> *To:* 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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 00:18
> *To:* 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 <ad...@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:mjumper@apache.org]
> *Sent:* 25 March 2020 22:26
> *To:* 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 <ad...@eesm.com> wrote:
>
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
Thank you Sean.
I look forward to the update!
Adrian
From: Sean Reid [mailto:sean.reid8@gmail.com]
Sent: 26 March 2020 20:36
To: 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 <ad...@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.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 01:32
To: user@guacamole.apache.org<ma...@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 <ad...@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.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 00:18
To: user@guacamole.apache.org<ma...@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 <ad...@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:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 22:26
To: user@guacamole.apache.org<ma...@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 <ad...@eesm.com>> wrote:
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 01:32
> *To:* 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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 00:18
> *To:* 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 <ad...@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:mjumper@apache.org]
> *Sent:* 25 March 2020 22:26
> *To:* 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 <ad...@eesm.com> wrote:
>
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
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.reid8@gmail.com]
Sent: 26 March 2020 01:32
To: 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 <ad...@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.reid8@gmail.com<ma...@gmail.com>]
Sent: 26 March 2020 00:18
To: user@guacamole.apache.org<ma...@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 <ad...@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:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 22:26
To: user@guacamole.apache.org<ma...@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 <ad...@eesm.com>> wrote:
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
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 <ad...@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.reid8@gmail.com]
> *Sent:* 26 March 2020 00:18
> *To:* 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 <ad...@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:mjumper@apache.org]
> *Sent:* 25 March 2020 22:26
> *To:* 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 <ad...@eesm.com> wrote:
>
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
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.reid8@gmail.com]
Sent: 26 March 2020 00:18
To: 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 <ad...@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:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 22:26
To: user@guacamole.apache.org<ma...@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 <ad...@eesm.com>> wrote:
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
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 <ad...@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:mjumper@apache.org]
> *Sent:* 25 March 2020 22:26
> *To:* 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 <ad...@eesm.com> wrote:
>
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
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:mjumper@apache.org]
Sent: 25 March 2020 22:26
To: 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 <ad...@eesm.com>> wrote:
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org<ma...@apache.org>]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Mike Jumper <mj...@apache.org>.
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 <ad...@eesm.com> wrote:
> Mike,
>
>
>
> Is there a less convoluted way to grab the text displayed?
>
>
>
> *From:* Mike Jumper [mailto:mjumper@apache.org]
> *Sent:* 25 March 2020 20:42
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
>
>
> On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
>
>
>
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
Mike,
Is there a less convoluted way to grab the text displayed?
From: Mike Jumper [mailto:mjumper@apache.org]
Sent: 25 March 2020 20:42
To: user@guacamole.apache.org
Subject: Re: guacenc new parameters
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
Re: guacenc new parameters
Posted by Mike Jumper <mj...@apache.org>.
On Wed, Mar 25, 2020 at 8:58 AM Adrian Owen <ad...@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
RE: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
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 ....
This would be similar to using ffmpeg to generate PNG snapshots from M4V.
Thanks, Adrian
From: Adrian Owen
Sent: 15 March 2020 22:38
To: user@guacamole.apache.org
Subject: Re: guacenc new parameters
Hi Sean,
Yes this is something I'd be very interested on working on.
My requirements are simple. Start at point x and run to the end.
The stream will be active (locked), and each time I visit it and will have moved on.
Or supply the 2 parameters, either way make it a contribution to guacamole project
I had as look at video.c and see I have a really steep learning curve ahead to code it.
Thanks Adrian
________________________________
From: Sean Reid <se...@gmail.com>>
Sent: 15 March 2020 22:15
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
Hi Adrian,
Is this something you'd be interested in working on? I've worked a bit on guacenc myself, so I can give you some information that I've found from working on it.
I'm not confident that you need to think about keyframes much at all from the perspective of guacenc. From my understanding (and I welcome anyone who might differ from my understanding or explanation here to jump in), since the Guacamole Protocol attempts to only send changes, guacenc renders a new image in memory for each new instruction in the recording file, based on the previously rendered image. Each new image is just a mutation of the previous, but itself is a full image. These images are sent to libavcodec on a periodic that matches the target framerate. This is done because the guacamole protocol doesn't have a framerate, so to square the circle of converting to a video with a time base, guacenc holds the image in memory so that it can repeat sending unchanged frames to libavcodec if no guacamole protocol instructions mutated the in-memory image. This implicitly means that each image guacenc sends can be a keyframe, so you could potentially start the encoding at any frame you'd like.
I'd recommend you look at the logic of video.c<https://github.com/apache/guacamole-server/blob/master/src/guacenc/video.c> in the guacenc source to get a better idea about how this process works.
Sean
On Sun, Mar 15, 2020 at 5:17 PM Adrian Owen <ad...@eesm.com>> wrote:
Hi Sean,
Thanks!
I believe that Keyframes are written to video stream, done as work for the Player.
So I guess it would be StartKeyFrame EndKeyFrame.
It would have to start at StartKeyFrame and run 'n' keyframes and stop.
So its a matter of scanning the video stream file for keyframes.
That is challenging. I am a C programmer, but know not how to identify a keyframe while reading the stream.
Adrian
________________________________
From: Sean Reid <se...@gmail.com>>
Sent: 15 March 2020 20:02
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
Hi Adrian,
I don't see a reason that this wouldn't be possible. I think it would be done by guacenc, though, not by ffmpeg. I'd think that guacenc just wouldn't start sending the frames to be encoded until, while reading the input file, guacenc has reached the start time and stop sending frames to be encoded at end time.
Sean
On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com>> wrote:
Hi,
ffmpeg allows getting a section of a video file by specifying start seconds and end seconds,
Now the Guacamole video steam may not know seconds but:
Could Guacenc support extra parameters: StartPoint Endpoint?
And then only generate MV4 between those points.
This is a theoretical question,
Many thanks, Adrian
Re: guacenc new parameters
Posted by Mike Jumper <mi...@glyptodon.com>.
I can clarify a bit here on what is present in the Guacamole protocol
stream and how it relates to the traditional video concept of a keyframe.
First, the Guacamole protocol stream is not a video stream. The Guacamole
protocol consists of a series of instructions, including instructions
related to graphical operations, audio, file/data transfer, events, etc.
The concept of a video stream here would relate only to a subset of those
instructions. With that in mind:
A keyframe is a frame which *does not* depend on earlier parts of the
video. The graphical content of a Guacamole protocol stream is generally
entirely incremental, and as such contains zero keyframes, with the
possible exception of the initial part of the stream (which inherently has
to initialize the display state). To replay the Guacamole instructions of a
particular frame, you must have the display state resulting from all
previous frames.
You *can* quickly seek to any particular point with a binary search, as the
stream contains timestamps which are naturally in sorted order, but you
would then need to replay all instructions prior to that point. This is
what the player object provided by guacamole-common-js does. The player
object also takes this a step further and dynamically generates its own
internal key frames (snapshots of display state), so that you can seek
backward in the stream quickly.
What you describe is possible - you would end up replaying the stream up to
the start timestamp (without writing video frames), then begin writing
video frames as normal, and then stop the process once you reach the end
timestamp.
- Mike
On Sun, Mar 15, 2020 at 3:38 PM Adrian Owen <ad...@eesm.com> wrote:
> Hi Sean,
>
>
> Yes this is something I'd be very interested on working on.
>
>
> My requirements are simple. Start at point x and run to the end.
>
>
> The stream will be active (locked), and each time I visit it and will have
> moved on.
>
>
>
> Or supply the 2 parameters, either way make it a contribution to guacamole
> project
>
>
>
> I had as look at video.c and see I have a really steep learning curve
> ahead to code it.
>
> Thanks Adrian
>
> ------------------------------
> *From:* Sean Reid <se...@gmail.com>
> *Sent:* 15 March 2020 22:15
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
> Hi Adrian,
>
> Is this something you'd be interested in working on? I've worked a bit on
> guacenc myself, so I can give you some information that I've found from
> working on it.
>
> I'm not confident that you need to think about keyframes much at all from
> the perspective of guacenc. From my understanding (and I welcome anyone who
> might differ from my understanding or explanation here to jump in), since
> the Guacamole Protocol attempts to only send changes, guacenc renders a new
> image in memory for each new instruction in the recording file, based on
> the previously rendered image. Each new image is just a mutation of the
> previous, but itself is a full image. These images are sent to libavcodec
> on a periodic that matches the target framerate. This is done because the
> guacamole protocol doesn't have a framerate, so to square the circle of
> converting to a video with a time base, guacenc holds the image in memory
> so that it can repeat sending unchanged frames to libavcodec if no
> guacamole protocol instructions mutated the in-memory image. This
> implicitly means that each image guacenc sends can be a keyframe, so you
> could potentially start the encoding at any frame you'd like.
>
> I'd recommend you look at the logic of video.c
> <https://github.com/apache/guacamole-server/blob/master/src/guacenc/video.c>
> in the guacenc source to get a better idea about how this process works.
>
> Sean
>
> On Sun, Mar 15, 2020 at 5:17 PM Adrian Owen <ad...@eesm.com> wrote:
>
>> Hi Sean,
>>
>>
>> Thanks!
>>
>>
>> I believe that Keyframes are written to video stream, done as work for
>> the Player.
>>
>>
>> So I guess it would be StartKeyFrame EndKeyFrame.
>>
>>
>> It would have to start at StartKeyFrame and run 'n' keyframes and stop.
>>
>>
>> So its a matter of scanning the video stream file for keyframes.
>>
>>
>> That is challenging. I am a C programmer, but know not how to identify a
>> keyframe while reading the stream.
>>
>>
>>
>>
>> Adrian
>>
>>
>>
>> ------------------------------
>> *From:* Sean Reid <se...@gmail.com>
>> *Sent:* 15 March 2020 20:02
>> *To:* user@guacamole.apache.org
>> *Subject:* Re: guacenc new parameters
>>
>> Hi Adrian,
>>
>> I don't see a reason that this wouldn't be possible. I think it would be
>> done by guacenc, though, not by ffmpeg. I'd think that guacenc just
>> wouldn't start sending the frames to be encoded until, while reading the
>> input file, guacenc has reached the start time and stop sending frames to
>> be encoded at end time.
>>
>> Sean
>>
>> On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com> wrote:
>>
>>> Hi,
>>>
>>> ffmpeg allows getting a section of a video file by specifying start
>>> seconds and end seconds,
>>>
>>> Now the Guacamole video steam may not know seconds but:
>>>
>>> Could Guacenc support extra parameters: StartPoint Endpoint?
>>>
>>> And then only generate MV4 between those points.
>>>
>>>
>>> This is a theoretical question,
>>>
>>>
>>> Many thanks, Adrian
>>>
>>>
Re: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
Hi Sean,
Yes this is something I'd be very interested on working on.
My requirements are simple. Start at point x and run to the end.
The stream will be active (locked), and each time I visit it and will have moved on.
Or supply the 2 parameters, either way make it a contribution to guacamole project
I had as look at video.c and see I have a really steep learning curve ahead to code it.
Thanks Adrian
________________________________
From: Sean Reid <se...@gmail.com>
Sent: 15 March 2020 22:15
To: user@guacamole.apache.org
Subject: Re: guacenc new parameters
Hi Adrian,
Is this something you'd be interested in working on? I've worked a bit on guacenc myself, so I can give you some information that I've found from working on it.
I'm not confident that you need to think about keyframes much at all from the perspective of guacenc. From my understanding (and I welcome anyone who might differ from my understanding or explanation here to jump in), since the Guacamole Protocol attempts to only send changes, guacenc renders a new image in memory for each new instruction in the recording file, based on the previously rendered image. Each new image is just a mutation of the previous, but itself is a full image. These images are sent to libavcodec on a periodic that matches the target framerate. This is done because the guacamole protocol doesn't have a framerate, so to square the circle of converting to a video with a time base, guacenc holds the image in memory so that it can repeat sending unchanged frames to libavcodec if no guacamole protocol instructions mutated the in-memory image. This implicitly means that each image guacenc sends can be a keyframe, so you could potentially start the encoding at any frame you'd like.
I'd recommend you look at the logic of video.c<https://github.com/apache/guacamole-server/blob/master/src/guacenc/video.c> in the guacenc source to get a better idea about how this process works.
Sean
On Sun, Mar 15, 2020 at 5:17 PM Adrian Owen <ad...@eesm.com>> wrote:
Hi Sean,
Thanks!
I believe that Keyframes are written to video stream, done as work for the Player.
So I guess it would be StartKeyFrame EndKeyFrame.
It would have to start at StartKeyFrame and run 'n' keyframes and stop.
So its a matter of scanning the video stream file for keyframes.
That is challenging. I am a C programmer, but know not how to identify a keyframe while reading the stream.
Adrian
________________________________
From: Sean Reid <se...@gmail.com>>
Sent: 15 March 2020 20:02
To: user@guacamole.apache.org<ma...@guacamole.apache.org>
Subject: Re: guacenc new parameters
Hi Adrian,
I don't see a reason that this wouldn't be possible. I think it would be done by guacenc, though, not by ffmpeg. I'd think that guacenc just wouldn't start sending the frames to be encoded until, while reading the input file, guacenc has reached the start time and stop sending frames to be encoded at end time.
Sean
On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com>> wrote:
Hi,
ffmpeg allows getting a section of a video file by specifying start seconds and end seconds,
Now the Guacamole video steam may not know seconds but:
Could Guacenc support extra parameters: StartPoint Endpoint?
And then only generate MV4 between those points.
This is a theoretical question,
Many thanks, Adrian
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
Hi Adrian,
Is this something you'd be interested in working on? I've worked a bit on
guacenc myself, so I can give you some information that I've found from
working on it.
I'm not confident that you need to think about keyframes much at all from
the perspective of guacenc. From my understanding (and I welcome anyone who
might differ from my understanding or explanation here to jump in), since
the Guacamole Protocol attempts to only send changes, guacenc renders a new
image in memory for each new instruction in the recording file, based on
the previously rendered image. Each new image is just a mutation of the
previous, but itself is a full image. These images are sent to libavcodec
on a periodic that matches the target framerate. This is done because the
guacamole protocol doesn't have a framerate, so to square the circle of
converting to a video with a time base, guacenc holds the image in memory
so that it can repeat sending unchanged frames to libavcodec if no
guacamole protocol instructions mutated the in-memory image. This
implicitly means that each image guacenc sends can be a keyframe, so you
could potentially start the encoding at any frame you'd like.
I'd recommend you look at the logic of video.c
<https://github.com/apache/guacamole-server/blob/master/src/guacenc/video.c>
in the guacenc source to get a better idea about how this process works.
Sean
On Sun, Mar 15, 2020 at 5:17 PM Adrian Owen <ad...@eesm.com> wrote:
> Hi Sean,
>
>
> Thanks!
>
>
> I believe that Keyframes are written to video stream, done as work for the
> Player.
>
>
> So I guess it would be StartKeyFrame EndKeyFrame.
>
>
> It would have to start at StartKeyFrame and run 'n' keyframes and stop.
>
>
> So its a matter of scanning the video stream file for keyframes.
>
>
> That is challenging. I am a C programmer, but know not how to identify a
> keyframe while reading the stream.
>
>
>
>
> Adrian
>
>
>
> ------------------------------
> *From:* Sean Reid <se...@gmail.com>
> *Sent:* 15 March 2020 20:02
> *To:* user@guacamole.apache.org
> *Subject:* Re: guacenc new parameters
>
> Hi Adrian,
>
> I don't see a reason that this wouldn't be possible. I think it would be
> done by guacenc, though, not by ffmpeg. I'd think that guacenc just
> wouldn't start sending the frames to be encoded until, while reading the
> input file, guacenc has reached the start time and stop sending frames to
> be encoded at end time.
>
> Sean
>
> On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com> wrote:
>
>> Hi,
>>
>> ffmpeg allows getting a section of a video file by specifying start
>> seconds and end seconds,
>>
>> Now the Guacamole video steam may not know seconds but:
>>
>> Could Guacenc support extra parameters: StartPoint Endpoint?
>>
>> And then only generate MV4 between those points.
>>
>>
>> This is a theoretical question,
>>
>>
>> Many thanks, Adrian
>>
>>
Re: guacenc new parameters
Posted by Adrian Owen <ad...@eesm.com>.
Hi Sean,
Thanks!
I believe that Keyframes are written to video stream, done as work for the Player.
So I guess it would be StartKeyFrame EndKeyFrame.
It would have to start at StartKeyFrame and run 'n' keyframes and stop.
So its a matter of scanning the video stream file for keyframes.
That is challenging. I am a C programmer, but know not how to identify a keyframe while reading the stream.
Adrian
________________________________
From: Sean Reid <se...@gmail.com>
Sent: 15 March 2020 20:02
To: user@guacamole.apache.org
Subject: Re: guacenc new parameters
Hi Adrian,
I don't see a reason that this wouldn't be possible. I think it would be done by guacenc, though, not by ffmpeg. I'd think that guacenc just wouldn't start sending the frames to be encoded until, while reading the input file, guacenc has reached the start time and stop sending frames to be encoded at end time.
Sean
On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com>> wrote:
Hi,
ffmpeg allows getting a section of a video file by specifying start seconds and end seconds,
Now the Guacamole video steam may not know seconds but:
Could Guacenc support extra parameters: StartPoint Endpoint?
And then only generate MV4 between those points.
This is a theoretical question,
Many thanks, Adrian
Re: guacenc new parameters
Posted by Sean Reid <se...@gmail.com>.
Hi Adrian,
I don't see a reason that this wouldn't be possible. I think it would be
done by guacenc, though, not by ffmpeg. I'd think that guacenc just
wouldn't start sending the frames to be encoded until, while reading the
input file, guacenc has reached the start time and stop sending frames to
be encoded at end time.
Sean
On Sun, Mar 15, 2020 at 1:55 PM Adrian Owen <ad...@eesm.com> wrote:
> Hi,
>
> ffmpeg allows getting a section of a video file by specifying start
> seconds and end seconds,
>
> Now the Guacamole video steam may not know seconds but:
>
> Could Guacenc support extra parameters: StartPoint Endpoint?
>
> And then only generate MV4 between those points.
>
>
> This is a theoretical question,
>
>
> Many thanks, Adrian
>
>