简体   繁体   English

使用adb screenrecord命令将Android屏幕通过USB镜像到PC

[英]Use adb screenrecord command to mirror Android screen to PC via USB

I've tried the suggestion from fadden to mirror the Android screen to PC, but the vlc player screen show nothing:我试过 fadden 的建议,将Android屏幕镜像到 PC,但 vlc 播放器屏幕什么都不显示:

在此处输入图像描述

What would be the correct commands lines for this function?这个 function 的正确命令行是什么? Thanks.谢谢。

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:由于 vlc 无法从 adb std 输出播放 h264 文件,我转而使用 ffplay 作为流播放器,它通过以下命令工作:

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

OS X binary ffplay and streaming screens: OS X 二进制ffplay和流屏幕:

在此处输入图片说明

Thanks!!谢谢!!

I don't remember the vlc command line that I used for the initial testing.我不记得我用于初始测试的 vlc 命令行。 I've tried a few different things recently, on desktop Linux (Ubuntu 15.10).我最近在桌面 Linux (Ubuntu 15.10) 上尝试了一些不同的东西。

VLC VLC

If you just pipe the output into vlc --demux h264 - , it appears to work, but you get gradually farther behind.如果您只是将输出通过管道vlc --demux h264 -vlc --demux h264 - ,它似乎可以工作,但您会逐渐落后。 Adding --h264-fps=60 seems to help that, but you start getting errors (" ES_OUT_SET_(GROUP_)PCR is called too late ").添加--h264-fps=60似乎有帮助,但您开始收到错误(“ 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.添加--clock-jitter=0似乎可以减少错误的创伤,但它仍然很混乱。

ffplay 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.一个简单的ffplay -工作,但似乎需要几秒钟才能决定开始,并且最终远远落后于整个时间。

Update - January 2018更新 - 2018 年 1 月

Using ffplay -framerate 60 -framedrop -bufsize 16M - gives you a decent quality that lasts for quite a while.使用ffplay -framerate 60 -framedrop -bufsize 16M -为您提供持续很ffplay -framerate 60 -framedrop -bufsize 16M -的体面质量。 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.这是由于以下命令同步了帧速率和比特率,否则视频将尝试以 30fps 播放,由于额外的帧,随着时间的推移,一切看起来/变慢。 The bitrate will then help keep the video properly timed as best as possible.然后,比特率将有助于尽可能保持视频正确定时。 I've found it works within a 100-1000MS delay ;我发现它可以在 100-1000 毫秒的延迟内工作 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最好重启-probesize 16M或者尝试追加-probesize 16M

Note: This configuration with ffplay works with the following adb command piped beforehand.注意:此 ffplay 配置适用于预先通过管道传输的以下 adb 命令。 If you're running GPU intensive tasks or using an older phone, a size of 1280x720 is a better recommendation.如果您正在运行 GPU 密集型任务或使用较旧的手机,则建议使用1280x720大小。 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.如果您的手机不支持 60fps(或似乎没有以 60fps 录制),请更改为适当的值,例如 30 或 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.命令mplayer -demuxer h264es -似乎产生了最好的结果。 Starts immediately, very little delay, and doesn't freak out like vlc.立即开始,几乎没有延迟,并且不会像 vlc 那样惊慌失措。

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:根据上面的答案,我尝试了所有可能的组合,只有一个不会滞后很多,不会停止并且具有不错的视频质量,带有 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 .请注意,这仍然远非完美,但完成了工作,我也通过 WiFi 进行了尝试,并且已经足够好了

mplayer播放器

For the low latency playback, the mplayer worked the best so far.对于低延迟播放,mplayer 迄今为止效果最好。

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.注意:以上设置mplayer尽快消耗帧。 Though, as a result, the playback window may be sluggish when waiting for new frames.尽管如此,在等待新帧时,播放窗口可能会很慢。

The screenrecord has a 3 minutes time limit "feature".屏幕记录有 3 分钟的时间限制“功能”。 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 -

Using any of the adb shell commands produced corrupted data for me.使用任何adb shell命令都会为我生成损坏的数据。 Using adb exec-out , as noted by lord-ralf-adolf in a comment on the accepted answer , fixed the problem.正如lord-ralf-adolf在对已接受答案的评论中所指出的,使用adb exec-out解决了该问题。

I used this exact command to get optimal video quality and minimal lag from a Galaxy S6:我使用这个确切的命令从 Galaxy S6 获得最佳视频质量和最小延迟:

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

I found that the lowest latency playback can be achieved by:我发现最低延迟播放可以通过以下方式实现:

adb exec-out screenrecord --bit-rate=64m --output-format=h264 --size=1080x680 - | ffplay -framerate 60 -framedrop -fflags nobuffer -flags low_delay -strict experimental -analyzeduration 100000 -probesize 64 -sync ext -vf setpts=0 -fflags discardcorrupt -

As per How to minimize the delay in a live streaming with ffmpeg根据How to minimize delay in a live streaming with ffmpeg

I found this software (for linux, windows and mac) that allows you to mirror and control your device connected via adb:我找到了这个软件(适用于 linux、windows 和 mac),它允许您镜像和控制通过 adb 连接的设备:

https://github.com/Genymobile/scrcpy https://github.com/Genymobile/scrcpy

It saved me!它救了我!

Best results for me with mpv :使用mpv对我来说最好的结果:

adb shell screenrecord --bit-rate=16m --size 540x1140 --output-format=h264 - | mpv --profile=low-latency --no-correct-pts --fps=60 -

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM