example api2-decode fail about avcpp HOT 9 OPEN

Are you using the latest release or a git checkout? I fixed a number of small problems related to these examples very recently. Try compiling a vanilla ffmpeg 6.1 and try transcoding file to file, if this doesn't work, then there is a problem.

from avcpp.

'-11' means EAGAIN. You can try to make access again, something like:

if (ec) {
  if (ec == av::make_ffmpeg_condition(-EGAIN)) {
    continue;
  }
  ...
}

from avcpp.

I git pull the latest commit from the master branch. The last commit is Dec 21.
As I said, if I use ffmpeg command line to transcoe, it is working. Does this mean there is no problem with
the rockchip-mpp backend?

Are you using the latest release or a git checkout? I fixed a number of small problems related to these examples very recently. Try compiling a vanilla ffmpeg 6.1 and try transcoding file to file, if this doesn't work, then there is a problem.

from avcpp.

Are you sure, I found return code <0 is error in the document.

In common way - you are right. But there is cases, when, for example, data is not ready yet but system work properly and you should just a wait a little. EBUSY, EAGAIN just a way say it.

In any case, HW can just stuck and maybe some proper configuration is needed in additional to generic SW setup.

from avcpp.

Are you sure, I found return code <0 is error in the document.

In common way - you are right. But there is cases, when, for example, data is not ready yet but system work properly and you should just a wait a little. EBUSY, EAGAIN just a way say it.

In any case, HW can just stuck and maybe some proper configuration is needed in additional to generic SW setup.

The original code is something like this

while (Packet pkt = ictx.readPacket(ec)) {
//some other code here
VideoFrame frame = vdec.decode(pkt, ec);
//some other code here
}

You mean I should do a while in the while? eg, do a while loop after each packet or do it on the read packet & decode together?

from avcpp.

Are you sure, I found return code <0 is error in the document.

In common way - you are right. But there is cases, when, for example, data is not ready yet but system work properly and you should just a wait a little. EBUSY, EAGAIN just a way say it.
In any case, HW can just stuck and maybe some proper configuration is needed in additional to generic SW setup.

The original code is something like this

while (Packet pkt = ictx.readPacket(ec)) {
//some other code here
VideoFrame frame = vdec.decode(pkt, ec);
//some other code here
}

You mean I should do a while in the while? eg, do a while loop after each packet or do it on the read packet & decode together?

I have tried doing a for loop on VideoFrame frame = vdec.decode(pkt, ec); but it never stops after get -11 return value.

from avcpp.

Are you sure, I found return code <0 is error in the document.

In common way - you are right. But there is cases, when, for example, data is not ready yet but system work properly and you should just a wait a little. EBUSY, EAGAIN just a way say it.
In any case, HW can just stuck and maybe some proper configuration is needed in additional to generic SW setup.

The original code is something like this

while (Packet pkt = ictx.readPacket(ec)) {
//some other code here
VideoFrame frame = vdec.decode(pkt, ec);
//some other code here
}

You mean I should do a while in the while? eg, do a while loop after each packet or do it on the read packet & decode together?

Neither of the two approaches work. But if I use ffmpeg command line to do anything, decode or transcode. It is working.
With the vallina ffmpeg compiled, this is no problem.

from avcpp.

An update again. I have tried the example code of decode_video.c in the official ffmpeg repo under /doc/examples.
This example program is working with ffmpeg-mpp. So it is highly possible that there is some problem with api2-decode here.

from avcpp.

@ywangwxd , could you please send me a sample of the problematic video? Also, issue are mpp related only? Does video successfully processed by the software decoder?

from avcpp.