Hello. I'm attempting to decode and "re encode" live TV. I noticed that when I attempt to transcode say, 6 streams at a time, ffmpeg seems to end up using "at most" 50% of the cpu available on the given box. The basic syntax I'm using is ffmpeg -i input.ts -map 0:p:1344 1344.mp4 -map 0:p:1345 1345.mp4 -map 0:p:1346 1346.mp4 So multiple outputs that come from different parts of the same input (it's not a file, its a live TS capture in this particular case). I've noticed that the speed indicator ends up, in my instance, saying something like frame= 696 fps= 16 q=-1.0 Lq=-1.0 q=-1.0 q=-1.0 q=-1.0 q=-1.0 q=-1.0 size=N/A time=00:00:27.84 bitrate=N/A dup=217 drop=0 speed=0.645x (full command line and somewhat cleaned up console output: https://gist.github.com/rdp/51448985bfa48a1f72a2 ) However, if I look at cpu utilization, it hovers right around 50% consistently (two cores out of 4 basically), regardless of "-threads" setting applied. I'm able to capture the incoming stream "fast enough" (for instance, if I only transocde a few substreams, everything comes in fine, speed keeps up), and if I test "decode only" (all streams), it handles it fine speed=3.5x. Is there any tricks to get more cpu "utilization" here or is this more of something to be implemented in a google summer of code or what not (assuming some speedup is possible)? In trying to create a reproducible sample, I came up with this (not sure if its the same problem or not): https://trac.ffmpeg.org/raw-attachment/ticket/3025/sbs.2.5M.ts run this, you'll see that it uses around 200% cpu regardless of cores available: ./ffmpeg_g -ignore_unknown -y -i <(while cat sbs.2.5M.ts; do :; done) -map 0:p:817 -c:v libx264 -preset ultrafast -sn 817.mp4 -map 0:p:818 -c:v libx264 -preset ultrafast -sn 818.mp4 -map 0:p:820 -c:v libx264 -preset ultrafast -sn 820.mp4 -map 0:p:821 -c:v libx264 -preset ultrafast -qp 0 -sn 821.mp4 -map 0:p:830 -c:v libx264 -preset ultrafast -sn 830.mp4 -map 0:p:832 -c:v libx264 -preset ultrafast -qp 0 -sn 832.mp4 -map 0:p:819 -c:v libx264 -preset ultrafast -qp 0 -sn 819.mp4 -ignore_unknown -loglevel info Here's a smaller example, possibly related, uses 600% (out of 800%) on a different box: ./ffmpeg -i <(while cat sbs.2.5M.ts; do :; done) -map p:817 -y -sn 817.mp4 -ignore_unknown Any theories out there as to why it ends up using just 200% cpu? Or any ideas/workarounds to be able to transcode multiple at the same time from the same source and use all the cpu available? Thanks! -roger-
Roger Pack <rogerdpack2 <at> gmail.com> writes:
ffmpeg -i input.ts -map 0:p:1344 1344.mp4 -map 0:p:1345 1345.mp4 -map 0:p:1346 1346.mp4
Which encoder are you using? You do know that this is not x264-feature-requests, don't you?
Is there any tricks to get more cpu "utilization" here
The tricks lead to slower conversion time. Carl Eugen
On 1/30/16, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Roger Pack <rogerdpack2 <at> gmail.com> writes:
ffmpeg -i input.ts -map 0:p:1344 1344.mp4 -map 0:p:1345 1345.mp4 -map 0:p:1346 1346.mp4
Which encoder are you using?
libx264
You do know that this is not x264-feature-requests, don't you?
Yes.
Is there any tricks to get more cpu "utilization" here
The tricks lead to slower conversion time.
I'm referring more to the fact that if I output to two outputs, from the same ffmpeg instance, in essence, this: ffmpeg -i input output1 output2 takes twice as long as running these two in parallel: ffmpeg -i input output1 ffmpeg -i input output2 It appears to me that the encoders are working in serial (at least in this instance, which is libx264 -preset ultrafast). In the first example it uses around 250% cpu, in the second, it uses around 500% cpu. Would be nice to be able to have the first use 500% cpu, if that makes sense. I assume it's just a feature request. Cheers!
Roger Pack <rogerdpack2 <at> gmail.com> writes:
I'm referring more to the fact that if I output to two outputs, from the same ffmpeg instance, in essence, this:
ffmpeg -i input output1 output2
takes twice as long as running these two in parallel:
ffmpeg -i input output1 ffmpeg -i input output2
The tee muxer fixes this issue. Carl Eugen
On 2/23/16, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Roger Pack <rogerdpack2 <at> gmail.com> writes:
I'm referring more to the fact that if I output to two outputs, from the same ffmpeg instance, in essence, this:
ffmpeg -i input output1 output2
takes twice as long as running these two in parallel:
ffmpeg -i input output1 ffmpeg -i input output2
The tee muxer fixes this issue.
Hmm...it seems the tee muxer is mostly for encoding once, then outputting to several (the same encoded content) it apperas? In this particular instance I'm trying to encode multiple streams simultaneously "in parallel" so that I can use more cores (assuming each encoding uses at most 2 cores, which seems to be the case here). https://gist.github.com/rdp/0a152670b742053a2a69e8d54e613b9a was my attempt at it. I suppose it just isn't possible today, and I may file a trac feature request for it sometime. Cheers! -roger-
participants (2)
-
Carl Eugen Hoyos -
Roger Pack