What are the specific requirements for encoding video?

I've loaded up a number of video files I encoded for other linux/windows comuters, media players, and PDAs and have had little luck playing them properly. Some formats are not recognized at all. One that plays shows significantly corrupted video. Another that plays shows the video fine but has about 2 seconds sync offset between video and audio.

So, exactly what kind of video format with what kind of audio format in what kind of file format is accepted by the edge media player?

I have played mp4 videos on my edge just fine

Originally Posted by borisb

Check the "Specifications" tab on the following page: http://www.entourageedge.com/devices...rage-edge.html.

Based on the list
"Audio playback: MP3, WAV, 3GPP, MP4, AAC, OGG, M4A
Video playback: 3GP, MP4, Adobe Flash Lite (H.264)"
I should expect most video files I tried to work. The "specifications" are not specific enough. Actually, the format I tried that worked the best for video (.AVI) isn't listed.

Nice, I never thought AVI would work. I been basically trying my MP4 movies I got for my iphone to the Edge, I noticed a bunch of movie to Ipad converters since its basically the same size. I am gonna try it after I come back after vacation....to see if that works or not.

Originally Posted by borisb

Video Details
- Format: RealPlayer Plus h.264
- Quality: 768 kbps
- Resolution: 480p HD

Audio Details
- Format: MP3
- Quality: 192 kbps Stereo
- don't use VBR

I hope MP3 isn't the only thing that works for audio inside video. It sounds so muddy.

Found this page that shows a script encoding h.264 with mencoder: http://www.mail-archive.com/android-.../msg04325.html which I'll try to work on tonight.

AVI does/doesn't work. The video plays fine. The audio is a couple seconds delayed.

The AVI files I have were encoded for the Kino movie player running on a Linux Sharp SL-C860 PDA. Plays fine there, but Android seems to be far less tolerant and more picky about video formats.

FYI: Random bit of video encoding news

It looks like Google may be improving the video encoding situation soon with a new VP8 format. Hopefully, it will be on Android soon: http://blogs.computerworld.com/15921..._video_forever

Better, faster encoding using less CPU, and lower CPU requirments for decoding. Found a description of the inner working of VP8 here: http://www.dspdesignline.com/showArt...leID=214303691

That script referenced in the previous post works fairly well using mencoder and ffmpeg. Below are the working guts of it:

So, assuming you have some good video, say, a DVD ripped using:

mencoder dvd://1 -alang en -oac copy -ovc copy -ofps 29.970 -o temp01.avi

Then you run it through mencoder to scale it to Android-approved dimensions and reencode it as :"x264/mp4" video, AAC audio, in an mp4 file:

mencoder "temp01.avi" -o "temp01_tmp.mp4" \
-vf dsize=480:352:2,scale=-8:-8,harddup \
-oac faac -faacopts mpeg=4:object=2:raw:br=128 \
-of lavf -lavfopts format=mp4 -ovc x264 \
-passlogfile "temp01.log" 
-sws 9 -x264encopts \
nocabac:level_idc=30:bframes=0:bitrate=512:threads=auto:turbo=1:pass=1:global_header:threads=auto:subq=5:frameref=6:partitions=all:trellis=1:chroma_me:me=umh
        
mencoder "temp01.avi" -o "temp01_tmp.mp4" \
-vf dsize=480:352:2,scale=-8:-8,harddup \
-oac faac -faacopts mpeg=4:object=2:raw:br=128 \
-of lavf -lavfopts format=mp4 -ovc x264 \
-passlogfile "temp01.log" \
-sws 9 -x264encopts \
nocabac:level_idc=30:bframes=0:bitrate=512:threads=auto:pass=2:global_header:subq=5:frameref=6:partitions=all:trellis=1:chroma_me:me=umh

The above does two pass encoding which I like to boost quality, though it will take twice as long to encode (total encoding time on my system is about the same amount of time to view the movie itself.)

Final step to glue it all together:

ffmpeg -i "temp01_tmp.mp4" -vcodec copy -acodec copy "Movie01.mp4"

FYI: When mplayer plays the video encoded for edge/Android on my computer it reports:

libavformat file format detected.
[lavf] Video stream found, -vid 0
[lavf] Audio stream found, -aid 1
VIDEO:  [avc1]  480x320  24bpp  29.970 fps    0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding)
FAAD: compressed input bitrate missing, assuming 128kbit/s!
AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder)
==========================================================================
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 480 x 320 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.50:1 - prescaling to correct movie aspect.
VO: [xv] 480x320 => 480x320 Planar YV12

. . .

My take on results:

The movie in question is Tron which is my standard for abusing video encoding. It is positively brutal for video encoding with plenty of high-contrast, thin lines. So, flaws in the encoding/playback are more obvious.

For comprison purposes:

The raw data is 6G. My "best" encoding for playing on TV is no scaling, 1800 kbits vhq mpeg4, fairly high quality ogg audio. Result is a 1.3G file. It plays fine on Linux and Windows with the proper codecs. Flaws are hardly noticeable on a HDTV.

The same format as above is used for my Zaurus PDA with the exception that video is scaled to 320 horizontal pixels (and y dimension scaled accordingly for aspect ratio) and video bitrate reduced to 355Kbits. Final size for that file is 312M. There is some graininess with thin, moving lines, but it's not very bad.

The blackberry was a problem. It was picky about encoding and audio had to be MP3. In the end it was easier to do everything using ffmpeg instead of mencoder. At the same dimensions for the zaurus with 375K bitrate for mpeg4 video and 48K for audio the result is a 291M file. Video quality is noticeably less precise and and obviously more blurry. The audio is muddy which might be good for you if you want more bass and less treble.

On paper the format encoded for blackberry should be playable on the edge/android. But, it isn't. In all the tests I tried the video is messed up. It looks like different colors are separated from the luminance channel and displayed offset. I think the cause is that the Android media player is more picky about the dimensions (numbers of X and Y pixels) of the video than the blackberry player. The video file formatted for blackberry does play on the edge with the audio in sync with video (although with video corrupted).

The results from the script above that are playable and viewable on the edge produce a 441M file:

The playback has occasional issues with the audio sync -- it drifts in and out of sync slightly ; up to a quarter of a second by my estimate. Audio quality is pretty good, though. Somewhat tinny from the speakers. With the maximum volume it sounds good with headphones.

Large horizontal movements show noticeable tearing. There is some obvious graininess around high contrast areas. Overall video quality on the edge is better than the blackberry version. The same video played back on my computer, full screen on a 1920x1200 monitor actually looks better than the edge playback in spite of greater zooming. I suspect the Android video player lacks smoothing and other refinements.

I'll try some more experiments and to see how much the video quality can improve.

Originally Posted by kenjennings

That script referenced in the previous post works fairly well using mencoder and ffmpeg. Below are the working guts of it:
. . .
Final step to glue it all together:

ffmpeg -i "temp01_tmp.mp4" -vcodec copy -acodec copy "Movie01.mp4"

. . .

I honestly can't say I understand what the final step using ffmpeg accomplishes. It just looks like it is copying from one file to another. I'm not exactly sure what manipulation is occurring in the output file. I tested the input file ( "temp01_tmp.mp4" ) and it plays the same as the output file on the edge, too. So, I don't know if there is a purpose for using ffmpeg here.

Originally Posted by kenjennings

. . . The playback has occasional issues with the audio sync -- it drifts in and out of sync slightly ; about a quarter of a second by my estimate. Audio quality is pretty good, though. Somewhat tinny from the speakers. With the maximum volume it sounds good with headphones.

I'll try some more experiments and to see how much the video quality can improve.

Further testing with mplayer playback shows the same audio sync issue on a (rather powerful) linux box, so the delay is not due to playback processing overhead. It must be something inherent in the encoding. The audio delay control in mplayer ( + and - ) was able to fix it during playback. When sound was back in sync it reported I added 200ms offset. Didn't have time last night to redo the rip/encode to verify I have a handle on how to shift the audio during encoding.