New hang on startup for omxh264enc

[Graham Leggett]

Hi all,

Having rebuilt the full gstreamer master stack using gcc v6.2.0, I am now finding my gstreamer pipeline refusing to finally enter the PLAYING state as it hangs inside omxh264enc.

Most specifically, inside here:

#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x7353678c in gst_omx_component_wait_message (comp=0x742acc00, timeout=18446744073709551615) at gstomx.c:441
#3  0x73541a94 in gst_omx_port_acquire_buffer (port=0x709aaeb0, buf=0x62afed00) at gstomx.c:1342
#4  0x73578dc4 in gst_omx_video_enc_loop (self=0x70b7e180) at gstomxvideoenc.c:649

If I’m reading this correctly, data is being sent to the omxh264enc inside gst_omx_video_enc_handle_frame(), but data isn’t coming out of the graphics card, and so gst_omx_video_enc_loop() is starved and hangs.

The pipeline stalls and nothing is output by the encoder.

This seems to be an improvement on before - the stream hangs on startup, instead of hanging randomly at some point in the stream. Does this make sense to anyone?

Starting program: /usr/local/bin/gst-launch-1.0 --gst-debug-no-color --gst-debug=1,omxh264dec:1,omxvideoenc:5,omxh264enc:5,videoencoder:1,mpegtsmux:5,decodebin:1,encodebin:1,hlssink:5 udpsrc multicast-iface=eth0 uri=udp://239.106.0.7:1234 caps=application/x-rtp,media=\(string\)video,clock-rate=\(int\)90000 \! rtpbin \! rtpmp2tdepay \! progressreport update-freq=5 \! tdttsparse modulo=10 \! transcoder name=transcoder \! hlssink target-duration=0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
warning: File "/usr/local/gcc-6.2.0/lib/libstdc++.so.6.0.22-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /usr/local/gcc-6.2.0/lib/libstdc++.so.6.0.22-gdb.py
line to your configuration file "/home/minfrin/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/minfrin/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
Setting pipeline to PAUSED ...
0:00:03.042270482 23383 0x74080f40 DEBUG                hlssink gsthlssink.c:221:gst_hls_sink_create_elements:<hlssink0> Creating internal elements
0:00:03.423675100 23383 0x74080f40 ERROR             transcoder gsttranscoder.c:345:gst_transcoder_start:<transcoder> Could not sync state with parent <encodebin0>
[New Thread 0x6f369430 (LWP 23388)]
Pipeline is live and does not need PREROLL ...
[New Thread 0x6eb69430 (LWP 23389)]
Setting pipeline to PLAYING ...
[New Thread 0x6e369430 (LWP 23390)]
New clock: GstSystemClock
[New Thread 0x6d9ff430 (LWP 23391)]
[New Thread 0x6d1ff430 (LWP 23392)]
[New Thread 0x6c9ff430 (LWP 23393)]
[New Thread 0x6c1ff430 (LWP 23394)]
[New Thread 0x6b9ff430 (LWP 23395)]
[New Thread 0x6b1ff430 (LWP 23396)]
progressreport0 (00:00:06): 0 seconds
[New Thread 0x680ff430 (LWP 23397)]
[New Thread 0x678ff430 (LWP 23398)]
[New Thread 0x670ff430 (LWP 23399)]
[New Thread 0x668ff430 (LWP 23400)]
[New Thread 0x660ff430 (LWP 23401)]
[New Thread 0x658ff430 (LWP 23402)]
[New Thread 0x64cff430 (LWP 23403)]
[New Thread 0x642ff430 (LWP 23404)]
[New Thread 0x63aff430 (LWP 23405)]
0:00:12.101218752 23383 0x740d1350 ERROR            omxvideodec gstomxvideodec.c:971:gst_omx_video_dec_reconfigure_output_port:<omxh264dec-omxh264dec0> Failed to negotiate RGBA for EGLImage
0:00:12.408587035 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:958:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Setting new format I420
0:00:12.409925822 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1087:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Setting inport port definition
0:00:12.412199181 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1137:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Updating outport port definition
0:00:12.412589437 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1157:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Enabling component
0:00:12.415281489 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1238:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Starting task again
[New Thread 0x62aff430 (LWP 23406)]
0:00:12.433234616 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:663:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Port settings have changed, updating caps
0:00:12.433906275 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:695:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Setting output state: video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)high, level=(string)4
0:00:12.439330379 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000480 0
0:00:12.439576887 23383 0x7409bcf0 DEBUG             omxh264enc gstomxh264enc.c:618:gst_omx_h264_enc_handle_output_frame:<omxh264enc-omxh264enc0> got codecconfig in byte-stream format
0:00:12.439692614 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: ok
0:00:12.440072193 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component
0:00:12.440158963 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:753:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Handling buffer: 0x00000490 0
0:00:12.440265108 23383 0x7409bcf0 DEBUG             omxh264enc gstomxh264enc.c:618:gst_omx_h264_enc_handle_output_frame:<omxh264enc-omxh264enc0> got codecconfig in byte-stream format
0:00:12.440353076 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:762:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Finished frame: ok
0:00:12.440621874 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:770:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Read frame from component
0:00:12.608644523 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:958:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Setting new format I420
0:00:12.609166183 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:970:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Need to disable and drain encoder
0:00:12.609275192 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1692:gst_omx_video_enc_drain:<omxh264enc-omxh264enc0> Draining component
0:00:12.609341910 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1697:gst_omx_video_enc_drain:<omxh264enc-omxh264enc0> Component not started yet
0:00:12.609746020 23383 0x7409bcf0 DEBUG            omxvideoenc gstomxvideoenc.c:793:gst_omx_video_enc_loop:<omxh264enc-omxh264enc0> Flushing -- stopping task
0:00:12.612047244 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1013:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Encoder drained and disabled
0:00:12.613388687 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1087:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Setting inport port definition
0:00:12.615478038 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1137:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Updating outport port definition
0:00:12.615878346 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1157:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Enabling component
0:00:12.617371766 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1238:gst_omx_video_enc_set_format:<omxh264enc-omxh264enc0> Starting task again

We freeze here, stuck inside gst_omx_port_acquire_buffer() here:

  g_mutex_lock (&comp->lock);

0:00:12.620258868 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.620434595 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1553:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.623845129 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1612:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Passed frame to component
0:00:12.625159332 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.625305633 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1553:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.629325899 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1612:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Passed frame to component
0:00:12.630598905 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.630763643 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1553:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.633904232 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1612:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Passed frame to component
0:00:12.635201092 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.635347601 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1553:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
0:00:12.636755553 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1612:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Passed frame to component
0:00:12.637996997 23383 0x7409ac00 DEBUG            omxvideoenc gstomxvideoenc.c:1460:gst_omx_video_enc_handle_frame:<omxh264enc-omxh264enc0> Handling frame
progressreport0 (00:00:11): 10 seconds
progressreport0 (00:00:16): 15 seconds
progressreport0 (00:00:21): 20 seconds
^C
Program received signal SIGINT, Interrupt.
0x76429b84 in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) thread apply all bt

Thread 20 (Thread 0x62aff430 (LWP 23406)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x7353678c in gst_omx_component_wait_message (comp=0x742acc00, timeout=18446744073709551615) at gstomx.c:441
#3  0x73541a94 in gst_omx_port_acquire_buffer (port=0x709aaeb0, buf=0x62afed00) at gstomx.c:1342
#4  0x73578dc4 in gst_omx_video_enc_loop (self=0x70b7e180) at gstomxvideoenc.c:649
#5  0x768ac5fc in gst_task_func (task=0x709df0d0) at gsttask.c:334
#6  0x768af904 in default_func (tdata=0x74ab3f20, pool=0x74209858) at gsttaskpool.c:68
#7  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 19 (Thread 0x63aff430 (LWP 23405)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x7353678c in gst_omx_component_wait_message (comp=0x742acc00, timeout=18446744073709551615) at gstomx.c:441
#3  0x73541a94 in gst_omx_port_acquire_buffer (port=0x709aae18, buf=0x63afd260) at gstomx.c:1342
#4  0x735824fc in gst_omx_video_enc_handle_frame (encoder=0x70b7e180, frame=0x709df3f0) at gstomxvideoenc.c:1476
#5  0x6f7ac8b0 in gst_video_encoder_chain (pad=0x68671028, parent=0x70b7e180, buf=0x709492d8) at gstvideoencoder.c:1457
#6  0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68671028, type=4112, data=0x709492d8) at gstpad.c:4206
#7  0x767f83e4 in gst_pad_push_data (pad=0x68671418, type=4112, data=0x709492d8) at gstpad.c:4458
#8  0x767f9ca0 in gst_pad_push (pad=0x68671418, buffer=0x709492d8) at gstpad.c:4577
#9  0x6fe7a1b4 in gst_base_transform_chain (pad=0x686712c8, parent=0x70b42c40, buffer=0x709492d8) at gstbasetransform.c:2378
#10 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x686712c8, type=4112, data=0x709492d8) at gstpad.c:4206
#11 0x767f83e4 in gst_pad_push_data (pad=0x68671e98, type=4112, data=0x709492d8) at gstpad.c:4458
#12 0x767f9ca0 in gst_pad_push (pad=0x68671e98, buffer=0x709492d8) at gstpad.c:4577
#13 0x730171b0 in gst_video_rate_flush_prev (videorate=0x70b88278, duplicate=1, next_intime=8399088448) at gstvideorate.c:707
#14 0x7301d910 in gst_video_rate_transform_ip (trans=0x70b88278, buffer=0x70953288) at gstvideorate.c:1434
#15 0x6fe78320 in default_generate_output (trans=0x70b88278, outbuf=0x63afdce0) at gstbasetransform.c:2184
#16 0x6fe79ab4 in gst_base_transform_chain (pad=0x68671d48, parent=0x70b88278, buffer=0x70953288) at gstbasetransform.c:2342
#17 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68671d48, type=4112, data=0x70953288) at gstpad.c:4206
#18 0x767f83e4 in gst_pad_push_data (pad=0x68671bf8, type=4112, data=0x70953288) at gstpad.c:4458
#19 0x767f9ca0 in gst_pad_push (pad=0x68671bf8, buffer=0x70953288) at gstpad.c:4577
#20 0x6fe7a1b4 in gst_base_transform_chain (pad=0x68671aa8, parent=0x70b84630, buffer=0x70953288) at gstbasetransform.c:2378
#21 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68671aa8, type=4112, data=0x70953288) at gstpad.c:4206
#22 0x767f83e4 in gst_pad_push_data (pad=0x68671958, type=4112, data=0x70953288) at gstpad.c:4458
#23 0x767f9ca0 in gst_pad_push (pad=0x68671958, buffer=0x70953288) at gstpad.c:4577
#24 0x6fe7a1b4 in gst_base_transform_chain (pad=0x68671808, parent=0x70b38e48, buffer=0x70953288) at gstbasetransform.c:2378
#25 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68671808, type=4112, data=0x70953288) at gstpad.c:4206
#26 0x767f83e4 in gst_pad_push_data (pad=0x686716b8, type=4112, data=0x70953288) at gstpad.c:4458
#27 0x767f9ca0 in gst_pad_push (pad=0x686716b8, buffer=0x70953288) at gstpad.c:4577
#28 0x6fe7a1b4 in gst_base_transform_chain (pad=0x68671568, parent=0x70b842f0, buffer=0x70953288) at gstbasetransform.c:2378
#29 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68671568, type=4112, data=0x70953288) at gstpad.c:4206
#30 0x767f83e4 in gst_pad_push_data (pad=0x68676040, type=4112, data=0x70953288) at gstpad.c:4458
#31 0x767f9ca0 in gst_pad_push (pad=0x68676040, buffer=0x70953288) at gstpad.c:4577
#32 0x73de2628 in gst_stream_splitter_chain (pad=0x68665ab0, parent=0x709c4840, buf=0x70953288) at gststreamsplitter.c:140
#33 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x68665ab0, type=4112, data=0x70953288) at gstpad.c:4206
#34 0x767f83e4 in gst_pad_push_data (pad=0x68665d50, type=4112, data=0x70953288) at gstpad.c:4458
#35 0x767f9ca0 in gst_pad_push (pad=0x68665d50, buffer=0x70953288) at gstpad.c:4577
---Type <return> to continue, or q <return> to quit---
#36 0x6f5ea310 in gst_queue_push_one (queue=0x70b7a1a0) at gstqueue.c:1359
#37 0x6f5ed80c in gst_queue_loop (pad=0x68665d50) at gstqueue.c:1506
#38 0x768ac5fc in gst_task_func (task=0x709bd6b8) at gsttask.c:334
#39 0x768af904 in default_func (tdata=0x74ab6740, pool=0x74209858) at gsttaskpool.c:68
#40 0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 18 (Thread 0x642ff430 (LWP 23404)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x6f5ec470 in gst_queue_loop (pad=0x686652d0) at gstqueue.c:1494
#3  0x768ac5fc in gst_task_func (task=0x709bd610) at gsttask.c:334
#4  0x768af904 in default_func (tdata=0x74ab64d8, pool=0x74209858) at gsttaskpool.c:68
#5  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 17 (Thread 0x64cff430 (LWP 23403)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x7353678c in gst_omx_component_wait_message (comp=0x7426ec60, timeout=18446744073709551615) at gstomx.c:441
#3  0x73541a94 in gst_omx_port_acquire_buffer (port=0x709aa8c0, buf=0x64cfebe0) at gstomx.c:1342
#4  0x73563acc in gst_omx_video_dec_loop (self=0x70b74180) at gstomxvideodec.c:1259
#5  0x768ac5fc in gst_task_func (task=0x709402c8) at gsttask.c:334
#6  0x768af904 in default_func (tdata=0x74ab6d90, pool=0x74209858) at gsttaskpool.c:68
#7  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 16 (Thread 0x658ff430 (LWP 23402)):
#0  0x764b0a40 in do_futex_wait (isem=isem@entry=0x707b45dc) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1  0x764b0af4 in __new_sem_wait (sem=0x707b45dc) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2  0x73511b60 in vchiu_queue_pop () from /opt/vc/lib/libvchiq_arm.so
#3  0x73210d70 in ilcs_task () from /opt/vc/lib/libopenmaxil.so
#4  0x73702cc4 in vcos_thread_entry (arg=0x707b4498) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#5  0x764a9e90 in start_thread (arg=0x658ff430) at pthread_create.c:311
#6  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 15 (Thread 0x660ff430 (LWP 23401)):
#0  0x764ae7a4 in __pthread_cond_wait (cond=cond@entry=0x707b4448, mutex=mutex@entry=0x707b442c) at pthread_cond_wait.c:187
#1  0x73702da8 in _timer_thread (arg=0x707b4428) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:722
#2  0x764a9e90 in start_thread (arg=0x660ff430) at pthread_create.c:311
#3  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 14 (Thread 0x668ff430 (LWP 23400)):
#0  0x764b0a40 in do_futex_wait (isem=isem@entry=0x73275a64 <cecservice_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1  0x764b0af4 in __new_sem_wait (sem=0x73275a64 <cecservice_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2  0x7325c620 in cecservice_notify_func () from /opt/vc/lib/libbcm_host.so
#3  0x73702cc4 in vcos_thread_entry (arg=0x73275a78 <cecservice_notify_task>) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
---Type <return> to continue, or q <return> to quit---
#4  0x764a9e90 in start_thread (arg=0x668ff430) at pthread_create.c:311
#5  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 13 (Thread 0x670ff430 (LWP 23399)):
#0  0x764b0a40 in do_futex_wait (isem=isem@entry=0x73274cdc <tvservice_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1  0x764b0af4 in __new_sem_wait (sem=0x73274cdc <tvservice_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2  0x7325baa0 in tvservice_notify_func () from /opt/vc/lib/libbcm_host.so
#3  0x73702cc4 in vcos_thread_entry (arg=0x73274cf0 <tvservice_notify_task>) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#4  0x764a9e90 in start_thread (arg=0x670ff430) at pthread_create.c:311
#5  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 12 (Thread 0x678ff430 (LWP 23398)):
#0  0x764b0a40 in do_futex_wait (isem=isem@entry=0x73275b60 <dispmanx_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:48
#1  0x764b0af4 in __new_sem_wait (sem=0x73275b60 <dispmanx_notify_available_event+24>) at ../nptl/sysdeps/unix/sysv/linux/sem_wait.c:69
#2  0x7325fb2c in dispmanx_notify_func () from /opt/vc/lib/libbcm_host.so
#3  0x73702cc4 in vcos_thread_entry (arg=0x732768a0 <dispmanx_notify_task>) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#4  0x764a9e90 in start_thread (arg=0x678ff430) at pthread_create.c:311
#5  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 11 (Thread 0x680ff430 (LWP 23397)):



#0  0x7642bf2c in ioctl () at ../sysdeps/unix/syscall-template.S:81
#1  0x76ae3a10 in __interceptor_ioctl (d=11, request=3222586375) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1235
#2  0x7350f010 in completion_thread () from /opt/vc/lib/libvchiq_arm.so
#3  0x73702cc4 in vcos_thread_entry (arg=0x73522318 <vchiq_instance+16>) at /home/dc4/projects/staging/userland/interface/vcos/pthreads/vcos_pthreads.c:144
#4  0x764a9e90 in start_thread (arg=0x680ff430) at pthread_create.c:311
#5  0x76433598 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 10 (Thread 0x6b1ff430 (LWP 23396)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x6f5c91b8 in gst_multi_queue_loop (pad=0x74865c08) at gstmultiqueue.c:1855
#3  0x768ac5fc in gst_task_func (task=0x70930610) at gsttask.c:334
#4  0x768af904 in default_func (tdata=0x74aa3550, pool=0x74209858) at gsttaskpool.c:68
#5  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 9 (Thread 0x6b9ff430 (LWP 23395)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x6feabe04 in _gst_data_queue_wait_non_empty (queue=0x742043b8) at gstdataqueue.c:553
#3  0x6feacbc4 in gst_data_queue_pop (queue=0x742043b8, item=0x6b9fecc0) at gstdataqueue.c:595
#4  0x6f5c7a18 in gst_multi_queue_loop (pad=0x74865818) at gstmultiqueue.c:1769
#5  0x768ac5fc in gst_task_func (task=0x70930568) at gsttask.c:334
#6  0x768af904 in default_func (tdata=0x74aa33c8, pool=0x74209858) at gsttaskpool.c:68
#7  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 8 (Thread 0x6c1ff430 (LWP 23394)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x6f5c91b8 in gst_multi_queue_loop (pad=0x74865428) at gstmultiqueue.c:1855
#3  0x768ac5fc in gst_task_func (task=0x709304c0) at gsttask.c:334
#4  0x768af904 in default_func (tdata=0x74aa32a8, pool=0x74209858) at gsttaskpool.c:68
#5  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 7 (Thread 0x6c9ff430 (LWP 23393)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x7353678c in gst_omx_component_wait_message (comp=0x7426ec60, timeout=18446744073709551615) at gstomx.c:441
#3  0x73541a94 in gst_omx_port_acquire_buffer (port=0x709aa828, buf=0x6c9fda80) at gstomx.c:1342
#4  0x7356e060 in gst_omx_video_dec_handle_frame (decoder=0x70b74180, frame=0x619148a8) at gstomxvideodec.c:2215
#5  0x6f798e6c in gst_video_decoder_decode_frame (decoder=0x70b74180, frame=0x619148a8) at gstvideodecoder.c:3400
#6  0x6f78734c in gst_video_decoder_chain_forward (decoder=0x70b74180, buf=0x70931510, at_eos=0) at gstvideodecoder.c:2142
#7  0x6f78c784 in gst_video_decoder_chain (pad=0x748c1ac0, parent=0x70b74180, buf=0x70931510) at gstvideodecoder.c:2454
#8  0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x748c1ac0, type=4112, data=0x70931510) at gstpad.c:4206
#9  0x767f83e4 in gst_pad_push_data (pad=0x748652d8, type=4112, data=0x70931510) at gstpad.c:4458
#10 0x767f9ca0 in gst_pad_push (pad=0x748652d8, buffer=0x70931510) at gstpad.c:4577
#11 0x6fe7a1b4 in gst_base_transform_chain (pad=0x74865188, parent=0x70b42150, buffer=0x70931510) at gstbasetransform.c:2378
#12 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x74865188, type=4112, data=0x70931510) at gstpad.c:4206
#13 0x767f83e4 in gst_pad_push_data (pad=0x74865038, type=4112, data=0x70931510) at gstpad.c:4458
#14 0x767f9ca0 in gst_pad_push (pad=0x74865038, buffer=0x70931510) at gstpad.c:4577
#15 0x6fe05db8 in gst_base_parse_push_frame (parse=0x74272890, frame=0x740ceab0) at gstbaseparse.c:2554
#16 0x6fe03494 in gst_base_parse_handle_and_push_frame (parse=0x74272890, frame=0x740ceab0) at gstbaseparse.c:2371
#17 0x6fe07ac8 in gst_base_parse_finish_frame (parse=0x74272890, frame=0x740ceab0, size=1782) at gstbaseparse.c:2712
#18 0x73b75420 in gst_h264_parse_handle_frame (parse=0x74272890, frame=0x740ceab0, skipsize=0x6c9fe7c0) at gsth264parse.c:1246
#19 0x6fe0017c in gst_base_parse_handle_buffer (parse=0x74272890, buffer=0x7092e948, skip=0x6c9fe7c0, flushed=0x6c9fe800) at gstbaseparse.c:2179
#20 0x6fe0f978 in gst_base_parse_chain (pad=0x74858eb0, parent=0x74272890, buffer=0x70936178) at gstbaseparse.c:3255
#21 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x74858eb0, type=4112, data=0x70936178) at gstpad.c:4206
#22 0x767f83e4 in gst_pad_push_data (pad=0x74858d60, type=4112, data=0x70936178) at gstpad.c:4458
#23 0x767f9ca0 in gst_pad_push (pad=0x74858d60, buffer=0x70936178) at gstpad.c:4577
#24 0x6f5c619c in gst_single_queue_push_one (mq=0x74851570, sq=0x7310f840, object=0x70936178, allow_drop=0x6c9fed00) at gstmultiqueue.c:1611
#25 0x6f5ca3ec in gst_multi_queue_loop (pad=0x74858d60) at gstmultiqueue.c:1923
#26 0x768ac5fc in gst_task_func (task=0x70930418) at gsttask.c:334
#27 0x768af904 in default_func (tdata=0x74a9d490, pool=0x74209858) at gsttaskpool.c:68
#28 0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 6 (Thread 0x6d1ff430 (LWP 23392)):
#0  0x767f5d40 in gst_pad_chain_data_unchecked (pad=0x7483d030, type=4112, data=0x709533c8) at gstpad.c:4202
#1  0x767f83e4 in gst_pad_push_data (pad=0x7482b820, type=4112, data=0x709533c8) at gstpad.c:4458
#2  0x767f9ca0 in gst_pad_push (pad=0x7482b820, buffer=0x709533c8) at gstpad.c:4577
#3  0x743b3bc0 in mpegts_parse_input_done (base=0x74835168, buffer=0x709533c8) at mpegtsparse.c:896
#4  0x743a6410 in mpegts_base_chain (pad=0x7482b6d0, parent=0x74835168, buf=0x709533c8) at mpegtsbase.c:1611
---Type <return> to continue, or q <return> to quit---
#5  0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x7482b6d0, type=4112, data=0x709533c8) at gstpad.c:4206
#6  0x767f83e4 in gst_pad_push_data (pad=0x7483d190, type=4112, data=0x709533c8) at gstpad.c:4458
#7  0x767f9ca0 in gst_pad_push (pad=0x7483d190, buffer=0x709533c8) at gstpad.c:4577
#8  0x7679bd6c in gst_proxy_pad_chain_default (pad=0x7483a1a8, parent=0x74833048, buffer=0x709533c8) at gstghostpad.c:126
#9  0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x7483a1a8, type=4112, data=0x709533c8) at gstpad.c:4206
#10 0x767f83e4 in gst_pad_push_data (pad=0x7482b580, type=4112, data=0x709533c8) at gstpad.c:4458
#11 0x767f9ca0 in gst_pad_push (pad=0x7482b580, buffer=0x709533c8) at gstpad.c:4577
#12 0x6fe7a1b4 in gst_base_transform_chain (pad=0x7482b430, parent=0x70b1a098, buffer=0x709533c8) at gstbasetransform.c:2378
#13 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x7482b430, type=4112, data=0x709533c8) at gstpad.c:4206
#14 0x767f83e4 in gst_pad_push_data (pad=0x7482b2e0, type=4112, data=0x709533c8) at gstpad.c:4458
#15 0x767f9ca0 in gst_pad_push (pad=0x7482b2e0, buffer=0x709533c8) at gstpad.c:4577
#16 0x74bb4d64 in gst_rtp_base_depayload_push (filter=0x748300e8, out_buf=0x709533c8) at gstrtpbasedepayload.c:825
#17 0x74bb2138 in gst_rtp_base_depayload_handle_buffer (filter=0x748300e8, bclass=0x727316c0, in=0x619316f0) at gstrtpbasedepayload.c:477
#18 0x74bb29b0 in gst_rtp_base_depayload_chain (pad=0x7482b190, parent=0x748300e8, in=0x619316f0) at gstrtpbasedepayload.c:536
#19 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x7482b190, type=4112, data=0x619316f0) at gstpad.c:4206
#20 0x767f83e4 in gst_pad_push_data (pad=0x7483abb8, type=4112, data=0x619316f0) at gstpad.c:4458
#21 0x767f9ca0 in gst_pad_push (pad=0x7483abb8, buffer=0x619316f0) at gstpad.c:4577
#22 0x7679bd6c in gst_proxy_pad_chain_default (pad=0x7483db30, parent=0x7483abb8, buffer=0x619316f0) at gstghostpad.c:126
#23 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x7483db30, type=4112, data=0x619316f0) at gstpad.c:4206
#24 0x767f83e4 in gst_pad_push_data (pad=0x74858580, type=4112, data=0x619316f0) at gstpad.c:4458
#25 0x767f9ca0 in gst_pad_push (pad=0x74858580, buffer=0x619316f0) at gstpad.c:4577
#26 0x6fbc5d04 in gst_rtp_pt_demux_chain (pad=0x74858040, parent=0x70917640, buf=0x619316f0) at gstrtpptdemux.c:442
#27 0x767f5e74 in gst_pad_chain_data_unchecked (pad=0x74858040, type=4112, data=0x619316f0) at gstpad.c:4206
#28 0x767f83e4 in gst_pad_push_data (pad=0x74847d50, type=4112, data=0x619316f0) at gstpad.c:4458
#29 0x767f9ca0 in gst_pad_push (pad=0x74847d50, buffer=0x619316f0) at gstpad.c:4577
#30 0x6fba7a3c in pop_and_push_next (jitterbuffer=0x70b38320, seqnum=35057) at gstrtpjitterbuffer.c:3377
#31 0x6fba8aa4 in handle_next_buffer (jitterbuffer=0x70b38320) at gstrtpjitterbuffer.c:3476
#32 0x6fbaf6f0 in gst_rtp_jitter_buffer_loop (jitterbuffer=0x70b38320) at gstrtpjitterbuffer.c:4020
#33 0x768ac5fc in gst_task_func (task=0x70928e10) at gsttask.c:334
#34 0x768af904 in default_func (tdata=0x74a9f410, pool=0x74209858) at gsttaskpool.c:68
#35 0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 5 (Thread 0x6d9ff430 (LWP 23391)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x7658843c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x6fbaf130 in wait_next_timeout (jitterbuffer=0x70b38320) at gstrtpjitterbuffer.c:3995
#3  0x765678c4 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 4 (Thread 0x6e369430 (LWP 23390)):
#0  0x76429c40 in __GI_ppoll (fds=fds@entry=0x74639ff0, nfds=nfds@entry=1, timeout=<optimized out>, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56
#1  0x76a9d25c in __interceptor_ppoll (fds=0x74639ff0, nfds=1, timeout_ts=<optimized out>, sigmask=0x0) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3104
#2  0x76838b0c in gst_poll_wait (set=0x74205488, timeout=954719246) at gstpoll.c:1369
#3  0x76898708 in gst_system_clock_id_wait_jitter_unlocked (clock=0x74844130, entry=0x742590c8, jitter=0x0, restart=1) at gstsystemclock.c:729
#4  0x76899c20 in gst_system_clock_id_wait_jitter (clock=0x74844130, entry=0x742590c8, jitter=0x0) at gstsystemclock.c:871
#5  0x76741a0c in gst_clock_id_wait (id=0x742590c8, jitter=0x0) at gstclock.c:541
#6  0x6fc22490 in rtcp_thread (rtpsession=0x70b200d8) at gstrtpsession.c:1135
#7  0x765678c4 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 3 (Thread 0x6eb69430 (LWP 23389)):
#0  0x76429b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x76a88ea4 in __interceptor_poll (Cannot access memory at address 0x1
fds=0x746387f0, nfds=1, timeout=-1) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3085
#2  0x7653e528 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0x6f369430 (LWP 23388)):
#0  0x76429b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x76a88ea4 in __interceptor_poll (fds=0x6f368824, nfds=2, timeout=-1) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3085
#2  0x6fce8758 in g_socket_condition_timed_wait () from /usr/lib/arm-linux-gnueabihf/libgio-2.0.so.0
#3  0x74dc18fc in gst_udpsrc_create (psrc=0x70b16178, buf=0x6f368b60) at gstudpsrc.c:884
#4  0x6feb1dcc in gst_push_src_create (bsrc=0x70b16178, offset=18446744073709551615, length=4096, ret=0x6f368b60) at gstpushsrc.c:130
#5  0x6fe5c408 in gst_base_src_get_range (src=0x70b16178, offset=18446744073709551615, length=4096, buf=0x6f368d00) at gstbasesrc.c:2465
#6  0x6fe5eb64 in gst_base_src_loop (pad=0x7482b040) at gstbasesrc.c:2741
#7  0x768ac5fc in gst_task_func (task=0x70928828) at gsttask.c:334
#8  0x768af904 in default_func (tdata=0x74a99a18, pool=0x74209858) at gsttaskpool.c:68
#9  0x7656845c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76ff4000 (LWP 23383)):
#0  0x76429b84 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x76a88ea4 in __interceptor_poll (Cannot access memory at address 0x1
fds=0x74637db0, nfds=2, timeout=-1) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3085
#2  0x7653e528 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Regards,
Graham
—


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fri, 2016-11-25 at 04:16 +0200, Graham Leggett wrote:
> Hi all,
>
> Having rebuilt the full gstreamer master stack using gcc v6.2.0, I am
> now finding my gstreamer pipeline refusing to finally enter the
> PLAYING state as it hangs inside omxh264enc.
> [...]

Please file a bug :)

Might be this one here
  https://bugzilla.gnome.org/show_bug.cgi?id=774654

Also there's still the EOS/draining bug you mentioned before?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Graham Leggett]

On 25 Nov 2016, at 12:32 PM, Sebastian Dröge <[hidden email]> wrote:

> Please file a bug :)
>
> Might be this one here
>  https://bugzilla.gnome.org/show_bug.cgi?id=774654

I suspect this is the same bug I am experiencing. I created a patch to test the theory and attached it to the bug, but the patch made no difference.

> Also there's still the EOS/draining bug you mentioned before?

That one causes the pipeline to shut down, this one causes the pipeline to hang. It seems they’re independent bugs at this point.

Regards,
Graham
—


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Graham Leggett]

On 25 Nov 2016, at 12:32 PM, Sebastian Dröge <[hidden email]> wrote:

> Please file a bug :)
>
> Might be this one here
>  https://bugzilla.gnome.org/show_bug.cgi?id=774654
>
> Also there's still the EOS/draining bug you mentioned before?

Does gst-omx support dynamic resolution changes?

It appears that the hang is occurring just as the graphics card reports a resolution change, as follows:

222754.226: video_decode:3:RIL:resolution changing

Full details are here:

https://github.com/raspberrypi/firmware/issues/686

Regards,
Graham
—


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Wed, 2016-12-07 at 14:55 +0200, Graham Leggett wrote:

> On 25 Nov 2016, at 12:32 PM, Sebastian Dröge <[hidden email]
> om> wrote:
>
> > Please file a bug :)
> >
> > Might be this one here
> >  https://bugzilla.gnome.org/show_bug.cgi?id=774654
> >
> > Also there's still the EOS/draining bug you mentioned before?
>
> Does gst-omx support dynamic resolution changes?
>
> It appears that the hang is occurring just as the graphics card
> reports a resolution change, as follows:
> [...]

It does support that, and that worked at some point in the past at
least. However there might be special behaviour on the RPi, or a bug.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Graham Leggett]

On 08 Dec 2016, at 12:05 PM, Sebastian Dröge <[hidden email]> wrote:

>> Does gst-omx support dynamic resolution changes?
>>
>> It appears that the hang is occurring just as the graphics card
>> reports a resolution change, as follows:
>> [...]
>
> It does support that, and that worked at some point in the past at
> least. However there might be special behaviour on the RPi, or a bug.

After some more picking apart of the code, it seems we hang because we haven’t reconfigured the port correctly in response to OMX_EventPortSettingsChanged.

What we’re supposed to do when OMX_EventPortSettingsChanged arrives is disable the port, reconfigure, then enable the port again.

What we do instead is miss out the disable step - we attempt to reconfigure and enable only.

The reason we miss out the disable step is because the port reports itself as already disabled, and so the disable step is skipped.

It appears we might have never been enabled because the following two lines have appeared:

0:00:26.136954131 16918 0x740c8630 DEBUG            omxvideodec gstomxvideodec.c:963:gst_omx_video_dec_reconfigure_output_port:<omxh264dec-omxh264dec0> Failed to negotiate with feature memory:GLMemory
0:00:26.245094851 16918 0x740c8630 ERROR            omxvideodec gstomxvideodec.c:971:gst_omx_video_dec_reconfigure_output_port:<omxh264dec-omxh264dec0> Failed to negotiate RGBA for EGLImage

At a glance, these two log statements seem unrelated, however they appear here, where the second is a fallback after the failure of the first:

      gst_omx_port_get_port_definition (self->dec_out_port, &port_def);
      GST_VIDEO_DECODER_STREAM_LOCK (self);
      state = gst_video_decoder_set_output_state (GST_VIDEO_DECODER (self),
          GST_VIDEO_FORMAT_RGBA, port_def.format.video.nFrameWidth,
          port_def.format.video.nFrameHeight, self->input_state);

      /* at this point state->caps is NULL */
      if (state->caps)
        gst_caps_unref (state->caps);
      state->caps = gst_video_info_to_caps (&state->info);
      gst_caps_set_features (state->caps, 0,
          gst_caps_features_new (GST_CAPS_FEATURE_MEMORY_GL_MEMORY, NULL));

      /* try to negotiate with caps feature */
      if (!gst_video_decoder_negotiate (GST_VIDEO_DECODER (self))) {

        GST_DEBUG_OBJECT (self,
            "Failed to negotiate with feature %s",
            GST_CAPS_FEATURE_MEMORY_GL_MEMORY);

        if (state->caps)
          gst_caps_replace (&state->caps, NULL);

        /* fallback: try to use EGLImage even if it is not in the caps feature */
        if (!gst_video_decoder_negotiate (GST_VIDEO_DECODER (self))) {
          gst_video_codec_state_unref (state);
          GST_ERROR_OBJECT (self, "Failed to negotiate RGBA for EGLImage");
          GST_VIDEO_DECODER_STREAM_UNLOCK (self);
          goto no_egl;
        }
      }

This code then follows the no_egl path, which seems to bypass this step:

      err = gst_omx_port_set_enabled (self->dec_out_port, TRUE);
      if (err != OMX_ErrorNone)
        goto no_egl;

The decoder is now running, but in an unexpectedly “disabled” state, which throws everything off track.

It seems there are two problems, the first being that gst_video_decoder_negotiate() fails twice in a row. I suspect the error checking is naive here, the real error is discarded and we’re assuming we always fail for the same reason.

The second problem is that after failing, we plow on regardless with the card in a disabled state, which then causes our hang further down the line.

Does this make sense?

Regards,
Graham
—


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2016-12-08 at 15:58 +0200, Graham Leggett wrote:

>
> It seems there are two problems, the first being that
> gst_video_decoder_negotiate() fails twice in a row. I suspect the
> error checking is naive here, the real error is discarded and we’re
> assuming we always fail for the same reason.
>
> The second problem is that after failing, we plow on regardless with
> the card in a disabled state, which then causes our hang further down
> the line.
>
> Does this make sense?

Yes, thanks for the analysis. Can you add this information also to the
bug report, and try writing a patch for that?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Graham Leggett]

On 09 Dec 2016, at 7:54 AM, Sebastian Dröge <[hidden email]> wrote:

>> It seems there are two problems, the first being that
>> gst_video_decoder_negotiate() fails twice in a row. I suspect the
>> error checking is naive here, the real error is discarded and we’re
>> assuming we always fail for the same reason.
>>
>> The second problem is that after failing, we plow on regardless with
>> the card in a disabled state, which then causes our hang further down
>> the line.
>>
>> Does this make sense?

Looking further.

The first gst_video_decoder_negotiate() fails because the downstream omxh264enc element does not support GLMemory for some reason. It appears support for this was added to the decoder, but not the encoder. This is unfortunate but not a bug.

The second gst_video_decoder_negotiate() fails because the downstream omxh264enc element does not support RGBA. It is not clear why RGBA was chosen, given that it is not a supported input format for much of OMX. Again, in theory this is unfortunate but not a bug - or is it? Is it normal for the decoder to arbitrarily choose a single format and not leave it up to negotiation?

Given that we failed to negotiate twice, we now follow the no_egl path, however this path doesn't appear to place OMX in a state where it can renegotiate in future.

It is not yet clear to me what the no_egl path does that is different to the path that would have been taken if this RPI specific code wasn't there at all.

Despite not having successfully negotiated we plow on regardless, and the renegotiation happens because a downstream element requests I420. This renegotiation fails and thus we hang.

> Yes, thanks for the analysis. Can you add this information also to the
> bug report, and try writing a patch for that?

Happy to submit patches, but can’t until I fully understand what the correct behaviour should be first. Would it be possible to clarify what the card should be doing in this case?

To be specific, when gst_omx_video_dec_reconfigure_output_port() fails to reconfigure the output port for whatever reason, what state should the card be left in afterwards, the disabled state or the enabled state?

Regards,
Graham
—


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Sat, 2016-12-10 at 15:04 +0200, Graham Leggett wrote:

> On 09 Dec 2016, at 7:54 AM, Sebastian Dröge <[hidden email]> wrote:
>
> > > It seems there are two problems, the first being that
> > > gst_video_decoder_negotiate() fails twice in a row. I suspect the
> > > error checking is naive here, the real error is discarded and we’re
> > > assuming we always fail for the same reason.
> > >
> > > The second problem is that after failing, we plow on regardless with
> > > the card in a disabled state, which then causes our hang further down
> > > the line.
> > >
> > > Does this make sense?
>
> Looking further.
>
> The first gst_video_decoder_negotiate() fails because the downstream
> omxh264enc element does not support GLMemory for some reason. It
> appears support for this was added to the decoder, but not the
> encoder. This is unfortunate but not a bug.

Yes, adding support for EGLImage to the encoder is IIRC not possible on
the RPi though.

> The second gst_video_decoder_negotiate() fails because the downstream
> omxh264enc element does not support RGBA. It is not clear why RGBA
> was chosen, given that it is not a supported input format for much of
> OMX. Again, in theory this is unfortunate but not a bug - or is it?
> Is it normal for the decoder to arbitrarily choose a single format
> and not leave it up to negotiation?

That sounds like a bug, like a left-over from the trying of the
egl_render path. We try to set a format that downstream supports in
gst_omx_video_dec_negotiate():
  param.eColorFormat = m->type;

> Given that we failed to negotiate twice, we now follow the no_egl
> path, however this path doesn't appear to place OMX in a state where
> it can renegotiate in future.
>
> It is not yet clear to me what the no_egl path does that is different
> to the path that would have been taken if this RPI specific code
> wasn't there at all.

It should be exactly the same, not sure why anything was duplicated
there.

> > Yes, thanks for the analysis. Can you add this information also to
> > the
> > bug report, and try writing a patch for that?
>
> Happy to submit patches, but can’t until I fully understand what the
> correct behaviour should be first. Would it be possible to clarify
> what the card should be doing in this case?
>
> To be specific, when gst_omx_video_dec_reconfigure_output_port()
> fails to reconfigure the output port for whatever reason, what state
> should the card be left in afterwards, the disabled state or the
> enabled state?

If reconfiguration fails, that should probably be an error. Or is there
a way to recover from there at this point.

I thought the problem here was that the output port gets a new video
format, and we fail to reconfigure correctly here? That is, we fail to
do the correct steps required to make the reconfiguration work?

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel