Confirm
1,927
edits
Changes
→Initial prototype
Code (and installation/usage docs): https://github.com/markrcote/eideticker
=== Investigation and Observations Status ===
* A call to Blackmagic support indicated that the Blackmagic cards can only capture Captures 1080p60 output from broadcast standards, e.g. 1080p at the standard 1920x1080, 720p LG phone at 1280x720, etc8-bit YUV 4:2:2 to a raw video file.
* It seems that the Transformer does ''not'' output at Transforms raw video into a standard resolution. I was unable to capture from it with any input setting. My TV is able to display it; however, the display is croppedcompressed AVI and a zipped archive of PNG images, lending credence to this theory. Blackmagic support said that many mobile devices do not output at broadcast standardsone per frame.
* The LG phone does have standard outputs; in fact, you can choose the output format (although only two of the options are supported Controlled by the capture card).** I was able to capture uncompressed video at both 720p and 1080p using Blackmagic's MediaExpress software. At 720p, the video recorded flawlessly, at least while browsing a few pages. At 1080p the machine lost framesweb interface, apparently due to disk speed (despite the SSD). However there's no reason to believe we which can't make it work with an even faster disk. The software and docs certainly imply that it shouldn't be a problem with a high-end machine.** None of also serve the HDMI output resolutions (1920x1080 and 1280x720) match the phone's screen's resolution (480x800). It appears that the image is scaled; it takes up the full vertical resolution but maintains aspect ratio and thus has large black bands on either side. It appears that this scaling is done by the phone after applications render the output to the screen. This means it isn't a pixel-perfect representation of what is on the screen and thus what Firefox calculates and displays.** I captured a couple frames and converted them from Targa to PNG.*** [http://people.mozilla.com/~mcote/eideticker/frames/mozilla.org-screenshot-720p.png Single output frame at 720p]*** [http://people.mozilla.com/~mcote/eideticker/frames/mozilla.org-screenshot-1080pcapture files.png Single output frame at 1080p]
* I was able Its screen is 480x800, but there is no option to record raw 720p and 1080p video output at 8-bit YUV (4:2:2) and play it back with mplayerthis resolution on the HDMI port. I have been able to record at 10-bit YUV, but it uses a special blackmagic codec that I haven't yet been able to play back yet, but I'm sure it's just a case A variety of finding the right incantationstandard formats are available.
* The SDK, for some reason, does not seem to support RGB It must be scaling (i.e. no subsampling) at 1080p. Only 8- and 10-bit YUV (4:2:2potentially converting) are supported. This is strange, given that MediaExpress can the output 10-bit RGB, albeit as an image sequence. I'll have to talk to support about thisat some level below the application layer.
* An Thus an exact 1:1 mapping of the pixels of the captured output to the pixels calculated and displayed to the phone's screen appears to be impossible is not possible with the current hardware configuration. I am uncertain of the exact ramifications of this on the project's goals, but there are probably some tasks that can be accomplished even with this inexact capture of screen output.
** Theoretically an HDMI-capable device with a screen exactly 720 or 1080 pixels high (or wide) should output a pixel-by-pixel match. Alternatively, there may exist capture cards that can capture at any resolution, which would have to be paired with a device that can output at exactly its screen's resolution (e.g. potentially the Transformer but not the LG).
** Alternatively, perhaps it would be possible to hack a device to treat its HDMI output as primary.
* In effectAt 1080p YUV 4:2:2, capturing any device's output with the DeckLink card there is the same as capturing any desktop's output, since the card can only no frame skipping. However disk speed could become an issue if we somehow manage to capture standard formats at their full resolutionRGB output.
** This shouldn't be an issue with a sufficiently fast disk.
** Also, perhaps a custom app could record only the pixels of interest, since most of each frame is black. There would probably be a CPU-disk speed tradeoff here.
