Similarly, Steam streaming can be used with things that aren't games by using "add non-steam game to library". If the thing you add has a minimise button this can be used to get to the desktop of the streaming PC.
Edit: Question I've suddenly realised. What happens in either case (Microsoft recording or Steam) when you're playing a copyrighted video?
This is a handy trick, but these are different use cases. Yours is live streaming, but this is for making video files you still need to send/host. Not sure if it picks up a mic, but this could be handy for making quick and dirty tutorials.
I'm assuming this will only let you share a specific application, not the desktop itself. So this may not work as a complete replacement for screencasting software.
Video capture really should be part of the OS, like screencapture is. I use Screenflow on OS X to do this - it's very handy for demoing bugs to others, or sending people instructions etc.
You can even use the Quicktime Player to record your iPhone/iPad screen in high-quality via Lightning cable, or to simply view your iOS device on a big screen (with less lag than wireless/AirPlay.)
IIRC the "intended" use was to record demos of your apps and games, considering that QT Player got this feature at the same time they introduced video previews to the App Store. :)
I've noticed this feature, but it doesn't allow you to record audio with it too (mic or system sound). Am I missing something/is there a good way to do this?
After you click the "New Screen Recording" button a small rectangular window appears. Next to the Record button there is a drop down menu where you can indicate sound input source, as well as things like "Show Mouse Clicks". I recently came across this Quicktime tool. It's really nice, you can even do some simple movie editing with it (trim clips, combine clips etc). I use it to produce demo videos.
in the drop down where you select the iPhone as video source you can also select the iPhone as audio source. I'm not sure if it records the audio output of the iPhone or the microphone input of the phone.
The main problem with quicktime screen recording is that it's terribly slow with a Retina display, because it records at the display's native resolution.
Like others have said, QuickTime (which is part of OS X) does this for you. Sadly, it fares less well with recording desktop audio along with the video. In general, the audio routing options in OS X are relatively limited, although you can achieve some limited success with "Audio MIDI Setup".
For fullscreen audio and video recording, I would suggest simply running OBS. It might seem overkill, but it gets the job done.
Soundflower (and more importantly: SoundflowerBed) hasn't worked right for me since at least two major OS versions now. The project has changed hands several times, and is only being partially maintained.
If I had tried it, I would have said something about it. I'm reluctant to try it, because my routing needs are somewhat solved now with the onboard MIDI stuff, and because Rogue Amoeba are the ones who killed Soundflower in the first place.
I'd be curious if anyone has a JACK success story. It sounded like exactly what I was looking for, but in practice the thing was so arcane and impractical it seemed like too much trouble.
For Linux, this is pretty easy to do from the command-line with ffmpeg/ffcast (using the x11grab option). Here's a fuller explanation, plus GIF conversion with ImageMagick: http://unix.stackexchange.com/q/113695/16404
GIF isn't a good video codec. I would recommend VP8 or H264.
Using huffyuv for the initial capture is going to start stuttering at higher FPS (the example uses 15, presumably because anything higher would result in massive file sizes given GIF's terrible compression ratio), because the disk won't be able to write fast enough. x264 with the ultrafast preset is a better option in my experience.
I don't understand the purpose of the ffcast tool - it seems to be as or even more verbose than just use ffmpeg directly.
Yep, GIF sucks, but it's unfortunately the only thing even remotely close to video that's embeddable on most StackExchange sites and a whole lot of chat platforms.
Ffcast also integrates selection of the capture area, which is a rather finicky argument to pass from xrectsel to ffmpeg. No need for it if you're capturing fullscreen.
Very happy to have something like this baked into the OS.
I thought clicking "Yes, this is a game" was a joke, not that you actually have to tell the app that the program is a game...that's very confusing from a UX perspective. Why do they do that?
edit: on a side note, why doesn't this work in the file explorer or when not focused on a program?
I've done this to demo or give instructions before. There are some caveats, sometimes it doesn't record tool tips or contextual menus. It also will not record more than one program at a time, even if they are on the same monitor. It will record the program you were focused on when you first started recording. So forget showing off a drag and drop, etc.
I'd like to see them expand this to not be Xbox branded and to just be like the "snipping" feature (which I use all the time.)
Agree completely. It's a great feature and would remove much of the need for dedicated applications like Fraps or Camtasia Recorder for people who just do the occasional screen recording.
I tried doing this at one point early after the Win10 release (I think just to record a browser session) and there was something I didn't like about it. Sadly I forget what it was. Maybe it was that the Xbox app/recorder would always want to launch or run now that it thought that program was a "game" or maybe it was some hotkey conflict.
Either way I disabled it and await it someday becoming a more useful feature.
My problem with it is that as soon as I enable it, my mouse speed changes to the speed of light, and goes back as soon as I switch it off. It's literally unusable. So far I found no way to fix it.
I've never had that problem of it wanting to launch randomly, and the keyboard shortcut to launch it is fairly hard to do by accident. I just want it to record everything on the screen and allow me to change focus. I actually like the simplicity, so I hope they don't go overkill if they do anything more to it.
>> sometimes it doesn't record tool tips or contextual menus
Welcome to the abysmal implementation of interactive controls. For some awful historical and technical reason, most standard UI controls - such as dropdown menus - are laid out on top of your application's window by the operating system. That UI control is not part of your application; it is implemented as a separate window by the operating system which positions it on top of your application window in the requested x/y location.
The screen capturing is designed to capture a single window, and so only captures your application without these separate windows that display elements like a dropdown menu. It really is a disgusting hack. In any reasonable implementation, these controls would be inlined within your application, not outsourced to the operating system.
This is the same reason why it took so long for browsers to support styling of form elements, such as changing the background color of a dropdown. The operating system simply provided no way to allow for this. I'm not sure if the modern browser implementation with styled form elements still works with the operating system, or if they are required to bundle their own controls in order to have full control over their rendering.
My Google-fu is failing me. Does anyone know why standard operating system controls are laid out by the operating system, rather than by the application using a standard library that keeps them inline to the app itself?
It's not historical, or technical; it's the only sensible way to do it. Context menus, dropdowns, tooltips, etc. often need to protrude outside the application window, so they must be separate windows.
I don't understand that logic. There is no reason why a window should not be able to directly own a control that protrudes beyond its outermost border. At a bare minimum, the "child window" used to implement an element should directly be descended from the "parent window" of the application so that any attempt to capture an image of the parent window includes all child windows. This was clearly a limitation of the chosen implementation rather than an inherent limitation of all possible implementations.
Primary colors arranged geometrically has been a thing since Office 95, predating Google: http://logos.wikia.com/wiki/Microsoft_Office Since then, variations on the theme have been heavily reused for all kinds of logos.
Yeah, by "variations on the theme" I was referring to all kinds of shapes and arrangements, like in a square, circle, triangle, dots orbiting each other, ribbons, and so on. Just like the "thing with a swoosh/crescent" trend back in the 90s (to go along with company names ending in "ent"), logos with RYGB primary colors in all kinds of geometric patterns were a thing too. Logos for Google products like Chrome, Web, Apps, etc. are yet more iterations on an existing trend.
My argument is more for the fact that these two logos in particular seems pretty close. I'd be willing to put money that my parents wouldn't notice the difference if you swapped the sharex logo out for the chrome logo.
It's just marketing. Sharing game recordings with friends is "A Thing". Microsoft wants to be seen as helping normal users do popular things (and get them tied closer into the Xbox brand). Recording for other purposes doesn't let them brand the feature as obviously.
From what other commenters are saying, it often misses things like tooltips and menu dropdowns.
60 comments
[ 6.0 ms ] story [ 139 ms ] threadOn using things for other than its original purpose:
1) http://www.tedunangst.com/flak/post/file-considered-harmful
2) https://stallman.org/articles/on-hacking.html
Edit: Question I've suddenly realised. What happens in either case (Microsoft recording or Steam) when you're playing a copyrighted video?
Well done Windows.
QuicktimePlayer -> File menu -> New Screen Recording
https://www.google.com/imgres?imgurl=http://etc.usf.edu/tech...
For fullscreen audio and video recording, I would suggest simply running OBS. It might seem overkill, but it gets the job done.
I'd be curious if anyone has a JACK success story. It sounded like exactly what I was looking for, but in practice the thing was so arcane and impractical it seemed like too much trouble.
Using huffyuv for the initial capture is going to start stuttering at higher FPS (the example uses 15, presumably because anything higher would result in massive file sizes given GIF's terrible compression ratio), because the disk won't be able to write fast enough. x264 with the ultrafast preset is a better option in my experience.
I don't understand the purpose of the ffcast tool - it seems to be as or even more verbose than just use ffmpeg directly.
Ffcast also integrates selection of the capture area, which is a rather finicky argument to pass from xrectsel to ffmpeg. No need for it if you're capturing fullscreen.
I thought clicking "Yes, this is a game" was a joke, not that you actually have to tell the app that the program is a game...that's very confusing from a UX perspective. Why do they do that?
edit: on a side note, why doesn't this work in the file explorer or when not focused on a program?
I'd like to see them expand this to not be Xbox branded and to just be like the "snipping" feature (which I use all the time.)
I tried doing this at one point early after the Win10 release (I think just to record a browser session) and there was something I didn't like about it. Sadly I forget what it was. Maybe it was that the Xbox app/recorder would always want to launch or run now that it thought that program was a "game" or maybe it was some hotkey conflict.
Either way I disabled it and await it someday becoming a more useful feature.
Welcome to the abysmal implementation of interactive controls. For some awful historical and technical reason, most standard UI controls - such as dropdown menus - are laid out on top of your application's window by the operating system. That UI control is not part of your application; it is implemented as a separate window by the operating system which positions it on top of your application window in the requested x/y location.
The screen capturing is designed to capture a single window, and so only captures your application without these separate windows that display elements like a dropdown menu. It really is a disgusting hack. In any reasonable implementation, these controls would be inlined within your application, not outsourced to the operating system.
This is the same reason why it took so long for browsers to support styling of form elements, such as changing the background color of a dropdown. The operating system simply provided no way to allow for this. I'm not sure if the modern browser implementation with styled form elements still works with the operating system, or if they are required to bundle their own controls in order to have full control over their rendering.
My Google-fu is failing me. Does anyone know why standard operating system controls are laid out by the operating system, rather than by the application using a standard library that keeps them inline to the app itself?
Video: H264 - MPEG-4 AVC (part 10) (avc1) Audio: MPEG AAC Audio (mp4a) at 48000 Hz
Sadly it maxes out at 1080p.
https://getsharex.com/favicon.ico
https://www.google.com/images/icons/product/chrome-48.png
From what other commenters are saying, it often misses things like tooltips and menu dropdowns.
On my PC, it says “There’s nothing to record. Play some more and try again”.
NVidia ShadowPlay records good here.