Backward seeking fails (same with Bellagio)

[gpalsingh]

While seeking backward/forward sometimes this error is thrown in the terminal and the video stops playing
0:00:10.229635666 2922 0x22f5a80 ERROR omx gstomx.c:1571:gst_omx_port_set_flushing:<omxh264dec-omxh264dectiz0> Timeout while flushing avc port 1

[CapOM]

Try to rebase to latest gst-omx there is a fix https://cgit.freedesktop.org/gstreamer/gst-omx/commit/?id=64f7f781d8cc95602008fd1a96a01251a26147e8 . Maybe it will help. (if some conflict with git rebase with OMX_UseEGLImage (now pushed upstream), please type: git rebase --skip to skip that obsolete patch locally)

[gpalsingh]

Still not working. Tried with this branch https://github.com/gpalsingh/gst-omx/tree/seek_fail

[gpalsingh]

0bf16f1 fixes the crash for me though. I get the "No corresponding frame found" error but the video runs fine. So I think this can be marked as resolved?

[CapOM]

Do you mean a crash after the ERROR timeout flushing above ?

[gpalsingh]

Yes, now it doesn't stop the video execution.

[CapOM]

Does the ERROR happens with 'tee' in between decoder and video converter ? With the tee it blocks allocation query to it will use OMX_AllocateBuffer. Without it will use OMX_UseBuffer. (dec ! tee ! video converter ...)

[gpalsingh]

No port flush error seen. Tested with pipeline:

gst-launch-1.0 filesrc location=~/mp4_tests/10\ Second\ countdown.mp4.mp4 ! qtdemux ! navseek seek-offset=2 ! h264parse ! omxh264dec ! tee ! videoconvert ! ximagesink

[CapOM]

Could you rename the issue to "Seeking frequently fails when using downstream buffer pool" ?

Since this is an advance feature, this issue now does not block the send patches for review on mesa-dev.
I will have a look to this issue next week since it is most likely a join pb with gst-omx.

[gpalsingh]

Ah I just realised you meant the ERROR happens with 'tee' when not using this patch. I tested it and in this case the port flush error does occur.

[CapOM]

Does moving navseek just before ximagesink solves the issue ?

[gpalsingh]

Same results as before.
Pipeline:

gst-launch-1.0 filesrc location=~/mp4_tests/10\ Second\ countdown.mp4.mp4 ! qtdemux ! h264parse ! omxh264dec ! tee ! videoconvert ! navseek seek-offset=2 ! ximagesink

Testing with the existing bellagio state tracker I observed the same behaviour. Backward seeking throws this error:

ERROR            omxvideodec gstomxvideodec.c:1567:gst_omx_video_dec_loop:<omxh264dec-omxh264dectiz0> No corresponding frame found

but doesn't affect the video playback.
Forward seeking works fine. Forward seeking works most of the times but there is a chance to throw the same error above sometimes.
Since both decoders (old and new) have same behaviour I suppose this can be closed or not high priority?

[CapOM]

Yes. I see now and I could reproduce. Thx for checking. Then rename issue to: backward seeking fails (same with Bellagio). And yes not a priority anymore