Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
evilmax17
Level 7

Videos fail with unknown error (index -3)

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!
My Roku Channels:
Viddler - viddler.com
Tested Fan - tested.com | Jamie & Adam
This is my next - theverge.com
1080p Showcase - RIP
Whiskey Media - RIP
======================
http://www.binarymoustache.com
0 Kudos
14 Replies
jgravert
Level 7

Re: Videos fail with unknown error (index -3)

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.
0 Kudos
Anonymous
Level 9

Re: Videos fail with unknown error (index -3)

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.
0 Kudos
RokuMarkn
Level 8

Re: Videos fail with unknown error (index -3)

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
0 Kudos
mikedehaan
Level 7

Re: Videos fail with unknown error (index -3)

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
0 Kudos
mikedehaan
Level 7

Re: Videos fail with unknown error (index -3)

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.
0 Kudos
stivosaurus
Level 7

Re: Videos fail with unknown error (index -3)

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 ).
0 Kudos
mikedehaan
Level 7

Re: Videos fail with unknown error (index -3)

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).
0 Kudos
stivosaurus
Level 7

Re: Videos fail with unknown error (index -3)

-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.
0 Kudos
mikedehaan
Level 7

Re: Videos fail with unknown error (index -3)

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.
0 Kudos