Stuttering after pause

[user84 54]

41 minutes ago, speechles said:

That is the problem. I knew it when you said you had that stuttering issue. I went man, I wonder if this is those RARBG encodes that do not follow standards? Low and behold it is. This release group does not follow standards required for streaming playback. They encode as if you have the entire file on your hard drive and are playing with something that can load the entire file at once. They put chapters at the end, use lots of embedded tags, and other nonsense. My advice is run anything from RARBG through MKVToolNix GUI and correct these at that point. Then these will play correctly. Are all the others you have issues with also from RARBG?

 

 

 

I haven't checked any of my own personal rips, but I can try to do that at some point.

@speechles The file in question is already an MKV. How would MKVtoolnix fix this?

Edited October 9 by user84

[speechles 2125]

21 minutes ago, user84 said:

@speechles The file in question is already an MKV. How would MKVtoolnix fix this?

Magic? Maybe?

No. Not magic. What it will do is correct some of the problems most encodings have without informing you its done anything other than remuxing. The main thing is it will build the file so it is optimized for streaming. You can then try both on your Roku and see if the optimized file behaves differently than the unoptimized.

The issue is the people who encode for RARBG are not subject to "scene rules" since they are just a P2P group. The "scene rules" would force them to use the correct parameters or risk nuke. RARBG fear no nuke. They just release things without double checking anything. Because of this sometimes their releases are not universally built for all streaming devices. They are not optimized for streaming on Roku, and possibly iOS since Roku follows iOS standards. Sometimes P2P is just as good as scene releases. Sometimes it isn't. In this case it isn't.

Edited October 9 by speechles

[ebr 16937]

1 hour ago, user84 said:

Just so I understand... Firestick can directplay this, Roku can't, and Emby settings have nothing to do with this. Is this correct?

Yes, as I mentioned, it has a multi-channel AAC track.  The Roku cannot handle that.  The Fire can - sort of - it mixes it down automatically.

And, as Speechles has found, the issue is most likely the encode.  As I also said before, the Roku player is VERY intolerant of anything out of spec.

[user84 54]

33 minutes ago, speechles said:

Magic? Maybe?

No. Not magic. What it will do is correct some of the problems most encodings have without informing you its done anything other than remuxing. The main thing is it will build the file so it is optimized for streaming. You can then try both on your Roku and see if the optimized file behaves differently than the unoptimized.

The issue is the people who encode for RARBG are not subject to "scene rules" since they are just a P2P group. The "scene rules" would force them to use the correct parameters or risk nuke. RARBG fear no nuke. They just release things without double checking anything. Because of this sometimes their releases are not universally built for all streaming devices. They are not optimized for streaming on Roku, and possibly iOS since Roku follows iOS standards. Sometimes P2P is just as good as scene releases. Sometimes it isn't. In this case it isn't.

This is super helpful. I really appreciate it. I'm no expert in these things. 

So are you suggesting I literally just use MKVtoolnix to create a new MKV and see if it still stutters? No changes other than creating a new MKV?

Edited October 9 by user84

[speechles 2125]

21 minutes ago, user84 said:

This is super helpful. I really appreciate it. I'm no expert in these things. 

So are you suggesting I literally just use MKVtoolnix to create a new MKV and see if it still stutters? No changes other than creating a new MKV?

Yes. Just drag the file onto MKVToolNix GUI. Then start remux. The optimized file should then play without that stuttering. The Emby server will still need to convert the AAC 5.1 to 2.0 because the Roku doesn't natively support AAC 5.1 output unless it is a Roku TV model. If this is a stick or set top box Roku it will transcode AAC 5.1, but the video should direct play. The stuttering you noticed before should now be resolved. The optimized file is a 1:1 copy of the unoptimized files video/audio/subtitle data. The only differences are the header data controlling how the file is delivered.

You are safe to delete the unoptimized copy after you convert it since it is the same data. There would be no need to save it unless you are seeding. That is why these legacy files remain available to find even though they are poor copies. Legacy data kept for seeding/sharing with a common crc/hash. Someone somewhere made this so someone somewhere preserved it for us all on the internet kind of thing.

Edited October 9 by speechles

[user84 54]

3 minutes ago, speechles said:

Yes. Just drag the file onto MKVToolNix GUI. Then start remux. The optimized file should then play without that stuttering. The Roku will still need to convert the AAC 5.1 to 2.0 because the Roku doesn't natively support AAC 5.1 output unless it is a Roku TV model. If this is a stick or set top box Roku it will transcode AAC 5.1, but the video should direct play. The stuttering you noticed before should now be resolved. The optimized file is a 1:1 copy of the unoptimized files video/audio/subtitle data. The only differences are the header data controlling how the file is delivered.

You are safe to delete the unoptimized copy after you convert it since it is the same data. There would be no need to save it unless you are seeding. That is why these legacy files remain available to find even though they are poor copies. Legacy data kept for seeding/sharing with a common crc/hash. Someone somewhere made this so someone somewhere preserved it for us all on the internet kind of thing.

Thanks, speechles. I opened the Say Anything file in MKVToolNix and it has just two tracks (HEVC video and 6-channel AAC), with no chapters, no tags, and no attachments. And it's already an MKV file.  So I’m not seeing the clutter you described, and the 5.1 AAC track is what’s forcing the remux. You still think it's the container?

Edited October 9 by user84

[speechles 2125]

Indeed. I still think if it stutters with playback it hasn't been run through MKVToolNix and somebody just renamed it MKV from MP4 or something.

[user84 54]

19 minutes ago, speechles said:

Indeed. I still think if it stutters with playback it hasn't been run through MKVToolNix and somebody just renamed it MKV from MP4 or something.

MKVToolNix lists the container as Matroska

[Neminem 1957]

Try if it's not working, ohh well.

Delete the new file

A remux take a 1 min. 

Edited October 9 by Neminem

[user84 54]

2 minutes ago, Neminem said:

Try if it's not working, ohh well.

Delete the new file

A remux take a 1 min. 

I don't disagree, but testing this is pretty annoying. It's not a consistent thing that's easy to repeat. So it basically just means I sit down and watch the same movie over and over again, pausing, and trying to recreate the issue. I just want to make sure I'm not wasting my time.

[ebr 16937]

I would play the movie for five minutes and then pause for at least five minutes.  Then resume and see if there is a difference.

Thanks.

[user84 54]

10 minutes ago, ebr said:

I would play the movie for five minutes and then pause for at least five minutes.  Then resume and see if there is a difference.

Thanks.

Ok! So here is what I did. Reminder: I am an amateur so I am sure I will butcher the language here.

1. I used ffmpeg to copy the video, make 5.1 AC3 track 1 default, and 5.1 AAC as track 2
2. I played the file with AC3 and it direct played and had no issues no matter how many times I played or paused.
3. I switched to 5.1 AAC audio and paused and played several times for different amounts of time. The movie stuttered at 2:20 slightly and then did typical behavior at 2:23. At 2:23, it skipped back a second or two and was out of sync for a second.

Log is attached. This doesn't seem to me to be a container or RARBG issue as  @speechlessuggested, though as I said, I am a novice. It definitely seems related to transcoding.
 

What's next?

ffmpeg-remux-463b8f97-53b0-49fb-85d3-51ad4eea0047_1.txt

[ebr 16937]

Did you do a remux on the file in MKVToolNix?

[user84 54]

1 minute ago, ebr said:

Did you do a remux on the file in MKVToolNix?

No I did not. Intentionally.

[ebr 16937]

Just now, user84 said:

No I did not. Intentionally.

That is the process that can fix-up header and meta information that the Roku may not like.  It may or may not be your actual problem here but doing that can eliminate that as a possiblity.

[speechles 2125]

20 minutes ago, user84 said:

No I did not. Intentionally.

Quote

14:21:08.197 [segment @ 00000252efc7eac0] Invalid DTS: 183127230 PTS: 183123450 in output stream 0:0, replacing by guess
14:21:08.197 [segment @ 00000252efc7eac0] Non-monotonous DTS in output stream 0:0; previous: 183123541, current: 183115980; changing to 183123542. This may result in incorrect timestamps in the output file.
14:21:08.197 [segment @ 00000252efc7eac0] Non-monotonous DTS in output stream 0:0; previous: 183123542, current: 183119760; changing to 183123543. This may result in incorrect timestamps in the output file.
14:21:08.198 [segment @ 00000252efc7eac0] Non-monotonous DTS in output stream 0:0; previous: 183123543, current: 183123450; changing to 183123544. This may result in incorrect timestamps in the output file.

Then you didn't correct the timestamps and this results in replacement by guessing. Use MKVToolNix and create an optimized file. That will fix and align timestamps among other issues.

Use the optimized file in Emby. Are your problems solved are that?

If yes, the issue was the header of the MKV. Which is the same issue that release group had with MP4. To remux with MKVToolNix it takes literally a minute, tops. Then out pops the corrected file. Then that file is now universal. It works on anything since it now follows known standards which the other MKV did not. That is the reason you need to convert it.

If no, we have to continue this thread. We are doing something wrong if the file isn't built wrong.

Also, very important, you then place that AC3 file you created earlier with ffmpeg into the MKV with your optimized file. MKVTookNix will let you extract the audio stream from one. Then you can pack it into the fully optimized file with the original AAC 5.1 stream. Having both AAC and AC3 available will allow you to direct play entirely. The AAC 5.1 is being coverted to AC3 in your ffmpeg log. You then could even create an AAC 2.0 file in stereo to include. So 3 audio tracks. Then it is universal across phones/tablets too rather than just TV devices to direct play.

Edited October 9 by speechles

[user84 54]

Steps I just now followed:

1. Took original MKV file that wasn't altered using ffmpeg and ran it through mkvtoolnix. Resulting file is the same with only AAC
2. Play at 3:00 - it does not direct play.
3. Pause at 3:02
4. Play at 3:04
5. Stutter between 3:04 and 3:05

What's next? @speechles@ebr

 

 

ffmpeg-remux-0d560086-a5e0-435a-9af2-899b4d28fbfc_1.txt ffmpeg-remux-6ce2cae9-b1b2-4dd0-ae1b-67cdbdd5845a_1.txt

Edited October 9 by user84

[speechles 2125]

hmm. Blame the encoding again. Does it switch to automatic playback recovery at that point and create an ffmpeg-transcode log? Or afterwards with that stutter does it stay as ffmpeg-remux? That is why I still blame the encoding. If it isn't forcing a playback method change. That means it isn't an error causing the Roku nor ffmpeg to abort they just cruise through it. It is something _in_ the video the stream itself is encoded. Some B-frame not done correctly where its part of the video stream now. Bad timestamps inside the video stream. There is no way to fix it without reobtain their same exact source material and encode it correctly. This issue should expose itself in the ffmpeg data log somewhere too, but I do not see it. Other than those guessed frames which could be it. 

If it plays correctly on other devices it must do that same hiccup at that same spot there. Those other devices are just more adept at how they handle the interruption.

If you are saying all other devices play it perfectly just the Roku is being a dork, then we might need a sample. The full sample. A partial sample may not give the same issue. The full file. It is okay to share in this instance because this is to better the app for educational and such reason. You can share via dropbox, or google drive, or anything you want to share with either myself or @ebr. Make sure to send the link to the file in private message. Once we can duplicate your issue which should then be possible we can get the right people involved and make this move much faster. Thanks.

Edited October 9 by speechles

[user84 54]

2 minutes ago, speechles said:

hmm. Blame the encoding again. Does it switch to automatic playback recovery at that point and create an ffmpeg-transcode log? Or afterwards with that stutter does it stay as ffmpeg-remux? That is why I still blame the encoding. If it isn't forcing a playback method change. That means it isn't an error causing the Roku nor ffmpeg to abort they just cruise through it. It is something _in_ the video the video is encoded. Some B-frame not done correctly where its part of the video stream now. There is no way to fix it without reobtain their source and encode it correctly. It should expose itself in the ffmpeg data somewhere too but I do not see it. Other than those guessed frames which could be it.

If it plays correctly on other devices it must do that same hiccup at that same spot there. Those other devices are just more adept at how they handle the interruption.

If you are saying all other devices play it perfectly just the Roku is being a dork, then we might need a sample. The full sample. A partial sample may not give the same issue. The full file. It is okay to share in this instance because this is to better the app for educational and such reason. You can share via dropbox, or google drive, or anything you want to share with either myself or @ebr. Make sure to send the link to download the file in private message.Once we can duplicate your issue which should then be possible we can get the right people involved and make this move much faster. Thanks/

I'm happy to do that, but just help me understand. If I made the adjustments with ffmpeg and changed audio to ac3 to direct play, and that solved the problem, how is it still the encode? As the guy who knows nothing here, doesn't this point to transcoding...or the non-ability to direct play as the cause?

At this point I'd rather just use ffmpeg on my library to make AC3 track one and solve this issue. 

[speechles 2125]

1 minute ago, user84 said:

I'm happy to do that, but just help me understand. If I made the adjustments with ffmpeg and changed audio to ac3 to direct play, and that solved the problem, how is it still the encode? As the guy who knows nothing here, doesn't this point to transcoding...or the non-ability to direct play as the cause?

At this point I'd rather just use ffmpeg on my library to make AC3 track one and solve this issue. 

Because it changed the audio which is how the timing is performed on the Roku. Aka, you did remux it when you did that and it did work. MKVToolNix would do the same thing.

Edited October 9 by speechles

[user84 54]

1 minute ago, speechles said:

Because it changed the audio which is how the timing is performed on the Roku. Aka, you did remux it when you did that and it did work. MKVToolNix would do the same thing.

So if mkvtoolnix would to the same thing, why didn't it solve the problem? Really sorry if these are stupid questions. I am not a dumb person, but I am not an expert here.

[speechles 2125]

4 minutes ago, user84 said:

So if mkvtoolnix would to the same thing, why didn't it solve the problem? Really sorry if these are stupid questions. I am not a dumb person, but I am not an expert here.

Because it proves their AAC 5.1 stream is the issue. If you simply change that out and the issue goes away. The issue was the audio stream. Some of the data inside is corrupt, bad, out-of-range, etc..

The timestamps used for playback on the Roku are obtain from the audio streams then the appropriate video sections are shown that match those timestamps. That is how the audio issues glitches could cause the stutter.

Then you re-encode the audio as AC3 would solve it. Ffmpeg corrects the errors. You did a good thing. If that solves it that is the issue. The simplest answer is 98% of the time correct. Other devices might not key directly off the audio stream timestamps and have their own way to tell when shrink/skew/stretch happens on timestamps and can fix it during playback. The Roku cannot/will not do this correction. Roku expects people to use their devices for streaming and is quite cheap on parts hence the devices being so cheap.

Edited October 9 by speechles

[user84 54]

1 minute ago, speechles said:

Because it proves their AAC 5.1 stream is the issue. If you simply change that out and the issue goes away. The issue was the audios stream.

The timestamps used for playback on the Roku are obtain from the audio streams then the appropriate video sections are shown that match those timestamps. That is how the audio issues glitches could cause the stutter.

Then you re-encode the audio as AC3 would solve it. You did a good thing. If that solves it that is the issue. The simplest answer is 98% of the time correct. Other devices might not key directly off the audio stream timestamps and have their own way to tell when shrink/skew/stretch happens on timestamps and can fix it during playback. The Roku cannot/will not do this correction. Roku expects people to use their devices for streaming and is quite cheap on parts hence the devices being so cheap.

Got it. So to confirm...running all of my library with 5.1 AAC audio through ffmpeg and changing to AC3 will solve this. Yes?

[speechles 2125]

1 minute ago, user84 said:

Got it. So to confirm...running all of my library with 5.1 AAC audio through ffmpeg and changing to AC3 will solve this. Yes?

Yes. It should. If these are similar to the RARBG stuff. They tend to use a script that all their members use to encode. That script would contain the flaw causing it. Then any created by that script would need fixing. I am sure you understand what I mean. Not all the 5.1 AAC may need fixing. Just the ones you suspect might carry the flaw.

[ebr 16937]

30 minutes ago, user84 said:

Got it. So to confirm...running all of my library with 5.1 AAC audio through ffmpeg and changing to AC3 will solve this. Yes?

Probably but perhaps only by coincidence.

Given your testing, the issue is related to the remux that is happening on the server - and only in the case of when you pause for a long time and then resume.  So, changing the audio will avoid the remux on the server and, thus, the problem.  What, exactly, is causing that problem is still a bit of a mystery in my view.