Ffmpeg


Code:
#define	MP_CODEC_NULL		-1
#define	MP_CODEC_MP4D		0
#define	MP_CODEC_MP4D_DIVX3	1
#define	MP_CODEC_H263D		2
#define	MP_CODEC_MP2D		3
#define	MP_CODEC_MJPD		4
#define	MP_CODEC_MP4E		5
#define	MP_CODEC_WMVD		6
#define MP_CODEC_MP3D	   7
#define	MP_CODEC_MP1D		9
#define	MP_CODEC_MJPE		10

In that case, what is the purpose of the above?
 
Vimacs posted on Apr 17 2006 at 11:31 AM said:
Yeah, right, dont forget the huge opensource scene arround the mmsp2 that exists for YEARS.
OHEHMGEE!!!

U R SOOOO RIGHT!!! + FUNNI!

LOLORSCATES!1!!!

Jesus Christ man, I was asking a question, not looking for a snarky remark.
 
Last edited by a moderator:
Phil posted on Apr 17 2006 at 06:29 AM said:
nickspoon posted on Apr 17 2006 at 11:19 AM said:
The video hardware inside the GP2X is very versatile - it can be used for many different types of video (including H.264) and even to speed up 3D performance. The current software module that is loaded on to the decoder only handles MPEG, MPEG-2, MPEG-4, H.263 and MJPEG. Many more formats are decodable, but the source for this module is unavailable. Not even GPH have it (they've only got the binary), so our chances of getting it are very close to nil.
And no sign of an open source alternative?

If by "open source" you mean "brute force"

Not yet =p
 
Last edited by a moderator:
invinciblegod posted on Apr 17 2006 at 04:51 AM said:
Since everyone is talking about possible playable file formats, another question pertains to container formats. Will mkv be supported? Choosing between languages tracks? Other subtitle formats? Can these work? And regarding h.264, Currently, most of my H.264 videos take more processing than other video types. This could be a problem for the gp2x.

Don't worry about MKV/OGM. They'll come in time and are a fairly trivial thing to add. The actual decoding is the worrysome part.
 
Last edited by a moderator:
Thanks to coob for pointing out that theres already some arm-asm code in libavcodec, i completly missed it. Anyway, we have 320x240 mpeg4 video / mp3 audio running at 233mhz, or 20fps at 250mhz. Should be a lot nicer on the batteries than the gph mplayer, as we're only using 1 cpu, not 2 and the video hardware.

iPod video trailers play at about 1/2 speed, with no sound, so h.264 will definitely need hardware support, but iPod res videos should be well within reach if the video hardware ever gets figured out.

Anyway, time to get cracking mplayer ;)


ps. oh yeah. we could always port libavcodec's video decoder the the 940t for a bit of a speed boost :)
 
I've been re'ing the Magiceyes 940 binary, and it seems to use hardware registers that are not documented in the databook (maybe you have to license these docs seperately, the same as you have to for the binary module itself).

Also, the 940 module does seem to support H263 in some way or other, and contains the open source software "tmndecode" which is a decoder and player for H.263 and H.263+ bitstreams, suprisingly enough... I don't know if its in there verbatim, or has been hacked up to use the hardware more. Maybe we can figure out the compiler used (I'm guessing GCC2.95), compile tmndecode with that compiler, and create some signature files to find the same functions in the 940 firmware (eg. by looking for the same sequence of instructions).

tmndecode can be found here -> http://www.openmash.org/lxr/source/codec/tmndec/

Doesn't seem to be GPL, otherwise we could sue Magiceyes for the source :)
 
Back
Top