Expected transcoding performance?

Beta Community DVR Beta
#1

Hi -

given this CPU:

4 cores / Intel® Core™ i7-3615QM CPU @ 2.30GHz

what would you guys expect for transcoding performance? i see that ffmpeg is called with -c:v h264_videotoolbox, which is guess is why the Settings page says “hardware” transcoder. however i find that the machine can only transcode 1080p/30 to 360p in real time. that seems slow. could this have to do with the fact that the machine is running 10.9.5?

thanks

rob

edit: seems like h264_videotoolbox might be using the GPU? the machine is a mac mini so the graphics card is the integrated Intel HD 4000. could it actually be slower than pure software on this cpu?

#2

There’s definitely something wrong there. -c:v libx264 would easily do 720p, if not 1080i/p, using the veryfast preset at crf=21. I have no experience with h264_videotoolbox.

#3

Performance should be a lot better than that. It is usually 2-3x faster compared to libx264.

Do you have anything plugged into the hdmi port?

#4

yes, the machine is my (hopefully soon to be legacy) EyeTV DVR machine, and it is plugged into one of the HDMI inputs on my samsung TV. does this mean all the GPU resources are tied up with that? it’s still useful to have a computer plugged into the TV so long-term i’d like to keep it connected.

would it be possible to add the option to use libx264 even though a hardware transcoder is available?

rob

#5

What generation Mac mini? Do you see any errors in the log?

On some macs the hardware encoder doesn’t kick in if nothing is plugged into hdmi, but I don’t think that matters on the mini.

#6

If you have an active VNC connection, that could be using up the hardware encoder too.

#7

it is a “late 2012” mac mini server. screen sharing is running, though there was no active connection at the time.

on replaying one particular recording i saw a couple of these errors:

h264_videotoolbox @ 0x7fe3a3004e00] Error setting realtime property: -1290

just now i set up for 720p transcoding and observed the following (different recording though):

2017/01/16 22:29:27 [HLS] Starting transcoder for file-3 at 4m52s
[mpegts @ 0x7ff7a5808000] PES packet size mismatch
[mpegts @ 0x7ff7a5808000] Dropped corrupted packet (stream = 1)
[ac3 @ 0x7ff7a582a000] frame sync error
Error while decoding stream #0:1: Invalid data found when processing input
2017/01/16 22:31:37 [HLS] Stopping transcoder session file-3
2017/01/16 22:31:38 [HLS] error during ffmpeg progress: unexpected EOF

nothing super interesting i guess.

interestingly when set up for 720p, i see ffmpeg burning 130-150% cpu. when set up for 360p, i see ffmpeg burning 220-230% of the cpu.

what i’m not grokking here is if i play these videos from my appleTV, they run fine. the problems i’m describing are happening when i try to use the web player.

rob

#8

The Apple TV does not require a transcoder for playback.

Sounds like there might be a compatibility issue with older versions of macOS.

#9

oh ok, i thought the atv could only decode mpeg4. i can try upgrading the mac, but given that EyeTV is essentially abandonware i was afraid to mess with the OS for no reason. i’ll probably leave it until everyone at home is cool with the channels DVR.

rob

edit: oh, i see that you guys wrote your own mpeg2 decoder for the atv.

#10

Yes, I thought h264_videotoolbox was a wrapper for hardware encoders too, and in the case of Intel-only graphics it would be for Intel QSV. However, QSV has not been ported to Mac OS for some reason. Having a rollback option (e.g. software encoding only) to x264 should improve performance considerably.

See here: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=3096

Note that on some lower-powered systems, particularly older ones, x264 can outperform hardware encoders, and if you want to balance quality and bandwidth it’s often the better option. Even on newer systems, x264 can always be tuned to give better quality for smaller data bandwidth, and so it might be preferred for some people. The downsize is that it taxes CPUs much more heavily.

1 Like
#11

VideoToolbox is Apple’s API that exposes the intel QSV engine to macOS. Since your CPU is QSV enabled, upgrading to a newer macOS should fix the issue.

1 Like
#12

OK. any way to know how far forward to go? i have a bunch of installers saved up so in theory i could go to 10.10 or 10.11.

i would also put in a vote for the option to use a software encoder. in my case if the performance were acceptable with libx264 i’d use that instead of upgrading the OS.

#13

Pretty sure 10.10 will work.

#14

ok if i can summon the courage i’ll try 10.10 :slight_smile:

#15

I had completely missed that QSV had been imported to the Mac, I guess because I tend to use HandBrakeCLI and it’s not appeared there yet, despite it being ffmpeg based. Thanks for the news!

#16

I am running dvr server on same hardware, 2012 mac mini with i7-3615QM CPU, and can transcode to 720p no problem. I have used 720p transcoding for web ui on a Linux desktop and several iOS devices. However, I am running latest 10.12.2 OS. Is there a reason you are running an old OS?

#17

I am having trouble getting the transcoding to play locally or remotely. The player after 10 seconds or so shows the timeline is moving but just a blank screen and no audio. I have the backend installed on a MyCloud PR-4100 and the system is using hardware transcoder and I have tried all the way from 1080p to 240p. Any ideas?

#18

Here is the log from my DVR attempting to stream a show.

2017/01/17 09:24:43 [HLS] Starting transcoder for file-5 at 5m0s
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: va_openDriver() returns 0
[mpegts @ 0x1cac760] PES packet size mismatch
[mpegts @ 0x1cac760] Dropped corrupted packet (stream = 1)
[mpegts @ 0x1cac760] PES packet size mismatch
[mpegts @ 0x1cac760] Dropped corrupted packet (stream = 2)
[mpegts @ 0x1cac760] PES packet size mismatch
[mpegts @ 0x1cac760] Dropped corrupted packet (stream = 2)
Unrepairable overflow!
2017/01/17 09:26:05 [HLS] Stopping transcoder session file-5
2017/01/17 09:26:05 [HLS] error during ffmpeg progress: unexpected EOF

#19

as mentioned above:

the machine shipped with 10.9, eyeTV worked, didn’t want to take the chance that an OS upgrade would bork it and “if it ain’t broke don’t fix it”.

at the time 10.10 came out there was no assurance that things would work. some of the astronomy software i used on the mac suffered mightily with the progression of the power saving stuff in OSX, so that was enough of an incentive to hold back.

sounds like i need to upgrade.

#20

The latest version has an option to use the software transcoder. Still highly recommend an upgrade so you can use the faster and more efficient hardware acceleration.