Roku Developer Program

[RokuKevin]

One of the root causes of the playback stopping after 30 to 60 min is that the encoding has an insufficient audio / video interleave for the Roku to handle.

v2.9 should alleviate most of the audio / video interleave issues, and we'd like to test against some more content that previously had this issue.

I've already been collecting serial numbers for the "squished video" issue, but if you'd also like to give us feedback about the "stops playing after 30 to 60 min" issue we'd welcome more testing.

--Kevin

[renojim]

I remember when I had the problem of buffering after 30 to 60 min it was because, I think, the video was encoded at other than 29.97 fps. Is this related in any way?

-JT

[em_lazardo]

I also had problems with the widely described rebuffering issues during playback or seek in the 51+ minute range, typically 23.97 mp4 generated by handbrake + ffmpeg.

Solution A: Ensure audio sync with a final clean-up pass:

[[ $MIN -gt 50 || $FPS -eq 23.97 ]] &&\
ffmpeg -i $SOURCE.mp4 -acodec copy -vcodec copy $TARGET.$$ &&\
mv $TARGET.$$ $SOURCE.mp4

Also tried MP4box interleave which worked in some but not all cases. Reference:http://forums.roku.com/viewtopic.php?f=34&t=24725&p=210908#p210908

Solution B: Verify frame rate using a pre-encode scan at +10 minutes:

SCAN=`mplayer -endpos 1 -ss 600 -vo null -ao null dvd://$TITLE -dvd-device $SOURCE 2>&1 |\
awk '/^demux/{ LOC=index($2,"fps"); if(LOC!=""){print substr($2,1,LOC-1) };}'`
[ "$SCAN" != "" ] && FPS=`echo "scale=2;$SCAN" | bc -q`

Most tools seem to not sample at a sufficient depth or duration to accurately determine frame rate, esp. for NTSC film source.

Since integrating A and B, zero rebuffers (even the 2001 KOYAANISQATSI DVD made it :), and both are many times faster than encode itself.

[RokuKevin]

This fix is to be more tolerant of audio/video interleave skew. We have done nothing to address the framerate issues.

--Kevin

[em_lazardo]

"em.lazardo" wrote:
Most tools seem to not sample at a sufficient depth or duration to accurately determine frame rate, esp. for NTSC film source.

"RokuKevin" wrote:
... We have done nothing to address the framerate issues.

Different issue. Handbrake would occasionally select the wrong framerate based on scanning source content different than the main feature [like ads, warnings, etc]. Since I couldn't determine that this mismatch didn't impact audio sync, I left both checks in my encode chain.

Cheers,

[bcl]

I had problems with pretty much every Handbrake preset except the iPod High one. I re-encoded everything using that so I don't have any problems currently.