On 09/05/2017 09:16 AM, Jorge Ramirez wrote:
On 09/05/2017 12:16 AM, Mark Thompson wrote:
On 04/09/17 22:55, Jorge Ramirez wrote:
On 09/04/2017 11:29 PM, Mark Thompson wrote:
... stuff ...
So the sequence of calls is:
send_frame(frame 0) -> success
receive_packet() -> EAGAIN
send_frame(frame 1) -> success
receive_packet() -> EAGAIN
...
send_frame(frame 15) -> success
receive_packet() -> EAGAIN
send_frame(frame 16) -> success
receive_packet() -> packet 0
receive_packet() -> packet 1
...
receive_packet() -> packet 15
receive_packet() -> packet 16
receive_packet() -> blocks
This appears correct to me - since EAGAIN has not been returned by
a receive_packet() call, it can be called again repeatedly (as
documented in avcodec.h). Do you disagree?
I would have expected that after a packet is received, a new frame
is enqueued instead of executing again receive_packet (why do we
that? what is the benefit?)
under these circumsntances I can't block in receive_packet blindly,
I have to track in user-space what the driver has in its guts and
predict how much it needs to keep working....I dont think it is a
good idea.
Feel free to submit a patch to avcodec.h which changes the definition
of the API.
no, that is ok. I can work around it easily (maybe v4l2 has special
needs compared to the rest of ffmpeg)
I think that the problem is that you are only polling on the frame
buffer queue when blocking, so you don't see the packet buffers
becoming free in the packet buffer queue - if you did see and
dequeue them, you would then return EAGAIN to indicate that more
input is needed. (See comments in
<e4c6a8d7-798a-dfdb-b748-42936e944...@jkqxz.net>.)
I could manually track it that way with additional counters - so
before blocking I could see count many frames are enqueued in the
input and if there is not at least one I could just return EAGAIN.
but the behaviour differs from encoding.
The behaviour is identical. You return the output buffer if there is
one available on the output queue, otherwise you return EAGAIN if
there is any space on the input queue, otherwise you block waiting
for either of those to become possible.
I made some modifications to the way I was dequeuing buffers so now it
polls for both input and output queues. you were right, things work much
smoother this way...thanks.
having said that I still I find the encoding API wrongly defined (no
need for two calls that are in fact highly couple to each other in my
opinion)
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
