video_decoder (and others): Allow using an empty buffer with EOS flag to signal EOS and drain the component

[sdroege]

Hi,

it would be really great if it would be possible to signal EOS to video_decode (and other components) by passing an empty (nFilledLen=0) buffer with the EOS flag to the input port. The output port would then either first output all frames that can still be output and set the EOS flag on the last of them, or would just output an empty buffer with the EOS flag if there are no frames pending (alternatively: always put the EOS flag on an empty buffer instead of the last buffer). It's just important that, no matter what, a buffer with the EOS flag is output.

This would allow to drain the component and make it possible to ensure that no buffers are ever lost. Useful for example when switching from one video stream to another.

This behaviour is not described anywhere in the spec (and does not conflict with anything in the spec) but many other OpenMAX IL implements provide this behaviour. Also it should not break any existing software as it needs to be triggered by something that previously had no effect at all, and is probably quite easy to implement.

[popcornmix]

As far as I can tell zero length packets are supported, and these can contain OMX_BUFFERFLAG_EOS, and that will put the component into EOS state.
How is this not working?
Do you believe sending final packet with OMX_BUFFERFLAG_EOS set behaves differently from sending final packet without OMX_BUFFERFLAG_EOS set, followed by zero length packet with OMX_BUFFERFLAG_EOS set ?

[sdroege]

It's not guaranteed that you get an output buffer with the EOS flag set. If there are no pending output buffers, the empty EOS buffer is simply ignored and never produces any output.

[popcornmix]

Are you saying you don't get an OMX_EventBufferFlag with OMX_BUFFERFLAG_EOS set callback?

[sdroege]

Yes, neither an OMX_EventBufferFlag (on any port) nor an empty buffer with the EOS flag set.

I don't get either of these at any time if I pass a non-empty or empty buffer to the input port of video_decode with the EOS flag set.

[sdroege]

But I get OMX_EventBufferFlag in hello_video on the video_render input port and also on the video_decode output port. In my case I grab buffers directly from the video_decode output port without tunneling to any other component, maybe that's the problem?

[sdroege]

http://pastebin.com/1nr5PHiA

Simple testcase based on hello_video with all the other components removed. This hangs forever after the EOS buffer is sent.

Changing (the normal) hello_video to wait for EOS on the video_decode output port works fine though so it must be something with the tunneling.

[popcornmix]

From OpenMax guy:
"We definitely support empty input buffers with EOS in non-tunnelled mode.

I believe the issue here is that the event we're sending is not the one expected by the test code. In the event, we send the full buffer nFlags field while the tests code is filtering exclusively for OMX_BUFFERFLAG_EOS.

So that line:
ilclient_wait_for_event(video_decode, OMX_EventBufferFlag, 131, 0, OMX_BUFFERFLAG_EOS, 0,
ILCLIENT_BUFFER_FLAG_EOS, 10000);
should be changed into:
ilclient_wait_for_event(video_decode, OMX_EventBufferFlag, 131, 0, 0, 1,
ILCLIENT_BUFFER_FLAG_EOS, 10000);"

[sdroege]

That doesn't work either. There is no event arriving after the empty EOS buffer is passed to the component, if you add a printf() to ilclient_event_handler() you'll see that.

[sdroege]

Ok, I got it working with hello_video now but not with my own code. I don't see the difference between the two, but this is the difference in the logs.

For hello_video:
[...]
2765710.664: video_decode:3:FillThisBuffer(f479740,0,131->0)
2765710.687: video_decode:3: queueBuffer (output : 0)
2765710.699: video_decode:3:qb RIL:1
2770396.707: video_decode:3:EmptyThisBuffer(f463760,0,0->130)
2770396.725: video_decode:3: queueBuffer (input : 0)
2770396.741: video_decode:3:qb RIL:1
2770396.766: video_decode:3:RIL: extract from fifo: len:0 flags:101
2770396.805: video_decode:3:cb:consumed_input_buffer(f463760,0b,0f) RIL:1
2770410.337: video_decode:3:RIL: eos
2770410.533: video_decode:3:RIL:cb:entered with buffer = 0xf4646a8, frame_info = 0xf471f90, status = 0, cb= 0x0
2770410.614: video_decode:3:RIL:cb:P time:0, cb:0x0, ar:0/0, crop:0x0 1920x1080, interval:0, interlace:0,0,0
2770410.657: video_decode:3:RIL:cb:entered with buffer = 0xf4646e8, frame_info = 0xf471e60, status = 0, cb= 0x0
2770410.670: video_decode:3:RIL: eos
[... draining the component]

For my code:
[...]
796215.502: video_decode:2:FillThisBuffer(f479740,0,131->0)
796215.521: video_decode:2: queueBuffer (output : 0)
796215.534: video_decode:2:qb RIL:1
796218.587: video_decode:2:EmptyThisBuffer(f463060,0,0->130)
796218.605: video_decode:2: queueBuffer (input : 0)
796218.628: video_decode:2:saveBuffer(130,f463060) Held:1
796225.796: video_decode:2:timer retry on 130
796225.822: video_decode:2:sendBuffers(130):f463060 0/0
and nothing happens.

"saveBuffer" or "timer retry" is nowhere in the logs for hello_video.

[sdroege]

Nevermind, it was a stupid bug in my own code.