[FFmpeg-user] FFmpeg Not Transcoding In Real Time

James Girotti james.girotti at gmail.com
Tue Dec 4 06:07:29 EET 2018

On Sun, Dec 2, 2018 at 9:59 AM Gabriel Balaich <roderrooder at gmail.com>

> >
> > Furthermore when I try recording both streams in one 4K60 video via OBS
> > things work perfectly fine, as in real-time. So I don't understand how
> > transcoding two 1080p60 streams in FFmpeg would be anymore intensive than
> > one 4K60 stream in OBS... When looking at the GPUs encoding chip usage it
> > shows about 30% for the two 1080p60 streams on FFmpeg and 80% usage for
> > single 4K60 stream in OBS, yet the OBS recording is real-time while the
> > FFmpeg recording is at .6x speed.

This makes me think it's something with your commandline. I presume OBS
does not call the ffmpeg binary, but rather uses the APIs. So it might not
be possible to tell exactly what settings it uses.

> > Lastly I run a very similar command at home but instead of two 1080p60
> > streams I'm doing 2 4K60 streams, a 1080p60 stream, and another 2 audio
> > streams without issue. I do have a GTX 1080 though... however when
> > monitoring usage for the 1050 TI being used in this situation nothing
> > points to a GPU bottlecap.
> >

Theoretically, the 1050Ti should be able to encode streams up to 8K (that's
what I've gathered from Nvidia's docs).

> Update: we swapped the 1050ti for a GTX 1080 to no avail. It seems fairly
> obvious at this point that it is the CPU causing problems. However this
> still makes little sense, as stated I use a 6800K and do much more that
> what I'm trying to do on this build. The 8600K should have higher single
> core performance... However, the 6800K has Hyper Threading wile the 8600K
> does not, is it possible that FFmpeg better utilizes a Hyper Threaded
> processor?
> It looks to be only hitting 1-2 threads, anyway to force it to use more?
> -threads doesn't seem to do anything regardless of where I insert it into
> the command.

The GPU encoder is "single-thread", so it is the bottleneck as far as

> Lastly would it be possible to utilize hardware accelerated decode via GPU
> to alleviate the issue? When I try to instert -hwaccel cuvid -v:c
> h264_cuvid before the inputs like tutorials would suggest the recording
> immediately errors out saying "Cannot set format options for [capture
> card]". And when I remove -v:c h264_cuvid and just use -hwaccel cuvid I get
> and endless string of errors stating "yuvj422p is incompatible", I'm
> assuming that is the capture cards native pixel format. When I try to set
> the capture cards pixel format to NV12 it errors out again with "Cannot set
> format options for [capture card]", not sure what other pixel formats GPU
> acceleration supports but I assume I'm just out of luck with this capture
> cards limited pixel format options.

No, your input is MJPEG. You cannot use "-hwaccel cuvid -c:v h264_cuvid".
That would be if your input was h264. There is no hw decoder for MJPEG.
That's probably okay though and may be better (I don't want to get into
that part). It's highly likely that your CPU should be able to decode fast

> Once again any insight would be much appreciated.

It's hard for me to understand your complete commandline, there are a lot
of options. It seems to me that some of your options are not optimum, but
they may be the settings that you want/need, which is fine that's up to you
to decide (I don't quite understand why you'd want to output in NV12, but
that's your business). I suggest that you drastically simplify your
commandline. It will be easier to troubleshoot. You might also try saving
the input directly to a file without any transcoding. Then use that file to
test with at first to see how many FPS you can get. Something like:

ffmpeg -i "whatever_your_input_is" -map 0 -c copy -t 60 input1.ts

ffmpeg -i input1.ts -c:v h264_nvenc output1.ts

If that performs well, then try two inputs. If that performs well, then try
the "live" input, etc.

Best of Luck,

More information about the ffmpeg-user mailing list