Jump to content

Last few seconds is being replayed


casperghst42

Recommended Posts

casperghst42

Hi,

 

When watching some media the appletv client is once in a while replaying the last few seconds. When I look at the server (lxc container) the utilisation is quite low, and it is using hw decoding....

 

Any idea where to look?

 

Cheers,

Casper

Link to comment
Share on other sites

Hi, this is a side-effect of a very specific situation.  We have worked around it to the point that it should be extremely rare.  I believe the best thing to do is to ensure that the media item is in a format that is directly playable by the device and it should avoid this situation.

Link to comment
Share on other sites

casperghst42

In my case it's not rare, it happens more or less constantly when I play media which has subtexts which are not supported by ffmpeg (ie. cannot do hw decoding):

 

General

Complete name                            : media-file.mkv
Format                                   : Matroska
Format version                           : Version 2
File size                                : 933 MiB
Duration                                 : 45 min 48 s
Overall bit rate                         : 2 846 kb/s
Writing application                      : x264.exe
Writing library                          : mkv2rls x264-tv version built on 2016.10.12
 
Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 45 min 48 s
Bit rate                                 : 2 405 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.109
Stream size                              : 788 MiB (85%)
Writing library                          : x264 core 148 r2744 b97ae06
Encoding settings                        : cabac=1 / ref=5 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.05:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=22 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.70
Language                                 : English
Default                                  : Yes
Forced                                   : No
 
Audio
ID                                       : 2
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Mode extension                           : CM (complete main)
Format settings, Endianness              : Big
Codec ID                                 : A_AC3
Duration                                 : 45 min 48 s
Bit rate mode                            : Constant
Bit rate                                 : 384 kb/s
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 kHz
Frame rate                               : 31.250 FPS (1536 spf)
Bit depth                                : 16 bits
Compression mode                         : Lossy
Stream size                              : 126 MiB (13%)
Language                                 : English
Default                                  : Yes
Forced                                   : No
 
Text
ID                                       : 3
Format                                   : UTF-8
Codec ID                                 : S_TEXT/UTF8
Codec ID/Info                            : UTF-8 Plain Text
Title                                    : English
Language                                 : English
Default                                  : No
Forced                                   : No
 
 
To follow your suggestion I'd have to re-encode lots of media to remove the subtitles ... 
 
Cheers,
Casper
Link to comment
Share on other sites

jscoys

I think it could be related to a bug I reported long time ago: Short jumps backward issue

https://r.tapatalk.com/shareLink?share_fid=77624&share_tid=51500&url=https%3A%2F%2Femby%2Emedia%2Fcommunity%2Findex%2Ephp%3F%2Ftopic%2F51500-Short-jumps-backward-issue&share_type=t and which is not resolved... please do something please I’m tired of the situation.

 

 

Sent from my iPad using Tapatalk

Link to comment
Share on other sites

casperghst42

I think it could be related to a bug I reported long time ago: Short jumps backward issue

https://r.tapatalk.com/shareLink?share_fid=77624&share_tid=51500&url=https%3A%2F%2Femby%2Emedia%2Fcommunity%2Findex%2Ephp%3F%2Ftopic%2F51500-Short-jumps-backward-issue&share_type=t and which is not resolved... please do something please I’m tired of the situation.

 

 

 

It does look to be the same problem. 

 

Could it be that the problem shows itself when the player switches between the decoded chunks.

Link to comment
Share on other sites

jscoys

I thought but I can’t correlate the decoded chunks and the moment it happens on the player...

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

casperghst42

I thought but I can’t correlate the decoded chunks and the moment it happens on the player..

 

 

Then we can only hope that they fix it, as re-encoding is not an option.

Link to comment
Share on other sites

casperghst42

 

What happens if you re-package one of those into an mp4?

 

 

 

It looks better, but it's difficult to say, as it happens randomly - meaning, it might happen, and when it happens it's randomly where it happens. And it might not happen.

Link to comment
Share on other sites

jscoys

 

What happens if you re-package one of those into an mp4?

Good lead ebr I really think there is something on Cooy streaming (extracting mp4 from mkv, that is to say “remux”).

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

ShoutingMan

I've experienced this with content on the AppleTV app, particularly trailers with Cinema mode was enabled, earlier this week. However, not with the movie. 

 

I've seen it once on Emby Theater for Windows playing a movie, fixed by quitting and restarting ET.

Link to comment
Share on other sites

jscoys

Don’t know if it’s related or not, but we’re experiencing problems on iOS devices: https://discussions.apple.com/thread/8082640?start=45&tstart=0

 

And it’s due to Apple when you try to stream a video from internet. If Emby app on Apple TV is using the default player from TvOS, it could be related.

 

 

Sent from my iPhone using Tapatalk

Link to comment
Share on other sites

casperghst42

I discovered that my hw encoding didn't work (used to work), then I got the static complied from this post:             #15             which then solved the hw encoding problem.

 

Since then I have not seen the problem, which makes me think that it could be a cpu utilisation problem, I have a G4600 which not fast, but it should be enough for a single 720p steam, but when the CPU is using 380% due to the fact that ffmpeg is using everything it can get is's hands on, then it more or less natural that something will stop working ... 

 

I'm still not sure that it was the hw encoding which caused the problem (high utilisation caused by ffmpeg), but it's a direction to look at ... 

  • Like 1
Link to comment
Share on other sites

casperghst42

I discovered that my hw encoding didn't work (used to work), then I got the static complied from this post:             #15             which then solved the hw encoding problem.

 

Since then I have not seen the problem, which makes me think that it could be a cpu utilisation problem, I have a G4600 which not fast, but it should be enough for a single 720p steam, but when the CPU is using 380% due to the fact that ffmpeg is using everything it can get is's hands on, then it more or less natural that something will stop working ... 

 

I'm still not sure that it was the hw encoding which caused the problem (high utilisation caused by ffmpeg), but it's a direction to look at ... 

 

 

And I was wrong, it wasn't hw encoding ... it happens even if it's only remuxing.

Link to comment
Share on other sites

Guys - as I mentioned above, I am 99% sure we know exactly what this issue is.  I appreciate all the continued effort to troubleshoot but we know about this situation.  Its just that it isn't something that can just be "fixed" but it is a fairly rare condition and won't always be a problem (exactly how you play the item, how much you seek and where you start from all affect the issue).  This is why you seem to be getting somewhat random results with it.

 

If you set your app settings such that a full transcode of the video results (e.g. lower the bitrate setting below the source) or repackage to a direct playable container, then I think you will no longer see this behavior.

Link to comment
Share on other sites

casperghst42

Guys - as I mentioned above, I am 99% sure we know exactly what this issue is.  I appreciate all the continued effort to troubleshoot but we know about this situation.  Its just that it isn't something that can just be "fixed" but it is a fairly rare condition and won't always be a problem (exactly how you play the item, how much you seek and where you start from all affect the issue).  This is why you seem to be getting somewhat random results with it.

 

If you set your app settings such that a full transcode of the video results (e.g. lower the bitrate setting below the source) or repackage to a direct playable container, then I think you will no longer see this behavior.

 

 

 

Are you by this, saying that you'll not be fixing this?

 

And by rare, well, for me it happens almost all the time .... it might not happen for a while, but it always return.

Link to comment
Share on other sites

Are you by this, saying that you'll not be fixing this?

 

And by rare, well, for me it happens almost all the time .... it might not happen for a while, but it always return.

 

As I said above, it isn't something that can just be "fixed" (other than forcing your item to transcode as I indicated above).  Your content must have the exact makeup of factors most likely to cause this issue and either transcoding it or repackaging it to a direct playable container on this platform should eliminate the problem until such time as we can find other workarounds.  We have made a number of changes along the way that have minimized its effect to the point where it is only seen by a very few people in certain circumstances.

 

It would be helpful if you could prove my hypothesis by either repackaging some of these problem items into an mp4 or forcing them to transcode and then seeing if the problem goes away.

 

Thanks.

Link to comment
Share on other sites

Also, when you see this problem, does the end of the video replay in a loop over and over or just replay once and then move on?

Link to comment
Share on other sites

Dibbes

Also, when you see this problem, does the end of the video replay in a loop over and over or just replay once and then move on?

 

It's played in a loop... when the episode is supposed to end, it goes back to a random point in time, starts playing from there until the end of the episode and then goes back again to another random point, sometimes earlier than the previous, sometimes later.

 

On the server side there is no entry regarding this in the server log and the Dash says the the ATV was last seen XX minutes ago.

Edited by Dibbes
Link to comment
Share on other sites

Can we get a sample of one of the problem files so we can examine it and see if anything can be done?

 

Thanks.

Link to comment
Share on other sites

Dibbes

Can we get a sample of one of the problem files so we can examine it and see if anything can be done?

 

Thanks.

 

Sure, where do you want it?

Link to comment
Share on other sites

casperghst42

Also, when you see this problem, does the end of the video replay in a loop over and over or just replay once and then move on?

 

 

For me it does end (and play next episode if there is one).

 

I am currently not able to duplicate it, which is after I fixed hw encoding, forcing the app to do 40mb/s and moved the transcoding temp path to and ssd raid0 .... 

 

But if I run in to it again, I'll make the media available.

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
×
×
  • Create New...