答案 0 :(得分:23)
由于vlc无法从adb标准输出播放h264文件,因此我转而使用ffplay作为流播放器,它通过以下命令工作:
adb shell screenrecord --output-format=h264 - | ffplay -
OS X二进制文件ffplay和流媒体屏幕:
谢谢!
答案 1 :(得分:15)
我不记得我用于初始测试的vlc命令行。我最近在桌面Linux(Ubuntu 15.10)上尝试了一些不同的东西。
<强> VLC 强>
如果您只是将输出传输到vlc --demux h264 -
,它似乎可以正常工作,但您会逐渐落后。添加--h264-fps=60
似乎对此有所帮助,但您开始收到错误(“ES_OUT_SET_(GROUP_)PCR is called too late
”)。添加--clock-jitter=0
似乎可以减少错误的创伤,但它仍然很混乱。
<强> ffplay 强>
一个简单的ffplay -
有效,但似乎需要几秒钟才能决定开始,并且最终落后于整个时间。
使用ffplay -framerate 60 -framedrop -bufsize 16M -
会给你一个体面的品质,持续相当长一段时间。这是由于以下命令同步帧速率和比特率,因为视频将尝试以30fps播放,使得由于额外的帧,一切看起来/变慢。然后,比特率将帮助保持视频尽可能正确地定时。 我发现它在100-1000MS延迟内工作;与大多数蓝牙耳机类似。 您可能会收到“考虑增加探测”错误,可能会冻结该流。最好重新启动屏幕记录或尝试附加-probesize 16M
注意:此配置与ffplay一起使用事先管道的以下adb命令。如果您正在运行GPU密集型任务或使用较旧的手机,则1280x720
的大小是更好的建议。如果您的手机不支持60fps(或者似乎没有以60fps录制),请更改为适当的值,例如30或24。
adb exec-out screenrecord --bit-rate=16m --output-format=h264 --size 1920x1080 -
<强> mplayer的强>
命令mplayer -demuxer h264es -
似乎产生了最好的结果。立即开始,非常小的延迟,并且不像vlc那样吓人。
答案 2 :(得分:5)
基于上面的答案,我已经尝试了所有可能的组合,并且只有一个不会滞后很多,不停止并且具有不错的视频质量,使用ffplay:
adb shell screenrecord --bit-rate=16m --output-format=h264 --size 800x600 - | ffplay -framerate 60 -framedrop -bufsize 16M -
size参数可以更改为任何内容。
请注意,这仍然远非完美,但完成了工作,我也通过WiFi尝试了它,足够好。
答案 3 :(得分:2)
mplayer
对于低延迟播放,mplayer迄今为止效果最好。
adb shell screenrecord --output-format=h264 - | mplayer -framedrop -fps 6000 -cache 512 -demuxer h264es -
注意:以上设置将mplayer设置为尽快消耗帧。但是,因此,在等待新帧时,播放窗口可能会变慢。
屏幕记录具有3分钟的时间限制“功能”。如果您愿意通过代码重新编译它,可以使用good link。
重新编译屏幕记录后:
adb shell screenrecord --time-limit=31000 --output-format=h264 - | mplayer -framedrop -fps 6000 -cache 512 -demuxer h264es -
答案 4 :(得分:0)
使用任何adb shell
命令都会对我产生损坏的数据。正如lord-ralf-adolf在对accepted answer的评论中所指出的那样,使用adb exec-out
解决了该问题。
我使用此精确命令从Galaxy S6获得最佳视频质量和最小延迟:
adb exec-out screenrecord --output-format=h264 --size 540x960 - | ffplay -framerate 60 -framedrop -bufsize 16M -
答案 5 :(得分:0)