GNOME Bugzilla – Bug 778934
vp8enc: Using Threads property causes major artifacts
Last modified: 2018-11-03 15:16:39 UTC
1.10.3 Mac OS - Installed via Brew Using the "threads" property causes the encoded video to refuse to play. Changing "error-resilient" to 1-3 with threads causes the video to play but incurs intense rainbow artifacting. Tested with various pipelines with varying degrees of success. gst-launch-1.0 videotestsrc ! vp8enc ! decodebin ! autovideosink will play gst-launch-1.0 videotestsrc ! vp8enc threads=4 ! decodebin ! autovideosink will not play gst-launch-1.0 videotestsrc ! vp8enc threads=4 error-resilient=3 ! decodebin ! autovideosink will play with heavy artifacts gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc ! decodebin ! autovideosink will play gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc threads=4 ! decodebin ! autovideosink will not play gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 will stream gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc threads=4 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 will stream gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 undershoot=95 cpu-used=5 deadline=1 static-threshold=50 error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 will stream without artifacts gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 undershoot=95 cpu-used=5 threads=4 deadline=1 static-threshold=500 error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 will stream with heavy artifacts Bottom two streaming examples were viewed in WebRTC compatible browser.
(In reply to purebordem from comment #0) > 1.10.3 Mac OS - Installed via Brew > > Using the "threads" property causes the encoded video to refuse to play. > Changing "error-resilient" to 1-3 with threads causes the video to play but > incurs intense rainbow artifacting. Tested with various pipelines with > varying degrees of success. > > gst-launch-1.0 videotestsrc ! vp8enc ! decodebin ! autovideosink > > will play > > gst-launch-1.0 videotestsrc ! vp8enc threads=4 ! decodebin ! autovideosink > > will not play > > gst-launch-1.0 videotestsrc ! vp8enc threads=4 error-resilient=3 ! decodebin > ! autovideosink Works on Linux, better if you set a deadline though (e.g. deadline=1). vp8enc without a deadline is not designed to be real-time. Can you attach a trace, maybe GST_DEBUG=2 and/or GST_DEBUG="vp*:7" ? Does using deadline=1 make it works ? > > will play with heavy artifacts > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > ! decodebin ! autovideosink I don't see visual artifacts. Note that by definition this would mean a corrupted image. Though, without deadline=1 my computer is too slow. > > will play > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > threads=4 ! decodebin ! autovideosink Works for me, lot of framedrop and deadline=1 helps. > > will not play > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > will stream > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > threads=4 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > will stream > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! > videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 > undershoot=95 cpu-used=5 deadline=1 static-threshold=50 error-resilient=1 ! > rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > will stream without artifacts If the encoder is not real-time, getting visual artifacts makes a lot of sense due to packet lost. Again, using vpxenc without deadline make not sense for streaming. Same goes to VBR, it's not the best setting for streaming. > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! > videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 > undershoot=95 cpu-used=5 threads=4 deadline=1 static-threshold=500 > error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > will stream with heavy artifacts > > > Bottom two streaming examples were viewed in WebRTC compatible browser. The is strange, since WebRTC compatible browser requires SRTP and an RTP sessions. Can you share your receiver pipeline ?
Created attachment 346393 [details] vp8enc threads debug logs and screenshot
(In reply to Nicolas Dufresne (stormer) from comment #1) > (In reply to purebordem from comment #0) > > 1.10.3 Mac OS - Installed via Brew > > > > Using the "threads" property causes the encoded video to refuse to play. > > Changing "error-resilient" to 1-3 with threads causes the video to play but > > incurs intense rainbow artifacting. Tested with various pipelines with > > varying degrees of success. > > > > gst-launch-1.0 videotestsrc ! vp8enc ! decodebin ! autovideosink > > > > will play > > > > gst-launch-1.0 videotestsrc ! vp8enc threads=4 ! decodebin ! autovideosink > > > > will not play > > > > gst-launch-1.0 videotestsrc ! vp8enc threads=4 error-resilient=3 ! decodebin > > ! autovideosink > > Works on Linux, better if you set a deadline though (e.g. deadline=1). > vp8enc without a deadline is not designed to be real-time. Can you attach a > trace, maybe GST_DEBUG=2 and/or GST_DEBUG="vp*:7" ? Does using deadline=1 > make it works ? > Attached a couple debugs with the above pipelines. Also included a screenshot. This artifacting is mild in comparison to the filesrc pipelines. Deadline does not cause the pipeline to play if it did not before. Only make pipelines that are playing to have a better playback frame rate. > > > > will play with heavy artifacts > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > > ! decodebin ! autovideosink > > I don't see visual artifacts. Note that by definition this would mean a > corrupted image. Though, without deadline=1 my computer is too slow. > > > > > will play > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > > threads=4 ! decodebin ! autovideosink > > Works for me, lot of framedrop and deadline=1 helps. > > > > > will not play > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > > ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > > > will stream > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin ! videoconvert ! vp8enc > > threads=4 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > > > will stream > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! > > videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 > > undershoot=95 cpu-used=5 deadline=1 static-threshold=50 error-resilient=1 ! > > rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > > > will stream without artifacts > > If the encoder is not real-time, getting visual artifacts makes a lot of > sense due to packet lost. Again, using vpxenc without deadline make not > sense for streaming. Same goes to VBR, it's not the best setting for > streaming. > > > > > gst-launch-1.0 filesrc location=file.mp4 ! decodebin name=decode ! > > videoconvert ! vp8enc end-usage=vbr min-quantizer=5 max-quantizer=50 > > undershoot=95 cpu-used=5 threads=4 deadline=1 static-threshold=500 > > error-resilient=1 ! rtpvp8pay ! udpsink host=127.0.0.1 port=5004 > > > > will stream with heavy artifacts > > > > > > Bottom two streaming examples were viewed in WebRTC compatible browser. > > The is strange, since WebRTC compatible browser requires SRTP and an RTP > sessions. Can you share your receiver pipeline ? Unfortunately I do not have the pipeline as I am feeding it to a Janus Gatewa and have yet to figure out what Janus does to handle the stream.
Created attachment 346396 [details] GST to Janus WebRTC Artifacts
I don't know what we can do about this? Are we sure the problem is GStreamer side and not in libvpx?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/348.