Ducati decoding with libDCE/DRM

[Andre Renaud]

Hi,
I'm working with the PandaBoard using libDCE + ffmpeg to do H264 video
decoding, and I'm not having a lot of luck - VIDDEC3_process is
consistently returning -1, and extended error is set to 0x401
(implying I'm getting XDM_INSUFFICIENTDATA). However I can't quite see
what I've messed up. I've whittled it down to a simple test program,
which can be found at:
http://pastebin.com/3fAe3iv3.

I've manually stripped the H264 frames out of a 400x300 video into a
bunch of separate files, and am loading these frame-by-frame, however
I have a long program that does this using libav, and it has the same
issue.

I'm using omap_bo_new to allocate the buffers, so that they can be
correctly shared, and adjusting the width/height to the proper
alignment.

Does anyone have any ideas about where I might have gone wrong?

Regards,
Andre

[Nicolas Dechesne]

not sure if that will help you... but we have a similar video decoder
sample application here:

http://gitorious.org/gstreamer-omap/omapdrmtest

that we use routinely. it's using libDCE directly (no GST) to decode
video file, and it's using libav to parse the file. Only h264 is
supported, but that at least gives you a working reference
implementation.

[Rob Clark]

On Thu, Aug 2, 2012 at 12:23 AM, Andre Renaud <an...@bluewatersys.com> wrote:
> Hi,
> I'm working with the PandaBoard using libDCE + ffmpeg to do H264 video
> decoding, and I'm not having a lot of luck - VIDDEC3_process is
> consistently returning -1, and extended error is set to 0x401
> (implying I'm getting XDM_INSUFFICIENTDATA). However I can't quite see

fwiw, this error is probably meaning you have something not formatted
as the codec expects in the incoming bitstream. It is expecting whole
frames (or slices) in bytestream format, not just arbitrary amount of
input. As Nicolas suggests, you probably want to have a look at the
parse code in omapdrmtest (see viddec3test.c and util/demux.c)

Also, fwiw, you probably need more output buffers when you get a bit
further, to have correct results.. at least if it is not a pure
I-frame stream. The codec is still using the output buffers as
reference frames until they are unlocked (show up in freeBufID[]
array).

BR,
-R

[Andre Renaud]

Hi Rob/Nicolas,

> Also, fwiw, you probably need more output buffers when you get a bit
> further, to have correct results.. at least if it is not a pure
> I-frame stream. The codec is still using the output buffers as
> reference frames until they are unlocked (show up in freeBufID[]
> array).

Thanks for your advice - it turns out I was incorrectly extracting the
H264 frames from the file because I had failed to use the BSF feature
of libav.

You are correct about the output buffers - I was aware of that, but
since the first frame was failing to decode I hadn't got around to
fixing that up yet.

Thanks for your help.

Regards,
Andre

[miaomia...@gmail.com]

HI,

"VIDDEC3_process is consistently returning -1, and extended error is set to 0x401"

 does this method can be  work at last?

can you provide a demo example?  i will be grateful  to you.....

在 2012年8月2日星期四UTC+8下午1时23分54秒，Andre Renaud写道：

[Vladimir Pantelic]

miaomia...@gmail.com wrote:
> HI,
> "VIDDEC3_process is consistently returning -1, and extended error is
> set to 0x401"
> does this method can be work at last?
> can you provide a demo example? i will be grateful to you.....

make your input buffer bigger, maybe 300x400 is not enough

[Vladimir Pantelic]

sprintf(filename, "../tester/output-%3.3d.yuv", i);
fp = fopen(filename, "rb");


why are you passing YUV data to the decoder?

> --
> You received this message because you are subscribed to the Google
> Groups "pandaboard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pandaboard+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>