04-09-2010 06:00 PM
No, I hear you, I think it probably is the format of the 3gp file rather than the syntax of the HTML that's making the difference.
Did you spin around three times counter-clockwise before dropping the newt's eye into the goat's blood while the video encoder was running? I think that may be the key. ;-)
04-09-2010 07:22 PM
You have somehow managed to produce the only video file ever created that can be played on a Blackberry over http... This is an amazing accomplishment. Pity that neither you nor I nor anyone else can reproduce your superhuman feat.
I really think you have to memorialize this file somehow. I think it should have its own Facebook page, and perhaps you should send it to the Library of Congress or the Smithsonian Museum of Natural History for archiving. This file is something that needs to be preserved for historical purposes.
For posterity, here is what Quicktime and some other tools tell me about the format of this magical file:
Audio: AAC, Mono, 16 kHz, 21.75 kbps
Video: H.264, 176x99, 15 fps, 53 kbps
Combined data rate: 75.13 kbps
File size: 1.83MB
File type: 3gp
As you can see, this thing is tiny, and highly compressed. My video encoders can't even produce a file with a bit rate that low. Even if I could produce a file like this that would play on a Blackberry, I'm not sure I'd want to use it...
But no matter, in honor of this momentous occasion, I hereby issue the following challenge!
To anyone who can reproduce Brian's magnificent feat and create a video file that will play on my Blackberry Storm, I shall offer a used Blackberry Storm, with a cracked screen, which Blackberry Storm to be shipped exactly one day after Verizon offers the iPhone.
04-09-2010 08:20 PM
Zelaza - you rock! Reading your post was definitely the most entertaining moment of my week... Thanks for providing all the various posts to this thread.
BTW, I'm joining in with Zelaza to sweeten the offer for anyone that can top my incredible feat. So that is two, count em', two Blackberry Storm's (broken screens included) to anyone that can deliver a video file that opens via the blackberry browser / http request. Blackberry's delivered after the iPhone is released by Verizon.
04-11-2010 03:22 AM - edited 04-11-2010 03:59 AM
Just thought I'd put in my two cents. I'm about to go live within the next week or two with a free on-demand streaming MP3 / MP4 website specifically for BlackBerries. It was... an interesting technical challenge. This platform is pretty interesting.
To start with, the native browser (which one has to use to watch HTTP streamed video, since Opera Mini only does RSTP) can't handle much CSS. Specifically, the original design plans called for simple drop-down menus... not possible. Because I didn't want to introduce the hassle and sluggishness of java-based drop-downs, I had to settle for a sort of manual two-layer navigation system, as though I were making a webpage in 1993. At least the CSS allowed some highlighting.
Secondly, my test phone is a Bold 9700. It handles HTTP video streaming (what my standardly hosted website uses) just fine. However, it turns out several BlackBerry phones cannot do HTTP, only RTSP. What's more annoying is that RIM only publicizes which phones handle RTSP streaming, and which codec... no info about HTTP. So it turned into a sort of trial-and-error thing.
Next, my embedded video tests worked okay with HTTP streaming on my 9700 (still no go on the non-HTTP compatible models). However, in testing, live RTSP cannot function when embedded! It doesn't make much sense, but there you are. I scrapped embedding altogether and now link to playlists that open directly. Then, of course, there's the more compatible h.263 vs higher quality but less compatible h.264 video; I ended up offerring both versions for best compatibility.
As it stands, some BlackBerry users can use my website "live." I had to put up direct download links as the only option for the rest, so they can get some use out of the site. They still hope I can figure out a streaming solution for them, but so far I've had no luck. I don't have the budget for an on-demand RTSP server like YouTube does. I'm happy to colaborate here, though, if anyone has any ideas.
Oh, and yes, the encoding can be a bit tricky. You have to know what options to check and what not to, or it's not compatible (even if it's the exact same codec and bitrate). I have some experience in this area, and can try and explain if anyone's curious. My videos run at about 15KB/s, and look pretty good. This 25 minute clip uses h.263; this one here is h.264. Both are MP4's, about 21.8MB, and stream fine to my 9700. Of course, if these work, I expect some broken Storms in the mail
04-11-2010 06:27 AM - edited 04-11-2010 06:33 AM
Thank you, CharredPC, for your thoughtful and valuable contribution.
Unfortunately, neither of your videos will play (stream) on my beloved Storm v188.8.131.528. In typical Blackberry fashion, they fail in slightly different ways, but fail they do nonetheless. I'm sure if I downloaded them to local Blackberry storage I could play them from there, but the objective on this thread is to get them to play directly from the network... a tough challenge for a Blackberry, I know, but there it is.
So, Brian's miraculous accomplishment still stands! Challenged but unbeaten!!
If you would like to share your Blackberry encoding secrets I'm sure the readers of this thread would appreciate that. Do they happen to involve newt's eyes or goat's blood by any chance?
04-11-2010 10:28 AM - edited 04-11-2010 10:36 AM
I look at this as good news. If my two files do not play for you, then you have one of the BlackBerries which "doesn't accept http streams." Yet if that 3gp clip from the last page did in fact work fine, then there's hope for everyone! This gives me a goal to accomplish- that all users of my site can view streaming video. Just like the finicky h.264 encoding settings I ran into, I'm betting it's simply a matter of keeping within some unknown set of feature restrictions. I will analize the posted clip with all the tools I have and attempt to recreate it.
04-11-2010 11:03 AM - edited 04-11-2010 11:31 AM
I give you challenge #2. It's an h.263 3GP file. There's still some differences between the 'miracle file' and this one, but hopefully they aren't important differences. My encoding software can't seem to put h.264 (what was used in the magic clip) into the 3GP package, so here's an h.264 MP4 version. If this works, I can try improving things (quality, resolution) until it breaks again. Keep in mind, my file is about three times as large, so might need to buffer initially. I purposely used some non-optimized methods to get a similar file.
04-11-2010 12:29 PM
Darn... CharredPC thanks for joining in the fray - I was thinking I could have a challenger for the holy grail 3gp file but unfortunately not... I had a fail on both files and was really hoping to get some video. We STILL can't figure out exactly what we did to get the working file happening.
Beyond the specs that Zelaza included in his previous post about the working file, did you get any other details. We're happy to re-output the file. We had extracted the same specs Zelaza posted as well but just following those did not seem to work. Its a mystery...
Lets figure it out!
04-11-2010 02:13 PM - edited 04-11-2010 05:31 PM
I haven't given up yet This is my personal quest now that I know it's possible. It looks like I need some more information, though. What software was used to create your magic file? As I said, I couldn't get h.264 into a 3GP package with anything I currently use. Also, could you post a link to a similar file you made which does NOT work? By comparing the two I may be able to spot the difference. I've got some ideas...
Another issue I had to contend with when setting up streaming was setting up custom MIME types. Just to verify that isn't an issue, can you click here and watch your own file streamed from my webspace?
The basic specs are as follows-
The magic file:
Stream 0: Audio
Sample Rate: 32000 Hz
AAC extension: SBR
Stream 1: Video
Codec: avc1 (h.264)
Display Resolution: 176x99
Frame Rate: 15
My failed mp4 test (challenge #2):
Stream 0: Video
Codec: avc1 (h.264)
Display Resolution: 176x100
Frame Rate: 15
Stream 1: Audio
Sample Rate: 3200 Hz
Now, there are many, many settings during encoding which are harder to analize after the fact, but this shows a few important differences between a working and nonworking file:
1. Perhaps most importantly, the 'magic' file has the audio stream first, while mine all have video as Stream 0. This was likely done via the software elogic was using; sometimes there's an extra setting for what stream physically shows up first.
2. The resolution of the 'magic' file differs slightly between Resolution and Display Resolution. I'm not sure how this was done, to be honest. Again I'd love to see what software was used. I don't think this is the secret ingrediant, however.
3. The 'magic file has an AAC extension, whereas my tests don't. If this is the only issue, we should be able to create a video-only test that theoretically wouldn't have the non-SBR compatibility problem... unless issue #1 comes into play.
Hope these ramblings help. I'm trying to contact some of my website beta testers to see if the magic file works for all "non-HTTP streaming" phones. If so, my audience will be very pleased... as will I, even though re-encoding everything will take a while
Edit: One last thing. Looking at the video code itself, it appears that elogic used an Apple / Quicktime based encoder using the 3gp6 filetype (actual code: ftyp3gp6....3gp6isomavc1mp42). My encoder is a bit outdated (and in Windows), so could only do 3gp4 (ftyp3gp4....3gp43gp53g2a). They both use the same *.3gp file extension, but handle things differently internally. There's some other encoding differences too- the audio and video meta data / labels are at the beginning of the file in the magic clip, and at the end in mine. I wish I had a Storm here myself, so that I could do some immediate testing.
04-11-2010 06:45 PM - edited 04-11-2010 06:46 PM
Here you are, challenger #3. I'm downright ashamed of the poor quality and large filesize of this, but... it should work. Expect lots of bufferring.