Expected transcoding performance?

Pretty sure 10.10 will work.

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

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!

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?

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?

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

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.

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.

thanks!! i will give it a try before upgrading the OS. still dragging my feet…

the software encoder works great; it’s doing about 1.67x real time on 1080i->720p. thanks for adding that, it will buy me some time and enable my luddite tendencies.

as an aside, what’s the right way to upgrade the server? i could see that latest@ was already pointing to a new build but the server was still reporting the old version, saying it was waiting to upgrade (for several hours). i did killall channels-dvr and manually restarted it but i guess there might be a launchd rule as another copy spawned a couple of seconds later. so i killed the one i started; everything seems fine.

rob

The sever waits until “Activity: Idle” to restart. There might be a bug that causes it not to in certain cases, as I have heard some reports.

There is a launchd service in place, so killing it should be enough to get it to respawn.

ah - yeah it was showing the status “downloading guide data” for most of the morning, which i assume is probably not really what it was doing for several hours.

rob

You can check the log tab to see what it was doing… possible it was downloading guide data. There was a bug that could have caused it to download guide data multiple times this morning.

hmm, hard to say if there’s anything unusual there, except for apparent DNS resolution failure when trying to fetch latest.json overnight and this morning. this could have been due to an internet outage on my end though.

rob

hi, found this thread searching for why ffmpeg on my mac mini is taking up 250% of my cpu%. I’ve checked all the bandwidth using the speedtests recommended to me on both locations. When I try to remote stream it works for about 20 mins and then it stops…no matter how low i drop the quality. When i check the activity monitor at the home base the ffmpeg flys to the top when trying to play and at an astronomical 250%+ . I’m guessing this is what is not allowing the stream to actually play. Evne when it plays it last for 2-3 seconds stops, then starts again. What is happening?

Do you have hardware transcoding enabled on your Mac?

[quote="tmm1, post:6, topic:930, full:true"]

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

So if I have TeamViewer running on my iMac, will that impact Channels performance?

Yes, pretty sure I do. On the my.channelsdvr.net setting page its set to Hardware - 2mbps - blend. Is there another place I should check?

That looks fine. I suggest you run a HWE test as described in VTEncoderXPCService CPU Usage and then open a new thread with the results.

Using hardware encoding on 2012 Mac mini with Ivy Bridge quad core i7, is there a way to increase the number of threads dedicated to ffmpeg like we can with comskip?

2020/10/13 22:34:10.906477 [HWE] Trying h264_videotoolbox: /Users/name/Library/Application Support/ChannelsDVR/latest/ffmpeg /Users/name/Library/Application Support/ChannelsDVR/latest/ffmpeg -hide_banner -nostats -loglevel warning -loglevel verbose -f lavfi -t 0.1 -i color=black:640x480 -c:v h264_videotoolbox -profile:v high -level 4.2 -realtime 1 -f null -y /dev/null
2020/10/13 22:34:11.117198 HWE] Successfully encoded using h264_videotoolbox