Here's the a quote from the set-up in the full phone-hosted article:
In Symbian, a video that comes in a container format that is totally unsupported (eg: *.mpeg) will not be listed in the video player and if opened from the File Browser, the video player tries to play the file and then gives an error message,"Cannot Play Video". But you might have noticed cases where the video player sometimes cannot play the video, but audio playback happens successflly with the display showing a striked out video icon. This means that the video player can handle the digital container format (AVI, MKV, MP4, etc.) and the audio/sound track format (MP3, WMA, AAC, etc.), but couldn't completely decode the video format (XVID, DIVX, H.264, etc.) due to some constraints, even though the codecs for these formats are already present. These constraints are nothing but the varrious parameters and configuration strings assigned during the encoding process.
Video players in other active ecosystems are updated frequently to cop up with these changes and advances in encoding technology, while for Symbian, as we near the end of 2013, there is little hope that such a thing would happen...
...But higher the number of reference frames being used, higher is the processing power and memory required to decode the video, which is probably why even flagship symbian devices cannot decode videos which use more than 5 reference frames, due to which the device can handle the container format and the audio format, but not the video part. The perfect solution is of cource to completely re-encode/convert the video into a suitable format, which could enable smooth playback at the cost of a little quality loss and too much time loss. The shortcut method is to just reduce the number of reference frames used from anything in between 6-16 to just 5. Thanks to a tweaked version of FFMPEG, a tool used for ultrafast encoding of video. This version does not support full video encoding, but just does Muxing/Demuxing of video through which features like number of Re-Frames, Frame Rate etc. can be changed.
There follows a mini tutorial on using the tool. And here's part of the conclusion:
Again, there would defenitly be some sort of noise in the output video and the amount of noise increases based on the number of frames reduced. Reducing upto 2 Re-frames won't cause much noise during playback. As the normally recommended Re-frames number for H.264 encoding is 6, most videos comes with 6 or 7 Re-frames assigned to them, which means these videos can be subject to the above process, thus enabling playback in Symbian devices. Above two images are screenshots of the initial unprocessed video and the processed one respectively. Here, the number of Re-frames reduced was 2 and the noise visible is not consistant in all frames, but is present only in some parts of the video, thus not ruining the movie watching experiance. When the number of Re-frames is more than 2, the noise will be large and present in more frames. The process would seem to be a bit complex at first, but is actually much simpler and time saving than complete re-encoding. After the Muxing process, the size of the video remains almost the same. The method will come in handy when you need to quickly make such videos playable in your symbian device. Barring the slight amount of distortion in some frames, the quality of the video remains the same as that of the initial video. This method could be usefull for a lot of Symbian users who like to watch movies and documentaries from their phones.
You read the full article here. Remember that if the phone-hosted page loads slowly, Jithin may be in tricky cell data coverage! As before, an admirable experiment, but this is why most of the world works from big and fast static web servers(!) [Indeed, the images above are hosted on other servers.]
Maybe I'm unusual, but all long form MP4 content I've tried to play on my Symbian phones has worked fine. I tend to get my MP4s from YouTube using various downloaders. I do realise that there's a (ahem) market for commercial movies online and that the codecs and parameters for these tend to be more ambitious. Comments welcome if the linked piece has helped you at all.