ridgerun/gst-omx-dm816x-dm814x

OpenMAX IL GStreamer wrapper

gst-omx-dm816x-dm814x's Issues

Seek transition is not completely neat.

Seek jump has a fast response, but the transition may show different things such as:

• frames that appear not to be of the new segment
• black screen (~0.25 seconds)

Also looks like the omxvideodec "No corresponding frame found" error message appears more times when the transition is not neat. Also seems that seek jumps at some specific times show more problems than others.

Further inspection is needed in the dec_loop method, and if needed in the demuxer seek logic.

Video seeking stalls playback session (gstd no return)

When injecting a seek event to the pipeline the playback session stalls, same goes for gstd-client. To regain control of the command line a CTRL+C (forced quit) is need. To start another playback session it would need manual kill of the gstd process, still it may affect OpenMAX layer, so reboot may be needed as well.

Debug logs don't show a particular error, but all latest logs show a QoS event received line at the very end, some lines above a flush start event can be seen also.

This issue is occasional, sometimes is very easy to reproduce, sometimes you can try several times and it doesn't appears.

Video seeking stalls playback session (gstd returns) ready2close

Video seeking is not 100% stable, doing a playback exercise with gstd-client when injecting a seek event to the pipeline causes a freeze. 5 consecutive seek exercise should be enough to reproduce the problem.

Black screen during video seek transition

When seeking during a playback exercise the transition has a black screen that lasts around 0.25 - 0.5 seconds.

Actions to consider:

• Don't flush omx output port in decoder element
• Prevent flushing displayed buffer in sink element

MP4/H.264 playback is not 100% smooth

1920x1080 playback is not 100% smooth, this is seen as persistent drops in the video. Memory usage has been optimized, omxh264dec and omxscaler are sharing buffer pool and v4l2sink is working with io-mode 3 (userptr).

Approaches to consider:

• Less I-frames in the H.264 bytestream at recording time may generate less stress to the decoder.
• Decoder element bottleneck study and refactor
• Rate reduction