Handbrake Encodes?

[TonyMontana702`]

I figured this was worth asking but I rip DVD's W/Handbrake on my Macbook and wanted to know if video files on Handbrake's normal encode setting would work on the Pandora?

 

[rabidpoobear]

what are the encode settings? [edit] 666th post [/edit]

 

[mali]

[edit] 666th post [/edit]

Spoiler

 

[TonyMontana702`]

MP4 Format, Codec is H.264 (x264) Output size is 720x480.

 

[gruso]

At the moment, x264 is waiting on hardware acceleration to play properly. When that happens, 480p x624 shouldn't be a problem. We don't know when it's going to happen though. If you want to start watching stuff as soon as your Pandora arrives, you might have to go with lowly old Divx.

[edit] Source

 

[WizardStan]

MP4 Format, Codec is H.264 (x264) Output size is 720x480.

Probably. x264 is very CPU intensive, but a 480p image shoooouuuld be alright. We'll need a lot more optimization before we get 720p though.
You would probably have a lot more luck with XViD or a similar large codec, but we'll see.

edit: h34r:

 

[paulguy]

Bitrate and profile would matter, too. A lot of handhelds rely on "simple profile" which has some limitations for stuff like b-frames and lacks some features. The full comprehensive encoder at a high bitrate will probably be too heavy, without acceleration (or even with acceleration... I know the iphone 3gs can't do more than simple profile.). Moderate/high bitrate divx should probably be just fine, and good enough for playing video on the go.

As for handbrake, I never used it, but I imagine it uses as much as it can to get the best quality, so it may not work well.

 

[kingoddball]

I'm happy using DivX/Xvid/AVI!
WOOHOO!

Happy 666th post, Rabid!

 

[hdonk]

I just checked the TI DSP codecs for the OMAP 3530:

"H.264 Baseline Profile Decoder on OMAP3530"
The H264 decoder handles a maximum resolution of WVGA(864x480)

"MPEG4 Simple Profile Decoder on C64x+"
Contains optimized I and P flow to decode frames up to WVGA (854 x 480 and 480 x 854) and D1 (720x576) resolution at 30 fps

 

[cbox]

That is if and when they add code to use the DSP, and from what I understand the DSP codes on the Pandora aren't really being used all that much right now.

 

[hdonk]

That is if and when they add code to use the DSP, and from what I understand the DSP codes on the Pandora aren't really being used all that much right now.

Actually that's from the documents that come with the CODECs that TI provide that run on the OMAP3530's DSP - and they work with GStreamer. So definitely useable. There's also a document that show the performance of the CODECs with various sample media files, also provided by TI. The question is whether they'll ever be optimised by TI for higher resolutions, or whether someone will have to start again with a new implementation.

 

[pder]

When people say that we are waiting on hardware acceleration in order to play h264, what does that mean exactly? I know that mplayer uses libavcodec for decoding videos and I thought that libavcodec has had ARM optimized h264 decoding using NEON for some time. What am I missing?

 

[paulguy]

This is closer to what vdpau does, where it uses the GPU or something else that's not just a chunk of native code to handle decoding.

 

[WizardStan]

When people say that we are waiting on hardware acceleration in order to play h264, what does that mean exactly? I know that mplayer uses libavcodec for decoding videos and I thought that libavcodec has had ARM optimized h264 decoding using NEON for some time. What am I missing?

DSP code, I believe. We've got this coprocessor that's basically designed with analog data and compression in mind, and no one is quite sure how to use it. It's a "slower" processor in that it has a lower clock speed, and it isn't a generic processor because it is lacking in a bunch of functions, but it does have a lot of additional functions that are not normally part of a generic processor that should make this kind of data manipulation fast and easy. Eventually. Maybe.
I'm probably not explaining the DSP as well as Exophase or someone else could.

 

[Creature XL]

When people say that we are waiting on hardware acceleration in order to play h264, what does that mean exactly? I know that mplayer uses libavcodec for decoding videos and I thought that libavcodec has had ARM optimized h264 decoding using NEON for some time. What am I missing?

I think we are talking about using the DSP (c64+) or the ISP. Honestly I do not know what the ISP does, however, it stands for Image Signal Processor so it might help in some way

I do not think we are talking about GPU assistance. As NVIDIA (and ATI) have special purpose circuits (like VP1/VP2) on their graphic boards to process some stages of the MPEG2, MPEG4 and h.264 codecs. If the shaders could do that they wouldn't have implemented it.

What I know is that one stage of the JPEG "codec" is the discrete cosine transformation (to decode a JPEG you need the inverse DCT) and the DSP is very good for it, well, a DSP is designed to do DCT, FFT and such things And I am pretty sure that MPEG and h264 use a similar transformation.

 

[Polossatik]

You can compare a dsp (Digital Signal Processor) to the 8087/80287/80387 co-processors back in the day's to do floating-point arithmetic or like GPU's on graphic cards to do 3D graphics rendering.

You basically don't need use/have that co-processor to do those things, but the coprocessor is highly optimized to do certain tasks, so it will be much faster (=the device can play higher bit rates/resolution videos ) to use a DSP for video decoding then the normal CPU,.

In hand held / battery based systems a second advantage, besides it's being faster, is that a DSP uses less energy (or at least normally it does) to do those tasks.

As usual, wikipedia has a nice writeup about Digital signal processors.

The problem of using a dsp is that each one is quite different to program , so if you know one DSP you cannot start writing things quite fast for a other DSP processor (like the C6000 DSP TI family) and on top of that not many people are used to do write code for DSP's.
It's really a highly specialized environment that is used a lot in certain systems, but it's not as common as like writing programs for "normal" cpu's.
Most of the DSP's also have not a real cross compiler env , meaning that if you write code in C or so you need to adapt it yourself for best usage of the DSP "family" you are using, while in a "normal" cpu env the compiler adapts the code for best performance on ARM or X86 "from itself", so the people who write a Linux program basically don't care to much if it's used on x86 (Intel) Linux or ARM (like the pandora) Linux, the compiler does the hard work to make the changes to the different CPU platform.
(this last is simplified - there is more to it, but it's to give the idea).

edit: typo's