On 06/08/12 03:13, Christian Brümmer wrote:
I've another question cause it seems that you are familiar with FFmpeg and its dependancies. The problem beside decoding (@Android Phone )is the Color-Conversion from YUV to RGBA. I m using swscale (performance is worse ~ about the decoding time) and i heared about splitting the image in two parts and use swscale parallel for each part. Is that possible? If not - is there a way to speed up colour conversion (some thing like "thread_count") for android? I get a log output that says there is no hardware acceleration for colour conversion - is that still right or is there a patch somewhere to use advanced neon commands for color-conversions?
I used opengles2 for this, it works well and gives you the scaling directly and is pretty well ideal if all you're doing is displaying it (also requires smaller texture uploads - which are #@#@$# slow - the android player uses external textures which directly load YUV from 'cpu ram', but these are not exposed apis). swscale is way too slow (unless it's been improved lately for arm), but if you want to try it MT the api directly handles 'slices', so converting it to MT should be fairly simple and obvious.
For optimised versions, the yuv conversion alone isn't too hard to write (i'm sure there is some out there for neon or at least arm, search for it) but if you need scaling it complicates things a little bit.
You can do the yuv conversion concurrently to decoding the next frame, so if all threads are busy decoding the video already, doing an MT conversion wont help.
But either way, mp4 is just slow to decode and you hit limits trying to do it in software. If you have control over both ends you're not tied to one format though.
Michael _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
