Seeking with kmssink does not work

[moritz.vieli]

Hi there

I am trying to seek with the kmssink, but the image always freezes. Does
anyone have an idea, what I could change? I tried flushing and not flushing.

Thanks a lot and best,
Moritz



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le vendredi 20 décembre 2019 à 11:44 -0600, moritz.vieli a écrit :
> Hi there
>
> I am trying to seek with the kmssink, but the image always freezes. Does
> anyone have an idea, what I could change? I tried flushing and not flushing.

I've just tested here on my PC, 1.16 and master, and seeking works for
me. I see there is some issues in v4l2h264dec though when I test on
DragonBoard 410c. Can you explain which decoder you are using ?

>
> Thanks a lot and best,
> Moritz
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[moritz.vieli]

I am using v4l2h264dec on a Raspberry 4. Tested with the repo version, 1.14,
because I could not get 1.16.2 running until now. But I'll try again with
this version.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[moritz.vieli]

Just checked the new version. It does not work either. The problem also
persists with glimagesink, so maybe you're right and it's the decoder.

Maybe this warning is the root cause?
0:00:00.788157898   773 0xacc08e90 WARN            v4l2videodec
gstv4l2videodec.c:811:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0>
Duration invalid, not setting latency



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le sam. 21 déc. 2019 04 h 30, moritz.vieli <[hidden email]> a écrit :

I am using v4l2h264dec on a Raspberry 4. Tested with the repo version, 1.14,
because I could not get 1.16.2 running until now. But I'll try again with
this version.

Ok, best to try latest as usual. I'm convinced there is something that could be improved there, assuming you are ready to spend the time.

--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Nicolas Dufresne-5]

Le samedi 21 décembre 2019 à 08:01 -0600, moritz.vieli a écrit :
> Just checked the new version. It does not work either. The problem also
> persists with glimagesink, so maybe you're right and it's the decoder.
>
> Maybe this warning is the root cause?
> 0:00:00.788157898   773 0xacc08e90 WARN            v4l2videodec
> gstv4l2videodec.c:811:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0>
> Duration invalid, not setting latency

This should probably be changed to INFO, it just means that there is no
framerate, so we cannot estimate the latency. It should only affect
live playback, making the frames late.

Note that on my tests on DB410c, seeking works sometimes, but stalls at
other time. This use to work reliably, at least on Samsung MFC driver
(Thibault being last person who debugged this). You should maybe share
a little more info about what you are doing. Also, you should check
your kernel logs too, as there is a good deal of work done by the
driver.

>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[moritz.vieli]

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)

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

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le dim. 22 déc. 2019 07 h 30, moritz.vieli <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[moritz.vieli]

Sounds great! Thanks a lot for your support! I found a similar issue in their
Github repo and linked it to this thread:
https://github.com/raspberrypi/linux/issues/3325

Hopefully, we'll get some feedback there.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel