Comments on transcoding

[ShoutingMan 95]

(I'd somewhat highjacked someone else's thread on transcoding. I'll leave theirs be and start this new one.)

 

I had confusing experiences with Emby's transcoding. I did some intentional tests and better understand what's happening. These aren't bug reports. But I'm looking for more insights on how to best use Emby and ideally be able to live transcode content instead of having duplicate pre-transcoded copies.

 

My system:

 

Emby Premiere (3.2.9.0 during testing)

ffmpeg is March 10, 2016 (I think) (installed by Emby into the Emby folders, I believe)

 

Skylake i5 3.2 GHz (6th Gen 6500)

Intel Graphics HD 530

Windows 10

Connected by 100Mbps switch to 1Gpbs LAN

Testing by streaming to a 4th Gen AppleTV connected to the same 100Mbps switch running tvOS Emby

 

[ShoutingMan 95]

Pre-transcoding works great (at the expense of time to manually transcode, build a new library branch, and extra space on my RAID.)

 

Content, both DVD and Blu-ray source, that I pre-transcoded using Handbrake streams fine. I don't have the Handbrake preset handy; I customized a 1080p60 5.1 AppleTV preset with QSV. CRF was 22 I think. It preserves discrete surround, 1080p HD, subtitles, and uses QSV to cut encoding time by ~75%.

 

Player transport controls all work smoothly and without problem: play/pause, forward, reverse, and thumbnails during paused-seek.

I can jump from the beginning to the middle and back to the beginning of the show.

There is minimal processing on the AppleTV to jump around (a second or less).

I've not seen any stops, failures, or crashes of playback using pre-transcoded shows.

[ShoutingMan 95]

One surprise: transcoding HD content is faster than SD content.

 

Using Emby default transcoding parameter, including GPU acceleration off:

MPEG (SD DVD) content uses up to 25% of my i5, which I think corresponds to 100% of one core utilized.

H264 (HD Blu) content uses up to about 35% of my i5, so it seems note quite 2 cores get fully used.

 

Using Emby default transcoding parameter, but with Intel Quick Sync enabled:

Similar CPU utilization, perhaps lower on the H264 input

 

 

I can watch in the Emby Dashboard the show being transcoded ahead of playback.

In both cases, transcoding is faster than real-time.

For a DVD input with QSV enabled it takes about 5-10 min to transcode a 45 min episode.

For Blu input with QSV enabled it takes 1-3 min to transcode a 45 min episode.

Edited April 1, 2017 by ShoutingMan

[ShoutingMan 95]

Playback during real-time transcoding is quirky.

 

Straight playback without any pausing and forward/reverse seems to work fine for both SD and HD content during real-time transcoding.*

 

Player transport controls though are a bit wonky. If I pause and jump forward (but within the duration already transcoded) It may or may not go forward. And if it does, it very likely resets that new point as the 0:00 start of the show and I can't go reverse. Or maybe I can go backwards but not back to the start of the show.

 

Sometimes, if I jump forward a large amount, the show will pause and then freeze in place. I have to completely exit playback and retry.

 

If I start a show and then pause for a few minutes to let real-time transcoding complete, then playback player transports tend to work more smoothly and consistently. But they're not as smooth and fast as using pre-transcoded content (done with Handbrake AppleTV-target presets). And even then, jumping around in the show can cause playback to freeze and require a complete restart (and new transcoding).

[ShoutingMan 95]

In summary: Real-time transcoding with QSV of full bitrate SD and HD MKV files for streaming to an AppleTV works. Linear playback without play/pause/forward/reverse in limited testing works well, with the exception of "Firefly".

 

Playback controls are quirky. They mostly work, but can cause the streaming to freeze and require a restart.

 

They seem to be more stable if the transcoding has completed before they're used.

 

Transcoding HD is faster than SD, in my limited trials.

[Luke 36999]

Thanks for the feedback !