Roku Developer Program

[Shlepzig]

"renojim" wrote:
The Chaneru fix was one I posted long before that post and has nothing to do with audio interleave. I'm not doubting your audio interleave statement, but you've posted conflicting reasons for the issue.

-JT

My intention was to direct the new posters to other conversations where this problem has been addressed. The assumption of audio interleave is not mine, but that of this post in the other thread.

http://forums.roku.com/viewtopic.php?f=34&t=24743&start=30#p186854

I have experienced this problem with encodes of movies over and hour, and in my opinion it acted just like a buffer-overflow type error. I did not devote more than a couple hours to solving it, but the explanation in the post above seems well informed and makes sense to me. I have seen other posts around this forum that say much the same thing (though I don't recall where they are nearly as well).

You post on the chaneru forum was a different approach to the problem and it also seems to have been effective (I have not tried it myself, but silence on a public forum is an otherwise excellent endorsement. It aslo reflects similar posts I have seen elsewhere in this forum.). You addressed specific bitrates, framerates, and audio settings which could also affect how much information is sent to or retained in the buffer.

Without diving deeply into the inner workings of the encode and streaming process, I don't have any better answers. I did want to help the other forum users get to explanations that would help them with the problem without reposting the entire forums.

-Shlep'

[jazric11]

"greubel" wrote:
Can you tell me where I can get a sample file ?

http://www.mediafire/?h24icacsrdc8m78

These are the different settings in handbrake that I have tried (my source is mkv 60 fps, 4000 bitrate, AC3 audio):

1. Large file size, web optimized, anamorphic strict, decomb (default), codec x264, 29.97 fps, 2500 avg bitrate, AAC audio 160 bitrate - picture fine when no fast motion, choppy picture very noticeable in fast action, no reload screen

2. Large file size, web optimized, anamorphic (strict or none), decomb (default), codec x264, same as source fps (60 fps), 4000 avg bitrate, AAC audio 160 bitrate - picture perfect, fast action flawless, gets a hiccup about 10 seconds into action and then does the reload screen, it repeats about 3 seconds of the action and then hiccups in the same place and does the reload screen again. Usually does this 3 x and then does a longer reload screen and the action continues.

[jazric11]

Ok, so I tried one more setting and I'm encouraged:

3. Large file size, web optimized, anamorphic none, decomb (default), codec x264, same as source fps (60 fps), 2500 avg bitrate, AAC audio 160 bitrate - picture is good quality, fast motion is perfect. I'm going to crank the bitrate up a little more to see how far I can go before it calfs.

[greubel]

That last setting works great, didn't rebuffer once !

[jazric11]

"jazric11" wrote:
Ok, so I tried one more setting and I'm encouraged:

3. Large file size, web optimized, anamorphic none, decomb (default), codec x264, same as source fps (60 fps), 2500 avg bitrate, AAC audio 160 bitrate - picture is good quality, fast motion is perfect. I'm going to crank the bitrate up a little more to see how far I can go before it calfs.

I tested the above at 3000 avg bitrate and it hiccup'd. Here is my conclusion based on an mkv source file at 720p (1280X720), 60fps, 4000 bitrate, AC3 audio:


For High motion sports (Hockey, basketball, football?), use the following handbrake settings:

Output Settings
Container - MP4 File - Large file size - Web optimized

Picture
Anamorphic - None

Video Filters
Decomb - Default (may not be necessary but it can't hurt)

Video
Video Codec - H.264 (x264)
Framerate (FPS) - same as source
AVG Bitrate (kbps) - 2500

Audio
AAC codec automatic mixdown, auto samplerate - 160 bitrate

If the source is 1080 then I suppose a loose anamorphic setting and a reduction of the width from 1920 to 1280 would do it.

[RokuKevin]

Both issues mentioned in this post are possible issues with video not playing after an hour.

1) An infrequent or non-existent audio interleave value can cause this. The audio interleave should be set to less than a couple seconds.

2) Framerates other than 23.976 fps or 29.97 can be problematic as the audio and video get out of sync over time any may eventually cause a rebuffer.

--Kevin

[Timmy_Likes_to_]

I have tried the audio interleave adjustment to video files that are 23.976 fps with no success. I used MP4BOX like this: mp4box -inter -2000 myfile.m4v

The video files load quick, but they still rebuffer after the hour mark and quite frequently.

The 29.976 fps videos work quite well. Problem is a lot of our videos are 23.976 fps and converting them to 29.976 fps makes panning within the video choppy.

Are there any other suggestions? Could it have to do with how my 23.976 fps videos are encoded initially?

[RokuMarkn]

"Timmy Likes to Click" wrote:
I have tried the audio interleave adjustment to video files that are 23.976 fps with no success. I used MP4BOX like this: mp4box -inter -2000 myfile.m4v

What does the dash in front of the 2000 mean? Shouldn't it be like this?
mp4box -inter 2000 myfile.m4v

--Mark

[Timmy_Likes_to_]

It seems that this issue is solved.

Magically, anything that was encoded at 23.976 fps do not rebuffer after the hour mark.

When was this fixed? With the newest firmware?

[RokuKevin]

We've always been able to play 23.976 fps content... It was odd framerates that sometimes had an issue after one hour. Nothing has changed on that issue.

--Kevin