Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with encoding #22

Closed
leavittx opened this issue Mar 27, 2017 · 1 comment
Closed

Problem with encoding #22

leavittx opened this issue Mar 27, 2017 · 1 comment

Comments

@leavittx
Copy link

leavittx commented Mar 27, 2017

I've made a simple encoding app, with code very similar to api2-decode-encode-video.cpp.
The only difference is that I don't really need an output Stream, since I want to manually operate on encoded packets.
The first problem that I see is that there is no VideoEncoderContext constructor which doesn't require a Stream parameter (I mean there is, but it will lead to problems, no such example provided). So maybe there should be a constructor for such scenario, shouldn't it?

Even when I create a fake output Stream, avcodec_receive_frame (codeccontext.cpp, int decode(AVCodecContext *avctx, AVFrame *picture, int *got_picture_ptr, const AVPacket *avpkt), returns AVERROR(EAGAIN) during roughly first 50 decode() calls, although I seem to provide correct input data to it.

I assume it should return valid packet every time a new frame is provided to avcodec_send_packet, shouldn't it? Any ideas on that?

Libavcodec version 57.80.100, target platform Windows 10 64-bit (visual studio toolchain is used)

@h4tr3d
Copy link
Owner

h4tr3d commented Mar 28, 2017

Uh... browser drop my anwer. In short: not an issue, just a WAD.

Some codecs has Delay in some amount of frames. Delay - major thing. In some cases Delay requires by performance optimization or by codec design itself (B-frames).

So, in some cases you should put some amount of packets to the codec before receive first decoded frame. Count of packets that sends to codec before first frame is a codec Delay. As a result, avcodec_receive_frame() can produce EAGAIN error for a some time.

Also, after input stream finished you must put some amount null packets to drain codecs and receive leftover frames. You should do it until EAGAIN (in my API: I do not put null packet to the codec, so it does not moves to flush state, basically it is an error) or AVERROR_EOF.

For more details see:

@h4tr3d h4tr3d closed this as completed May 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants