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 |
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 signature.asc (201 bytes) Download Attachment |
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 |
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 |
In reply to this post by moritz.vieli
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, 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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by moritz.vieli
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 |
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 |
Le dim. 22 déc. 2019 07 h 30, moritz.vieli <[hidden email]> a écrit : Ok, best to try latest as usual. 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.
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 |
Free forum by Nabble | Edit this page |