Based on the <some things> I've observed - virtualized graphics is substantially poorer than real mode so it's actually best to implement <zero> graphics in the Guest. Do your transcoding in the Guest if you wish, but view the results in real mode (another physical machine or perhaps the Guest).
Re: keyboarding conflicts... I'm going to guess that they likely relate to GUI windows. If you follow my recommendation to not use a tool that way (most transcoding apps support command line even if they can be deployed in a Desktop), they wouldn't be an issue. Typically you just build your command and execute. If you're trying to do something else than transcoding, eg video slice and dicing... YMMV. Depends on your hardware. Depends on the app. Depends on a lot of variables. HTH, Tony On Fri, Mar 21, 2014 at 8:45 AM, Christian Jaeger <[email protected]> wrote: > Hi > > What's the best way to approach video editing in a guest? I would > assume that going fullscreen using a virtual console (framebuffer?) > would be better than running it within X? I don't need to record > video, just process pre-recorded files. > > I'm also looking for a way to minimize keyboarding conflicts between > host and guest, i.e. perhaps use ctl-alt-fX to switch between host and > guest *and back* (and hope never to need to switch virtual consoles > within the guest, but I can always send a key combo to the guest using > its monitor socket, I've got a tool for that already, so no problem), > is this possible? > > Thanks for your comments. > > Christian. > >
