[Bug 778934] [vp8enc] Using Threads property causes major artifcats

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=778934

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |nicolas at ndufresne.ca

--- Comment #1 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(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 ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.