After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 797302 - rtpulpfec causes h264 artifacts with FEC overhead > 0 and netsim = 0
rtpulpfec causes h264 artifacts with FEC overhead > 0 and netsim = 0
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.14.x
Other Linux
: Normal normal
: 1.15.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-10-18 10:20 UTC by alexagv
Modified: 2018-10-23 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Picture of receiving stream with FEC=1, netsim=0 (741.02 KB, image/png)
2018-10-18 10:20 UTC, alexagv
Details

Description alexagv 2018-10-18 10:20:12 UTC
Created attachment 373960 [details]
Picture of receiving stream with FEC=1, netsim=0

Based on slomo rust example which uses vp8 I´ve implemented a h264 example. 
However, the FEC overhead causes artifacts on receiving stream despite netsim = 0 (no network loss).

I´ve tried with multiple bitrates, GOP lengths and inputstreams. When FEC = 0 everything is fine, but from 1 to 100, artifacts appear.

Tested on:
macOS High Sierra and Ubuntu 18.04, both running gstreamer 1.14.4

Code:
https://github.com/alexagv/gstreamer-rs/blob/h264-fec/examples/src/bin/rtpfecclient.rs
https://github.com/alexagv/gstreamer-rs/blob/h264-fec/examples/src/bin/rtpfecserver.rs
Comment 1 alexagv 2018-10-18 13:55:42 UTC
Further testing with different x264enc settings, only thing that helps is setting GOP/key-int = 1. So it seems like the issue is related to P-frames
Comment 2 Mathieu Duponchelle 2018-10-19 11:54:47 UTC
Thanks for filing this Alexandre. I reproduced the issue with 1.14, but not with master, I believe it was fixed by some patches in rtpptdemux and rtpbin, but haven't investigated further. Can you try with master and confirm that the issue is gone for you as well?
Comment 3 alexagv 2018-10-22 13:12:03 UTC
Thanks Mathieu, it seems to be working fine in 1.15
However I dont see much effect when using the GST_BUFFER_FLAG_NON_DROPPABLE flag on i-frames and specify the percentage-important. Does anyone really know how that algorithm works? 

Cheers,
Alex
Comment 4 alexagv 2018-10-22 13:12:56 UTC
Fixed in 1.15
Comment 5 Mathieu Duponchelle 2018-10-23 14:47:59 UTC
(In reply to alexagv from comment #3)
> Thanks Mathieu, it seems to be working fine in 1.15
> However I dont see much effect when using the GST_BUFFER_FLAG_NON_DROPPABLE
> flag on i-frames and specify the percentage-important. Does anyone really
> know how that algorithm works? 

It is probably a bit hard to see the result reliably when using netsim and dropping random buffers. I guess a better test would be to drop only keyframes, and use 100 for percentage-important , and 0 for percentage.