Jump to content

Problem since recent server updates


bazzabent
 Share

Go to solution Solved by arecad98,

Recommended Posts

bazzabent

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

Link to comment
Share on other sites

bazzabent

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.

Link to comment
Share on other sites

bazzabent

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

 

 

Link to comment
Share on other sites

bazzabent

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.

 

post-52256-0-02285300-1506155302_thumb.png

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Waldonnis

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)?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

bazzabent

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 :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

bazzabent

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

bazzabent

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by arecad98
Link to comment
Share on other sites

Waldonnis

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...