- this works and displays no video, but eats 40-50% of CPU core.
Recompiled latest git pull with debug symbols, ran perf, top 4 CPU users:
So, it is clearly doing decoding even with -nodisp and -vn options (-vn
makes no difference).
Re: Receive network stream and drop without decoding
On 2020-06-16 01:22, Carl Eugen Hoyos wrote:
> Drop the map option.
Well, not working as expected :(
While this is kinda-working on this DASH example (it receives stream at
max speed with low CPU load) - it does not work as "client" at the same
time and fails badly on live streams as it tries to get stream as fast
In other words - ffplay "plays" stream at 100% of speed, requests new
packet, gets it, "plays" again and so on. Server live stream time is
going together with client, no desync, all DASH segments are provided
ffmpeg tries to do something with stream fast as possible, so only
network is limiting factor on recorded streams (i tested few, sometimes
it goes up to 30x realtime). On live streams it fails quickly as server
do not have stream in future (as ffmpeg requests new chunk in 1 second,
instead of 2 seconds, for example). This is also a problem on recorded
stream, as every client tries to take full record at maximum speed - far
from real client which requests each chunk at realtime.
I can't find any option to limit ffmpeg speed (if it can work at exactly
1x speed this may solve this problem), so maybe modifying ffplay is easier?
There is decoder_decode_frame function in ffplay, what if i do immediate
'return 0' from it?
ffmpeg-user mailing list
[hidden email] https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
I see network traffic (10Mbps) and, based on consumption - can fit
probably thousand or more copies to make proper load generator for server.
perf report shows that most load comes from libc functions, so probably
nothing to optimize on ffmpeg side already (network traffic).