http://www.viddler.com/file/93ee306f/html5
http://www.viddler.com/file/8dd2cbf0/html5
When I try to play these two files, I get an isRequestFailed roVideoPlayerEvent (-3, “An unexpected problem (but not server timeout or HTTP error) has been detected.”) These videos also fail to play from the USB channel.
They both play fine on my computer, and they look like they should be Roku compatible. Any idea what the problem could be?
Thanks!
Supported MP4 is H.264 /AAC LC - Audio Bit Rate max 256K Video Bitrate Max 2.5Mbps. Constrainted VBR. Progressive files work best. YUV Color. Max Res on HD 1280x720. Max Res in SD 720x480.
90% of the time it’s the encoding. Also depends on how you are streaming videos to the ROKU. You didn’t mention that.
Also depending on what program you use to encode video with will determine how you need to encode. Not all converters are alike.
FWIW, you can go higher bitrate than that. 4.5mbps is probably about the recommended limit for streamed items, though you’d probably want to be careful on your peak bitrate settings. Of course, if you’re providing an encoding that high of bitrate, you should provide lower bitrate options for viewers with slower connections.
Both of these videos play fine for me using the latest internal build. A number of playback bugs have been fixed in the internal build, so it looks like whatever was causing the problem will be fixed in the next release.
–Mark
I’m receiving the same error with a video I’ve encoded (details shown below). I have noticed that if I limit the encoder to only encode the first 20 (or so) frames, the video plays with no error. Additionally, if I reference the URL from within my browser, QuickTime can play the video flawlessly. I initially tried using the settings as outlined in the Roku Streaming Player Encoding Guide, but those settings result in the same behavior. Is there something I’m overlooking?
Error Code
request failed - error: -3 - An unexpected problem (but not server timeout or HTTP error) has been detected.
Video Properties (from ffmpeg -i)
ffmpeg -i 20080703184721.m2ts.mp4
FFmpeg version git-N-28891-gda53f05, Copyright (c) 2000-2011 the FFmpeg developers
built on Apr 5 2011 16:43:42 with gcc 4.4.3
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab
libavutil 50. 40. 1 / 50. 40. 1
libavcodec 52.117. 0 / 52.117. 0
libavformat 52.105. 0 / 52.105. 0
libavdevice 52. 4. 0 / 52. 4. 0
libavfilter 1. 77. 1 / 1. 77. 1
libswscale 0. 13. 0 / 0. 13. 0
libpostproc 51. 2. 0 / 51. 2. 0
Seems stream 0 codec frame rate differs from container frame rate: 59.94 (2997/50) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20080703184721.m2ts.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
creation_time : 1970-01-01 00:00:00
encoder : Lavf52.105.0
Duration: 00:00:17.57, start: 0.000000, bitrate: 2175 kb/s
Stream #0.0(und): Video: h264 (High), yuv420p, 720x480 [PAR 32:27 DAR 16:9], 2048 kb/s, 29.97 fps, 29.97 tbr, 2997 tbn, 59.94 tbc
Metadata:
creation_time : 1970-01-01 00:00:00
Stream #0.1(und): Audio: aac, 44100 Hz, stereo, s16, 128 kb/s
Metadata:
creation_time : 1970-01-01 00:00:00
At least one output file must be specified
Update: After much trial and error, I’ve discovered that this issue appears with any video over 464 frames (approx. 15.48 seconds). Once I play a video with 465 frames, the video stops prematurely. 466 frames and the video fails to play altogether.
I used the same video encoded with the same settings shown above.
Seems stream 0 codec frame rate differs from container frame rate: 59.94 (2997/50) → 29.97 (2997/100)
That part looks a little suspicious. Maybe you need to explicitly set the frame rate ( ffmpeg’s -r flag ).
Here is the encoding command I’ve been using:
ffmpeg -y -i $1 \
-acodec libfaac -ab 128k -ar 44100 -ac 2 \
-vcodec libx264 -vpre roku -b 2048k -r 29.97 -s 720x480 -vframes 464 -threads 0 $2
Where $1 is the input file (usually m2ts) and $2 is the output (mp4).
-vframes 464
Hmmm, you are explicitly setting the frame rate so that guess is wrong.
According to the ffmpeg man page, -vframes is the number of frames to record. My psychotic powers tell me there is a connection here with your videos stopping at frame 465. Try dropping the -vframes flag altogether.
Dropping the vframes parameter produces a video that doesn’t play at all.
I’m wondering if this is a server side issue and not fully related to Roku. I’m curious to know if Roku is receiving data from the server too fast and flooding a buffer. The fact that 464 frames succeeds, but 466 fails might be due to the buffer being filled. In other words, the buffer must be close to a 4MB limit (give or take because the buffer is emptying as it is filling).
I will try to put a sleep on the server side between buffer flushes to spoon feed the data to Roku. I’m not sure if that would help, but it’s worth a try.
Hold on – you’re encoding an MP4 file, right? So the file must be completely encoded before the Roku starts playing it. MP4 is not a streaming format. I’m not sure what “server” you’re talking about, but Roku reads the files from a standard HTTP server at its own speed; it’s not possible for the server to send the data too fast. What “buffer flushes” are you referring to?
–Mark
“RokuMarkn” wrote:
Hold on – you’re encoding an MP4 file, right? So the file must be completely encoded before the Roku starts playing it. MP4 is not a streaming format.
Correct. The files I’m attempting to play are completely encoded ahead of time (last week).
“RokuMarkn” wrote:
I’m not sure what “server” you’re talking about, but Roku reads the files from a standard HTTP server at its own speed; it’s not possible for the server to send the data too fast. What “buffer flushes” are you referring to?
You are exactly right. I am writing a custom server to host my videos and suspect that I have something wrong either in the HTTP Headers (mime type?) or in the streaming. Once I moved one of the longer videos to an Apache HTTPD instance, the file worked just fine.
Thanks for your time. This is obviously not a Roku issue so I will go on my own for now.
Make sure your server supports range requests.
-JT
“renojim” wrote:
Make sure your server supports range requests.-JT
Brilliant! That was exactly the issue.
Thanks for the help. 
Roku player started video failing
