[Bug 759043] gst-omx: Timeout waiting for egl_render port 221 buffer release triggers subsequent "Insufficient resources" errors

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759043

--- Comment #10 from Enrique Ocaña González <eocanha at igalia.com> ---
Created attachment 358136
  --> https://bugzilla.gnome.org/attachment.cgi?id=358136&action=edit
New test case results

First of all, the original error reported by the bug isn't reproducible anymore
on the VideoChangeRate test from YouTube 2015[1] nor YouTube 2016[2] MSE tests
using gst-omx 1.10.4. Something might have changed in our WebKit implementation
or in gst-omx since the bug was reported.

However, the patch I originally proposed is still relevant. Without it, the
call to gst_omx_video_dec_set_format() still fails in the middle of a video
(few times) or at the end of it (more frequently).

> Could you explain why in the attached "Test case results" you said to seek near > the end of the video, i.e. 4.08 (the video has a duration of 4:14) but then in > log the error happens around 0.36 ?

0.36 is the time the application has been running. I seeked to 4.08 as soon as
I started the test, so didn't wait 4 minutes for the player to reach that
position by itself.

I'm attaching a new log, where I seeked to 4:07 (movie time) at ~27 GStreamer
run time. Selected log lines follow:

0:00:27.120713323   569 0x71102380 DEBUG           videodecoder
gstvideodecoder.c:1396:gst_video_decoder_sink_event:<omxh264dec-omxh264dec0>
received event 2563, flush-start
0:00:27.272474729   569  0x1872430 DEBUG           videodecoder
gstvideodecoder.c:849:gst_video_decoder_push_event:<omxh264dec-omxh264dec0>
segment time segment start=0:04:07.000000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x01,
time=0:04:07.000000000, base=0:00:00.000000000, position 0:04:07.000000000,
duration 99:99:99.999999999

Then, at some point there's a change in the caps (only framerate) which causes
an error:

0:00:28.375073270   569  0x174c090 DEBUG           videodecoder
gstvideodecoder.c:703:gst_video_decoder_setcaps:<omxh264dec-omxh264dec0>
Checking if caps changed old video/x-h264, stream-format=(string)byte-stream,
alignment=(string)au, level=(string)4, profile=(string)high, width=(int)1920,
height=(int)1012, pixel-aspect-ratio=(fraction)1/1,
framerate=(fraction)50000/1677, parsed=(boolean)true new video/x-h264,
stream-format=(string)byte-stream, alignment=(string)au, level=(string)4,
profile=(string)high, width=(int)1920, height=(int)1012,
pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)89/3,
parsed=(boolean)true
0:00:32.633606862   569  0x174c090 ERROR                    omx
gstomx.c:1978:gst_omx_port_wait_buffers_released_unlocked:<omxh264dec-omxh264dec0>
Timeout waiting for egl_render port 221 to release all buffers
0:00:32.633974987   569  0x174c090 WARN            videodecoder
gstvideodecoder.c:745:gst_video_decoder_setcaps:<omxh264dec-omxh264dec0>
Subclass refused caps

And the errors reappear since then, putting the pipeline in an error state and
probably causing an EOS:

0:00:32.666314102   569  0x174c090 DEBUG           videodecoder
gstvideodecoder.c:1396:gst_video_decoder_sink_event:<omxh264dec-omxh264dec0>
received event 28174, eos

Suprisingly, a new segment is sent to the pipeline after that:

0:00:33.463679154   569 0x6ce04ef0 DEBUG           videodecoder
gstvideodecoder.c:849:gst_video_decoder_push_event:<omxh264dec-omxh264dec1>
segment time segment start=0:00:00.000000000, offset=0:00:00.000000000,
stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00,
time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000,
duration 99:99:99.999999999

But the pipeline is already in an error state.

[1]
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2015.html?enablewebm=false&command=run&tests=37
[2]
http://yt-dash-mse-test.commondatastorage.googleapis.com/unit-tests/2016.html?enablewebm=false&command=run&tests=37

And nothing of this happens with the patch I originally proposed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.