Use adb screenrecord command to mirror Android screen to PC via USB

Question

I've tried the suggestion from fadden to mirror the Android screen to PC, but the vlc player screen show nothing:

What would be the correct commands lines for this function? Thanks.

Solution 1

I don't remember the vlc command line that I used for the initial testing. I've tried a few different things recently, on desktop Linux (Ubuntu 15.10).

VLC

If you just pipe the output into vlc --demux h264 -, it appears to work, but you get gradually farther behind. Adding --h264-fps=60 seems to help that, but you start getting errors ("ES_OUT_SET_(GROUP_)PCR is called too late"). Adding --clock-jitter=0 seems to make the errors less traumatic, but it's still pretty messed up.

ffplay

A simple ffplay - works, but it seems to take a few seconds to decide to start, and ends up lagging well behind the entire time.

Update - January 2018

Using ffplay -framerate 60 -framedrop -bufsize 16M - gives you a decent quality that lasts for quite a while. This is due to the below command that synchronises the framerate and bitrate as the video will otherwise be trying to play at 30fps making everything look/get slower over time due to the extra frames. The bitrate will then help keep the video properly timed as best as possible. I've found it works within a 100-1000MS delay; similarly to most Bluetooth headsets. You might get a "consider increasing probesize" error that may freeze the stream. It's best to restart screenrecord or try appending -probesize 16M

Note: This configuration with ffplay works with the following adb command piped beforehand. If you're running GPU intensive tasks or using an older phone, a size of 1280x720 is a better recommendation. If your phone doesn't support 60fps (or doesn't seem to record in 60fps) change until appropriate with values such as 30 or 24.

adb exec-out screenrecord --bit-rate=16m --output-format=h264 --size 1920x1080 -

mplayer

The command mplayer -demuxer h264es - seems to yield the best results. Starts immediately, very little delay, and doesn't freak out like vlc.

Solution 2

Since vlc can't play the h264 file from adb std output, I turn to use ffplay as stream player and it works via the following command:

adb shell screenrecord --output-format=h264 - | ffplay -

OS X binary ffplay and streaming screens:

Thanks!!

Solution 3

Based on the answers above I have tried every possible combination and there is only one that is does not lag a lot, does not stop and has a decent video quality, with ffplay:

adb shell screenrecord --bit-rate=16m --output-format=h264 --size 800x600 - | ffplay -framerate 60 -framedrop -bufsize 16M -

The size parameter can be changed to anything.

Note this is still far from perfect, but gets the work done and I also tried it over WiFi and it was good enough.

Solution 4

mplayer

For the low latency playback, the mplayer worked the best so far.

adb shell screenrecord --output-format=h264 - | mplayer -framedrop -fps 6000 -cache 512 -demuxer h264es -

Note: the above sets the mplayer to consume frames as soon as possible. Though, as a result, the playback window may be sluggish when waiting for new frames.

The screenrecord has a 3 minutes time limit "feature". If you feel comfortable with recompiling it from code, here is a good link.

After recompiling the screenrecord:

adb shell screenrecord --time-limit=31000  --output-format=h264 - | mplayer -framedrop -fps 6000 -cache 512 -demuxer h264es -

Solution 5

Using any of the adb shell commands produced corrupted data for me. Using adb exec-out, as noted by lord-ralf-adolf in a comment on the accepted answer, fixed the problem.

I used this exact command to get optimal video quality and minimal lag from a Galaxy S6:

adb exec-out screenrecord --output-format=h264 --size 540x960 - | ffplay -framerate 60 -framedrop -bufsize 16M -

View more solutions

Comments

[Gautam]

Works Great on Ubuntu, Thanks !!

[Oliver Dixon]

How do i open this in vlc?

[Rich Elswick]

tried this on Mac OS X Yosemite and I get a "pipe:: Invalid data found when processing input" could be because I am going over bluetooth.

[Wesley]

When I use - as output, I got ：Unable to open '-': Read-only file system, how to fix this?

[smedasn]

How to do this on windows?

[Ciro Santilli OurBigBook.com]

Yes, ffplay could use some love.

[cbix]

Use adb shell "while true; do screenrecord --output-format=h264 --time-limit 5 -; done" | ffplay - to overcome the 180 seconds limit and have it react to screen orientation changes after < 5 seconds.

[Lytic]

@flo, you are a life saver! Thank you.

[lord-ralf-adolf]

why adb shell and not adb exec-out ? adb shell wasn't meant for piping exec-out is made specifically for piping it will give better results

[Joseph Reeve]

For people in future who are confused by no video showing (but no errors in the command line): I found nothing showed until I caused a lot of movement on the screen (scrolling app drawer etc). I guess it causes some buffer to fill?

[fadden]

@JosephReeve: Good point. Android doesn't generate frames if it doesn't need to. The screenrecord command captures generated frames -- it doesn't do periodic sampling -- so if nothing happens on-screen, no output will appear. The video codecs can require some amount of input buffering before generating output, so you may need to cause some screen updates before anything appears. (It'll wake up eventually because of clock updates, but dragging the notification shade will speed it along.)

[bgfvdu3w]

adb shell produced a jumbled mess. Tried adb exec-out and it solved the issue!

[Remolten]

@Mark Thank you! That solved my problem too. I was getting mostly corrupted video, even though you could see it was somewhat correct.

[Ayush Bansal]

@JosephReeve @fadden I am getting a black screen when trying adb exec-out screenrecord --bit-rate=16m --output-format=h264 --size 800x600 - | ffplay -framerate 60 -framedrop -bufsize 16M -. Am i executing this correctly?

[Stefan]

The official android documentation says that screenrecording stops after 3 minutes... Does this happen when using exec-out?

[fadden]

@Stefan: the limitation is in screenrecord, so it doesn't matter how you run it. (blame)