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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #3 from purebordem at gmail.com ---
(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.

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