add CBR encoder mode please !!!!

[masterchiang]

i find out the lag problem, X264 VBR encouder is spent much CPU resource, i test a record file on Static ,it just 20M size for 180second. so ,i test a dynamic record file too. about 600M size for 180second ,so i know it must be VBR mode.

options spec
150M bite rate ,120FPS,1920 MAX SIZE

as we all know ,VBR will spent lots of CPU usage, it will increase transport lag, so i hope can add a CBR mode ,fast to fast. with best quality. we dont care the transport size,use for streaming

whatever USB2.0 or 3.0,i think its enough of bandwidth

[masterchiang]

@rom1v come on Boss ! it time to update

[rom1v]

i find out the lag problem

Which lag problem?

I'm not sure to understand. What is a "static" or "dynamic" record? Why CBR? It's not the fact that it is CBR or VBR, but the complexity of the encoding (but it should not impact CPU a lot, since the main work is done by hardware decoder/encoder).

Just a remark: the encoding is done by your device hardware encoder, it is fast, but not optimal. If you reencode your recorded file with x264, you will probably get a smaller file:

ffmpeg -i record.mkv -c:v libx264 -crf 25 out.mkv

The difference depends a lot on your device hardware encoder efficiency. For example, my Nexus 5 produces very big files (I get 10× smaller file if I reencode in CRF 25), while my OnePlus 7 Pro produces files with acceptable file sizes (the result is only 2× smaller).

[masterchiang]

i find out the lag problem

Which lag problem?

I'm not sure to understand. What is a "static" or "dynamic" record? Why CBR? It's not the fact that it is CBR or VBR, but the complexity of the encoding (but it should not impact CPU a lot, since the main work is done by hardware decoder/encoder).

Just a remark: the encoding is done by your device hardware encoder, it is fast, but not optimal. If you reencode your recorded file with x264, you will probably get a smaller file:

ffmpeg -i record.mkv -c:v libx264 -crf 25 out.mkv

The difference depends a lot on your device hardware encoder efficiency. For example, my Nexus 5 produces very big files (I get 10× smaller file if I reencode in CRF 25), while my OnePlus 7 Pro produces files with acceptable file sizes (the result is only 2× smaller).

i wanna modify mediacodec options, but lots of function no work, such "bitrate mode",max rate and min rate ,especially "vcodec". they couldnt work. even though scrcpy can run,i think it may you latest codec option not add some format.

a real CBR file,should be bigger size than VBR mode, although only record a picture

[rom1v]

What problem are you trying to solve?

[masterchiang]

What problem are you trying to solve?

wanna a good quality setting with big size record mode.VBR is no good at quality.

some commands is useless,is hardware not support??

[rom1v]

scrcpy -b20m -r record.mkv should give a good quality.

If you want to recompress:

ffmpeg -i record.mkv -c:v libx264 -crf 25 out.mkv

It should give a good quality and reasonable size.

[adahbingee]

CBR agree.

CBR codec mode is much more faster than VBR mode.

Even the media codec is most hardware accelerated, there still some process using CPU code-block estimation & decode

I'm working in MILLION DAU live streaming company, trust me.

Also x264 is faster and higher quality than x265 when setting small CRF or QP

[rom1v]

I didn't notice there was an option KEY_BITRATE_MODE in MediaCodec, so you can set it to BITRATE_MODE_CBR:

scrcpy --codec-options bitrate-mode=2

However, I just tested, it shows obvious quality loss on fast motion (compared to not passing the option), and it does not decrease latency (tested like in #646, it's even the opposite) on my device/computer.

Please test on your configuration and give feedbacks :)