I'm analyzing PVMFAvcEncNode which uses the software codec that comes in
opencore\codecs_v2\video\avc_h264\enc. Fist I couldn't run any test because
of the "Bus error" message, then I applied the fix that you shared and I was
able to run the test but the output looks distorted; the players I'm using
are desktop applications: mplayer and VLC media player.
Also I'd like to know how PVMFAvcEncNode produces data. Are they NAL units
or is there some meta data that composer node might use?
Apologize for the confusion;
Thanks
On Thu, Dec 4, 2008 at 8:33 AM, rktb <[EMAIL PROTECTED]> wrote:
>
> I am very confused.
>
> Whose encoder are you using?
> Whose decoder are you using?
>
>
> On Dec 2, 3:15 pm, "Ricardo Martinez" <[EMAIL PROTECTED]> wrote:
> > Thanks for your response,
> > I tried your fix and I'm able to run the custom test that I created, but
> the
> > output looks distorted.
> >
> > I'm porting a HW accelerated H264 codec into PV, so far I'm able get an
> > output using test_pvauthorengine but I'm not able to play that output. Do
> > you know if the composer node expects the h264 data to be delivered in
> some
> > specific format? I suspect this error is because my codec does not
> support
> > NAL format but I'm still not sure.
> >
> > Thanks
> >
> > On Tue, Dec 2, 2008 at 11:44 AM, rktb <[EMAIL PROTECTED]> wrote:
> >
> > > Just to add a comment, the problem that was originally reported, "Bus
> > > error", indicates a data-alignment problem. Here, mvL0 was assumed to
> > > be 32-bit aligned...which is not necessary the case.
> >
> > > On Dec 2, 11:32 am, rktb <[EMAIL PROTECTED]> wrote:
> > > > This is a quick fix. I am still not sure whether the same patch will
> > > > be applied or not. But, here it is ..
> >
> > > > File: external/opencore/codecs_v2/video/avc_h264_old/enc/src/
> > > > motion_est.cpp
> > > > Function: void AVCMotionEstimation(AVCEncObject *encvid)
> >
> > > > mv_uint32 = ((mot_mb_16x16->y) << 16) | ((mot_mb_16x16->x) &
> > > > 0xffff);
> > > > for (k = 0; k < 32; k += 2)
> > > > {
> > > > ptr_mv = (void*)(&currMB->mvL0[k]);
> > > > *((uint32*)ptr_mv) = mv_uint32;
> > > > }
> >
> > > > to
> >
> > > > for (k = 0;k < 32; k+=2)
> > > > {
> > > > currMB->mvL0[k] = mot_mb_16x16->x & 0xFFFF;
> > > > currMB->mvL0[k+1] = mot_mb_16x16->y;
> > > > }
> >
> > > > On Dec 1, 11:27 am, "Ricardo Martinez" <[EMAIL PROTECTED]> wrote:
> >
> > > > > great!
> >
> > > > > Do you have a fix that I could apply until the patch is available?
> >
> > > > > BR,
> > > > > Ricardo
> >
> > > > > On Mon, Dec 1, 2008 at 8:41 AM, rktb <[EMAIL PROTECTED]> wrote:
> >
> > > > > > I am able to reproduce this. I can see the problem and also have
> a
> > > > > > fix. Will submit a patch soon.
> >
> > > > > > Thanks
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"android-framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-framework?hl=en
-~----------~----~----~----~------~----~------~--~---
