Seeking with kmssink does not work

[Nicolas Dufresne]

Le dim. 22 déc. 2019 07 h 30, moritz.vieli <moritz.vieli at gmail.com> a
écrit :

> Ok, best to try latest as usual.
> --> I know. Unfortunately, I am still unable to build Gstreamer on the
> Raspberry from the sources (but I am still a Linux noob ;)).
>
> I'm convinced there is something that could be improved there, assuming you
> are ready to spend the time.
> --> As long as I can help, sure!
>
> You should maybe share
> a little more info about what you are doing.
> --> I am developing a system to play audio, video, MIDI and lighting shows
> in sync. Gstreamer is used as the backend. Everything worked fine on the
> Raspberry Pi 3 and I am trying to port it to the Raspberry Pi 4 now. I had
> to switch from glimagesink to kmssink, because of a problem with the colors
> (see
>
> http://gstreamer-devel.966125.n4.nabble.com/Wrong-colors-on-Raspberry-Pi-4-td4692614.html
> ),
> that's why I first suspected kmssink to be responsible for the seeking
> issues. However, it turns out, it really seems to be an issue with
> v4l2h264dec. I just tested it with avdec_h264 and it worked fine. However,
> this decoder is too slow on the Raspberry and everything stutters. This is
> the current pipeline for video files:
> uridecodebin ! queue ! kmssink
>
> Also, you should check
> your kernel logs too, as there is a good deal of work done by the
> driver.
> --> There are indeed errors, as soon as I seek:
> Dec 22 11:02:35 xxx kernel: bcm2835-codec bcm2835-codec:
> bcm2835_codec_stop_streaming: Timeout waiting for buffers to be returned -
> 5
> outstanding
> Dec 22 11:02:35 xxx kernel: bcm2835_mmal_vchiq: buffer_from_host:
> msg_context not allocated, buf 7147fe8b
> (2nd message repeated 7 times)
>

If you find how to contact them, would be nice to send that to the
Raspberry Pi folks to get their feedback. I knew they were moving, but
wasn't involved much. It is though one of my goal for 2020 to make sure
these things get fixed on popular SBC like the Raspberry PI and Amlogic.
Nvidia has moved to, but have fork over 50% of the code, without really
filling any upstream issues.


> Additionally, I found another error thrown from my app:
> (unknown:1570): GStreamer-CRITICAL **: 10:29:30.813:
> gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size'
> failed
>

This one has been fixed upstream. It should make it in the next stable
release. I don't have a link handy, but if you can't find it, let me know,
I can search for that later.


> Please let me know, if you need any further information and thanks a lot
> for
> your support!
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191223/81267a96/attachment.htm>