Problem since recent server updates

[bazzabent 0]

Hello, when trying to play x265 files, the video will freeze but the audio continues and then the video will skip forward and continue for a while then do the same again. It has only started doing this recently so not sure what the problem might be. If I try to skip forwad or back, the video goes back to the beginning and starts again. I've attached the server log in the hopes that someone can pinpoint the possible problem

 

server-63641700362.txt

[ebr 15245]

Were any ffmpeg logs created?

[bazzabent 0]

Here you go

 

ffmpeg-transcode-cf2e7e8c-d1a1-463e-88ab-b065cb403ef9.txt

[ebr 15245]

Has your device updated to tvOS 11 yet?

[bazzabent 0]

Yes, it has. I’m busy doing a reset and update just to make sure it’s not something I did with settings and such. I’ll then reinstall emby and see what gives.

[ebr 15245]

If you enabled hardware acceleration, try disabling it.

[bazzabent 0]

I reset and updated Apple TV, reinstalled Emby app v1.0.20, uninstalled Emby server on pc and reinstalled it v3.2.32.0. No plugins added. no tweaking with settings. Tested file again and got the same results. I'm at a loss. Hardware acceleration not enabled. Files play perfect on ipad though.

 

ffmpeg-transcode-ade5908a-417d-4214-b262-92bc4d24c600.txt

server-63641749921.txt

 

 

[Luke 38157]

Can you provide a sample video for testing? thanks !

[bazzabent 0]

Not sure how to do that other than upload a full episode. Here are the file stats if that helps any. I'm guessing it's a transcoding issue of some sort. I'll have to just try different settings and files and see what results I get and hope that I find a solution.

 

[ebr 15245]

Can you join the beta for the Apple TV app and try that?  tvOS 11 has support for hevc natively and the beta of the app understands that so it would probably get around the problem entirely by not having to transcode it.

 

If you are willing to try it, PM me your Apple ID.  Thanks.

[Luke 38157]

@@Waldonnis, hopefully this isn't due to the keyframe change or that may have to be rolled back.

[Waldonnis 148]

I'm working with spotty power and internet (I live where Irma first hit mainland Florida  ), but I'll take a look at the logs.  

[Waldonnis 148]

I'm not seeing anything in the transcode log that would imply that kind of playback behaviour.  I even ran a few more tests with the older keyframe generation expression vs. the new one and haven't seen any significant difference in keyframe generation, so it shouldn't be forcing more than is needed.  I'd really have to look at the source file and know more about the limitations of the player/playback device, though, before I can draw any real conclusions transcoding-wise (guessing this was an Apple TV unit).  Also, the source appears to be a web stream  capture that's been re-encoded (with no encoder metadata to refer to), so upstream segmentation may be complicating things (they too would force keyframes).

 

That aside, is there any indication that keyframe generation is really causing this?  I noticed some slow responses in the server log as well, but haven't looked too closely at that log yet to see if it may be related.  Is there an app log available (and would it show any more info about what's going on on the playback side)?

[Luke 38157]

That aside, is there any indication that keyframe generation is really causing this?  I noticed some slow responses in the server log as well, but haven't looked too closely at that log yet to see if it may be related.  Is there an app log available (and would it show any more info about what's going on on the playback side)?

 

No indication right how, it was just a hunch on my part.

[Luke 38157]

@@bazzabent, is it possible to put a sample video on something like dropbox? We'd really like to test it. Thanks !

[bazzabent 0]

Here is a link to the file https://www.dropbox.com/s/7ygnycaj5psb5fk/Gotham.S03E11.Mad.City.Beware.the.Green-Eyed.Monster.720p.WEB-DL.2CH.x265.HEVC-PSA.rar?dl=0

 

Thanks for looking into this as I really was enjoying emby.

[bazzabent 0]

Can you join the beta for the Apple TV app and try that?  tvOS 11 has support for hevc natively and the beta of the app understands that so it would probably get around the problem entirely by not having to transcode it.

 

If you are willing to try it, PM me your Apple ID.  Thanks.

I was using the beta but thought maybe that was the problem. I will try it again and see if it solves the issue. Thanks

[Luke 38157]

Is your ipad on ios11?

[Luke 38157]

Also is this the full original file, or did you cut or re-encode a sample? Just asking because sometimes when you do that, the problem will not occur in the sample. thanks.

[bazzabent 0]

Is your ipad on ios11?

 

Hi Luke, yes it is, so is my Apple tv

 

Also is this the full original file, or did you cut or re-encode a sample? Just asking because sometimes when you do that, the problem will not occur in the sample. thanks.

 

Yes, this is the full original file as I downloaded it.

[ebr 15245]

How long does it take for the problem to occur?

 

I have been playing your sample for five minutes with no issues.  Seeking also works fine.

 

I am on the beta though.

[bazzabent 0]

Probably about 30 seconds in it starts and continues on and off throughout. It must be something I've done, I just can't figure out what. I will try the beta again tonight and see. It's only when emby needs to transcode that the problem occurs. Question, is the file you are using playing without any transcoding?

[ebr 15245]

It was transcoding.  There is some question whether or not that should be required (seems like a remux would have sufficed) but, in my test, it was doing a full transcode from hevc to h264.

[arecad98 5]

Not sure if it's related but on latest version of server and beta version of non 4k Apple TV. I have a show completely encoded in HEVC and after I updated to TVOS11, whether related or not (as it could also be latest server which I updated at the same time) - I get this error when playing "This content cannot be played because its format is not compatible with Apple TV" - It used to transcode this show.

 

Video specs:

Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main@L3.1@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Duration : 43 min 42 s Bit rate : 416 kb/s Width : 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.019 Stream size : 130 MiB (75%) Writing library : x265 1.8+1-5dcc9d3a928c400b:[Windows][GCC 5.2.0][64 bit] 8bit Encoding settings : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=0 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=0 / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.30 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / rc=abr / bitrate=432 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30 Language : English Menus : 3

 

Audio

Audio ID : 2 Format : AAC Format/Info : Advanced Audio Codec Format profile : LC Codec ID : 40 Duration : 43 min 43 s Bit rate mode : Constant Bit rate : 128 kb/s Channel(s) : 2 channels Channel positions : Front: L R Sampling rate : 48.0 kHz Frame rate : 46.875 FPS (1024 spf) Compression mode : Lossy Stream size : 40.2 MiB (23%) Language : English Default : Yes Alternate group : 1 Menus : 3 Edited September 24, 2017 by arecad98

[Waldonnis 148]

Just ran some tests with the original file (thanks for providing that).  Using the new keyframe expression increased the keyframe total by 22 compared to the older expression (keyframe count was 1517 vs 1495; original file contained 847 keyframes; total frame count: ~63307), so I'm doubtful that it's the forced keyframes making the difference.  Since it's an Apple TV unit, I'm even more doubtful since the last time I looked they were recommending an even shorter keyframe interval (every 2secs for HLS) which would result in a higher keyframe count and at a greater frequency.  Looking at the transcoded segments, I don't see anything unusual at first glance.  Segment duration is predictably ~3secs and there's no indication of the same problems we were seeing with the old expression (caveat: those issues were only seen after seeking, which I'm not doing in this case since the transcode log provided didn't do it either).  Each segment begins with a keyframe as expected, and no unusual IDR (or non-) frames aside from the expected scenecut keyframes.