Playback issue with 3.1.2, and FireTV

[MSattler 390]

So ran into an issue with playback on a FireTV  and Android TV using a MiBox, using Stable 3.1.2 using hardware acceleration.  If I turned off hardware acceleration then it worked fine.

 

Rolled back to 3.1.1.0 and playback worked again with and without hardware acceleration.  So this issue only comes up with 3.1.2, no other changes have been made.

 

 

I can provide both the current server log where it works, and the previous one where it didn't.

 

It seems the 3.1.1.0 ffmpeg call has this "-b:v 9872000 "    which 3.1.2 does not have.  With 3.1.1.0 even with a higher bitrate setting it still works better, and no pixelation.

 

3.1.1.0 - Worked (with Hardware Transcoding)

 

 

B:\Users\Administrator\AppData\Roaming\Emby-Server\ffmpeg\20160410\ffmpeg.exe -fflags +genpts -c:v h264_qsv  -i file:"\\tower2\bluray\The Accountant\The_Accountant.mkv" -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_qsv -force_key_frames "expr:gte(t,n_forced*5)" -copyts -avoid_negative_ts disabled -start_at_zero -preset 7 -look_ahead 0 -b:v 9872000 -maxrate 9872000 -bufsize 19744000 -vsync -1 -profile:v high -level 4.1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 aac -strict experimental -ac 2 -ab 128000 -af "aresample=async=1,volume=2" -y "B:\Users\Administrator\AppData\Roaming\Emby-Server\transcoding-temp\transcoding-temp\7dc14ef6ae14340cb3cddb8b48b42a7d.mkv"

 

 

 

3.1.2 - Did not work (with Hardware Transcoding)

 

B:\Users\Administrator\AppData\Roaming\Emby-Server\ffmpeg\20160410\ffmpeg.exe -fflags +genpts -c:v h264_qsv -i file:"\\tower2\bluray\The Accountant\The_Accountant.mkv" -map 0:0 -map 0:1 -map -0:s -codec:v:0 h264_qsv -force_key_frames "expr:gte(t,n_forced*5)" -copyts -avoid_negative_ts disabled -start_at_zero -preset 7 -look_ahead 0 -maxrate 4808000 -bufsize 9616000 -vsync -1 -profile:v high -level 4.1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 aac -strict experimental -ac 6 -ab 192000 -af "aresample=async=1" -y "B:\Users\Administrator\AppData\Roaming\Emby-Server\transcoding-temp\transcoding-temp\eb758b1bb2da472c2b931e5e7ed25a9e.mkv"

 

3.1.2 - Did work (without Hardware Transcoding)

 

B:\Users\Administrator\AppData\Roaming\Emby-Server\ffmpeg\20160410\ffmpeg.exe -fflags +genpts -i file:"\\tower2\bluray\The Accountant\The_Accountant.mkv" -map 0:0 -map 0:1 -map -0:s -codec:v:0 libx264 -force_key_frames "expr:gte(t,n_forced*5)" -copyts -avoid_negative_ts disabled -start_at_zero -pix_fmt yuv420p -preset superfast -crf 23 -tune zerolatency -maxrate 4808000 -bufsize 9616000 -vsync -1 -profile:v high -level 4.1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 aac -strict experimental -ac 6 -ab 192000 -af "aresample=async=1" -y "B:\Users\Administrator\AppData\Roaming\Emby-Server\transcoding-temp\transcoding-temp\9296607343f69e5f2d57cfd8feb877e9.mkv"

 

 

I'll upload logs in a few minutes.

 

 

*EDIT* Was able to replicate this on a MiBox as well.

Edited January 2, 2017 by MSattler

[MSattler 390]

On 3.1.1.0 - ffmpeg-transcode-2ff51781-6a97-4135-8911-4308932b5b9a
 
On 3.1.2 - ffmpeg-transcode-dfc51079-7857-46eb-92a8-694960bf39f7

 

Server log ending in 7592 should be for 3.1.1.0, and the other for 3.1.2.

 

 

Just to recap:

 

3.1.2:  Hardware transcoding on, QuickSync, causes Pixelation on both a FireTV, and a MiBox.  Changing resolution to 4Mbps results in pixelation, same as with 10Mbps.  Turning off hardware transcoding fixes the pixelation issue.

 

3.1.1.0:  Hardware transcoding on, no pixelation on both a FireTV and a Mibox.

 

Both of these were tested remotely.  Local playback seems to not suffer this issue, it only happened when transcoding was required.

 

 

Thanks,

Marcus

 

 

 

ffmpeg-transcode-2ff51781-6a97-4135-8911-4308932b5b9a.txt

ffmpeg-transcode-dfc51079-7857-46eb-92a8-694960bf39f7.txt

server-63618957592.txt

server-63618912000.txt

[MSattler 390]

@@Luke @@ebr

 

Let me know if you see anything.

 

Thanks!

[Luke 42078]

Thanks. We will add that param back when not using libx264.

[MSattler 390]

Thanks. We will add that param back when not using libx264.

Do you believe that caused the pixelation?

[Luke 42078]

Probably. Removing the b:v gives it a better chance of staying under the max requested bitrate, whereas having b:v will increase the chances of sometimes exceeding it. It was removed to prevent exceeding the max requested bitrate which may cause too high of a bitrate to be sent back to mobile devices. However, since I'm not quite as familiar with the nuances of the various gpu encoders as I am with libx264, I will just restore it back to those for now. Ultimately it will probably need to be removed again, unless we find that those encoders do not generally overshoot the maxrate.

[Luke 42078]

You could also try dropping the crf value in transcoding settings. that might be a better answer than adding back the b:v. So for example, the default is 23 so you could 19 or 15.

[MSattler 390]

You could also try dropping the crf value in transcoding settings. that might be a better answer than adding back the b:v. So for example, the default is 23 so you could 19 or 15.

 

I could, but this issue only effected the Android TV/Fire TV clients.  IOS clients, and regular android client, web browsers all still played back the content find.  I actually had it at 25, and tried dropping it to 23 and it still did not help.

 

I don't really like the thought of dropping the quality for everyone.

 

How are you figuring out if the maxrate is being overshot?  I use QuickSync multiple times a day for transcoding within Emby.  It wouldn't be hard for me to check, and I could potentially script something to check for that condition if you can tell me what I am looking for.

 

Thanks!

[Luke 42078]

Yea you can just look at the segment files that get created in the transcode temp folder.

[MSattler 390]

Yea you can just look at the segment files that get created in the transcode temp folder.

 

And just see what the bit rate is for each of the recordings right?  Is there any variance, or should it just never be above the requested max bitrate?

[Luke 42078]

transcoding to android is using progressive techniques to convert to either .ts or .mkv, there's no real concern of overshooting the bitrate. the concern is mostly for apps that use HLS, which is the format where we split it into lots of little segments. Yes it can overshoot the bitrate with b:v. The web browsers use HLS as well as apple, roku and most of the smart tv's.

[pappaq 8]

I've got the exact problem as MSattler. How do I roll back to 3.1.1?

 

EDIT: Found it by myself.

Edited January 3, 2017 by pappaq

[MSattler 390]

@@Luke,

 

Should I expect the fix for this in 3.1.3?  Or a beta version?

 

 

Just trying to figure out where I'll be able to find the fix.

 

Thanks!

[moviefan 187]

I don't really like the thought of dropping the quality for everyone.

 

Just FYI, lowering the CRF value increases the quality versus degrading it.

[MSattler 390]

Just FYI, lowering the CRF value increases the quality versus degrading it.

 

Hmmm wouldn't that just increase the size of the file and increase throughput?

[Waldonnis 148]

How are you figuring out if the maxrate is being overshot?  I use QuickSync multiple times a day for transcoding within Emby.  It wouldn't be hard for me to check, and I could potentially script something to check for that condition if you can tell me what I am looking for.

 

I don't think it's 100% possible for ffmpeg to do "true" CBR encodes outside of 2-pass (at least not with libx264 without using some tricks; not sure about QSV's CBR options as I haven't tried them before).  IIRC with libx264, the maxrate is just a maximum average bitrate for a segment that fits in the target buffer rather than a hard maximum bitrate across the whole file.  This can probably be tricked by setting the buffer size to insanely low or high values, but that's probably not a good idea and I've never personally tried it.

 

You can try playing with the buffer size, but bitrate spikes will probably still happen.  In theory, it shouldn't be a big deal since it's not sustained and you're still buffering anyway, but could be an issue if you're target bitrate is very close to your bandwidth limit or the bitrate spikes for a more sustained period with the device playing back faster than it can fill the buffer.

 

Hmmm wouldn't that just increase the size of the file and increase throughput?

File size/bitrate increase for sure.  Just how much both increase is dependent on the setting, though (it's not linear).

Edited January 3, 2017 by Waldonnis

[Luke 42078]

Please try my suggestion of lowering crf, because if later we find that the qsv encoder tends to overshoot the bitrate, then we ultimately will have to keep it the way it is in 3.1.2. Thanks.

[moviefan 187]

Hmmm wouldn't that just increase the size of the file and increase throughput?

 

In general, with ffmpeg, lowering the CRF value will lead to higher bitrates which will mean file size and required throughput necessary to transmit would go up.

 

I'm not sure how it works when combining both the CRF value and the "internet streaming bitrate limit" impact each other however along with some of the auto bandwidth detection I know is going on behind the scenes to determine the final playback settings however.  Have always wondered about that aspect.

[MSattler 390]

Please try my suggestion of lowering crf, because if later we find that the qsv encoder tends to overshoot the bitrate, then we ultimately will have to keep it the way it is in 3.1.2. Thanks.

 

I don't get this, you want me to lower the crf, which will increase quality and size...... wouldn't that just create more of a chance of exceeding the bit rate?

[Luke 42078]

Probably not to the same degree as using the b:v param though.

[Luke 42078]

Actually nevermind, sorry. We are only using the CRF value with libx264. Ok so for now I will just add b:v back for gpu encoders for the next release. We'll revisit bitrate fluctuation with them later. Thanks.

[MSattler 390]

If I have time this week I'll setup a Dev install and will attempt to test it.

 

Not gonna put in on my prod server.

[MSattler 390]

Actually nevermind, sorry. We are only using the CRF value with libx264. Ok so for now I will just add b:v back for gpu encoders for the next release. We'll revisit bitrate fluctuation with them later. Thanks.

 

Thanks Luke!

 

Is it possible to do more of a deep dive how all the transcoding works within Emby?  By the response on this thread there is a ton of knowledge here, and it may make sense to lay out how it works, so that the folks with ffmpeg experience can perhaps guide us in the right direction.

 

Also, since we are not using the CRF value with anything but libx264, can we document that in the GUI?

 

Let me know what build fixes this, as I am dying with the volley timeouts in 3.1.1.

 

Thanks! 

Edited January 3, 2017 by MSattler

[Kipperdawn 5]

Hi Everyone,

 

I am new to this and Emby but just wanted to add that I too have the same problem. For me it is with chromecast, which I use for my tvs. With 3.1.2 the video was terrible. Hard to explain but looked very pixelated and like frames of data were being left in the buffer from previous display. If I displayed the same file on the browser it looked fine. I rolled back to 3.1.1 and if is fine.

 

For me, I am using quick sync and a transcode crf of 15. I would not want to go back to sw decode because the performance difference is huge.

 

Just wanted to share so we don't think it is an isolated situation.

 

Thx

[MSattler 390]

I think its been proven to be an issue. It appears to be fixed in the latest beta.