Wht Video Files Are Going To Be Compatible On The Pandora?


jakshep2

Active Member
Joined
Nov 10, 2007
Messages
509
Website
Visit site
is the pandora gonna be compatible with several video formats? I'm sick to death of my GP2X only running certain AVI files een if they're DivX. WMV support maybe?
 
jakshep2 said:
I'm sick to death of my GP2X only running certain AVI files een if they're DivX.
Hi,

You should try Avidemux to convert your files to (in ?) a proper format / resolution (320x240) and save some space ;)

Bye, Magic Sam
 
Last edited by a moderator:
Chip said:
Though we are still waiting to hear back about h.264 playback...
I couldn't find a free H264 encoder within the 30 seconds I was searching for, so I got kinda bored with that idea :)

If you can point me to a H264 encoded clip, I'll try it.
 
Last edited by a moderator:
Squidge said:
I couldn't find a free H264 encoder within the 30 seconds I was searching for, so I got kinda bored with that idea :)

http://www.videolan.org/developers/x264.html
QUOTE
If you can point me to a H264 encoded clip, I'll try it.

Wikipedia points here for samples:
http://www.apple.com/quicktime/guide/hd/
http://www.apple.com/trailers/

But I would be surprised if mplayer did not support h264 out of the box.
As far as speed is concerned, I am not sure if these will play real-time out of the box. There's no c64x+ or NEON code in mplayer... yet ;)
 
Last edited by a moderator:
Laurent said:
1800 bps? Shouldn't that be 1800 kbps?
On my Athlon 3500+ running in 64 bit mode, mplayer eats close to 20% of CPU time, that doesn't look encouraging :(
Whoops. fixed

Straight-up CPU-wise the Pandora probably can't hack it. It's going to take the DSP (which was specifically designed for video decoding) to do h.264.
 
Last edited by a moderator:
Chip said:
Straight-up CPU-wise the Pandora probably can't hack it. It's going to take the DSP (which was specifically designed for video decoding) to do h.264.

That's what I think too. Perhaps NEON can come close :)

FYI: http://www.arm.com/news/18441.html

Note the EULA would prevent use in mplayer/ffmpeg.
 
Last edited by a moderator:
Laurent said:
Note the EULA would prevent use in mplayer/ffmpeg.
Whose EULA, Arm's or ffmpeg's? Do we care as long as we get proper h.264 decoding?
 
Last edited by a moderator:
Chip said:
Whose EULA, Arm's or ffmpeg's? Do we care as long as we get proper h.264 decoding?

I would not try to mix any EULA (in this case ARM's) with any GPL code (ffmpeg).

I will try to get in touch with the various parts involved to see if anything can be done :)
 
Last edited by a moderator:
I'll try some slightly more accurate, but still quite flawed benchmarks.

1. My Athlon 2500+ has a frequency of 1913mhz (3829.53 bogomips) and mplayer ate up 14-18%. Video was minimised to remove the rendering times which are irrelevant. Artsd off for same reason. Nothing else significant was running.
39secs of that video ate up 10secs of cpu time (measured comfortably with qps). That means on an x86 cpu at 600mhz the same 39secs would take CODE
600/1913 * 39 = 12
secs of cpu time to decode. Realtime on an x86 with SSE (1) with some cycles to spare.

2. The mplayer-nogui package on debian lenny appears to be missing. Annoying.
Nonetheless, on my 300mhz server (602.17 bogomips, no SSE) vlc (which uses the same ffmpeg decoder) reports:CODE

"ffmpeg decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)"

Need advice on how to get more data out of vlc.

Anyway, I doubt it'll be hard to get the pandora to decode H.264 realtime.
 
With mplayer compiled with no ARMv5 or ARMv6 extensions, no NEON and no DSP:


[root@OMAP3EVM /]# ./mplayer -cache 8192 ./buryx264.mp4
MPlayer 1.0rc2-4.2.0 © 2000-2007 MPlayer Team
CPU: ARM
Could not access the 'termcap' data base.

Playing ./buryx264.mp4.
Cache fill: 1.86% (155648 bytes)
Quicktime/MOV file format detected.
[mov] Video stream found, -vid 0
[mov] Audio stream found, -aid 1
VIDEO: [avc1] 640x480 24bpp 24.000 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)
AUDIO: 44100 Hz, 2 ch, s16le, 314.8 kbit/22.30% (ratio: 39345->176400)
Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder)
==========================================================================
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 640x480 => 640x480 Planar YV12
A: 3.8 V: 3.0 A-V: 0.795 ct: 0.023 74/ 74 116% 0% 6.8% 50 0 88%


So close! * May be faster on a "retail" Pandora though, as it'll probably have better audio drivers.

To be honest, you didn't notice any gaps in the audio, and due to the video, do didn't notice much wrong until you ran it on a PC to find out what it should be.


* - @ 925Mhz
 
Last edited by a moderator:
Squidge said:
With mplayer compiled with no ARMv5 or ARMv6 extensions, no NEON and no DSP:

No ARMv6, sure? ffmpeg has an idct v6, you did not compile it?
 
Last edited by a moderator:
Chip said:
Straight-up CPU-wise the Pandora probably can't hack it. It's going to take the DSP (which was specifically designed for video decoding) to do h.264.
Or the IVA2+ video decoder ;)
 
Last edited by a moderator:
I'm not entirely sure what all those numbers mean. How close to fullspeed was the video? On the one hand, you could probably make up the difference just by overclocking the CPU. On the other hand, using the NEON codec and/or DSP you could probably get fullspeed playback with a significant underclock.

I know MPlayer comes with ffmpeg for codec support built in, but is it at all possible to use external codecs? It seems a shame that ARM came up with a nicely optimized h.264 codec that we might not be able to use because of dopey licensing restrictions.
 
Chip said:
I'm not entirely sure what all those numbers mean. How close to fullspeed was the video?
It required 116% of the processor to play the video correctly. I'd say it was close, but no cigar.

Chip said:
On the one hand, you could probably make up the difference just by overclocking the CPU.
Someone didn't read my post fully.

QUOTE
No ARMv6, sure? ffmpeg has an idct v6, you did not compile it?


I deleted my mplayer binary so I had to recompile it. It refused to work at first, but in the end it compiled, but minus the v6 extensions. If I can get them working, I'll see how much of a difference it makes.

QUOTE
I know MPlayer comes with ffmpeg for codec support built in, but is it at all possible to use external codecs? It seems a shame that ARM came up with a nicely optimized h.264 codec that we might not be able to use because of dopey licensing restrictions.


The windows version has codecs in DLLs for when they can't release the source code for license or other reasons. I don't see why the same can't be done on Linux.
 
Last edited by a moderator:
Back
Top