libde265
libde265 copied to clipboard
strukturag
Total image distortion even on 1% packet loss
Hi, I use rtp as h265 transport and found that even with 1% of packets loss image became totally distorted (static background became gray and only moving parts are shown). It seems that libde265 has a bug because if I use NVidia HW decoder nvh265dec it decode that same stream without any visible artifacts. The same bug also have libav.
How to reproduce:
- Use gstreamer:
gst-launch-1.0 videotestsrc is-live=true do-timestamp=true ! 'video/x-raw,width=640,height=480,framerate=30/1,format=I420' ! x265enc tune=zerolatency bitrate=2000 ! rtph265pay mtu=1400 aggregate-mode=zero-latency ! identity drop-probability=0.01 ! queue ! rtph265depay ! h265parse ! libde265dec ! videoconvert ! xvimagesink sync=false - Use libde265-dec265
/usr/bin/libde265-dec265 -d /tmp/test.h265
If I replace in gstreamer pipeline above libde265dec with nvh265dec all will work without problems
Test data: h265_0.01_loss.mkv.gz test.h265.gz
SW versions: GStreamer: 1.22.0 libde265: 1.0.11-1 OS: Debian 12, amd64
That is not a bug. Even a small packet loss can corrupt many frames because they depend on each other. It is not specified what to do in the case of missing input data. As far as I remember, libde265 simply uses empty content (grey) for the missing image parts. Alternatively, one can use some error concealment algorithms to hide the errors. Apparently, the NVidia HW decoder uses one of them.
We can leave this open as a feature request for implementing an error concealment algorithm.
@farindk Is it possible to use previous base frame instead of grey color filling?
Something like this. But frames are not always coded in temporal order and several frames could be decoded in parallel threads, what makes this more difficult. But yes, that would be a rather simple algorithm that should improve this.
BTW: I looked at your test stream. How does the input look like? I guess that it is a static test image with noise in the bottom right rectangle. Right?
@farindk Yes. It is output of gstreamer videotestsrc. Also interesting that libav h264 decoder doesn't have such bug (see attached file) h264_0.01_loss.mkv.gz
@farindk Is it possible to add quick fix for this problem or it requires a deep investigation?
Are there any progress on this issue? We are facing the exact same issue with intermittent packet loss in keyframes causing gray screen until the next key frame.
