Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

H264 bad video after passing through network; issue with packetization/depacketization apparently.. #877

Closed
forlayo opened this issue Dec 2, 2022 · 5 comments

Comments

@forlayo
Copy link
Contributor

forlayo commented Dec 2, 2022

I am trying to fix an issue that comes from sending the Android camera using SipSorcery, after several tests I ended up recording the stream in raw h264 just before sending it and just when receiving it at the other side. And the issue is still there so I would say that something is not going well on network transmission.

As a proof of this I've recorded the h264 stream just before calling OnVideoSourceEncodedSample on video source and recorded same on the other party on OnVideoFrameReceived.

As you an see on file recorded at OnVideoSourceEncodedSample video looks pretty fine, but at receiving side at OnVideoFrameReceived. it looks with artefacts, specially on movement.

Note: You can play these raw h264 files with ffplay, vlc or Elmedia Player.

Comparing (using h264streamanalysis tool) the stream we can see that there are errors, on received stream at NAL 98 (for example) the type is not correct, neither the size and it's followed by an invalid frame as wel..

image (5)

@forlayo forlayo changed the title H264 pixelation issue after passing through network. Something RTP or network related is happening. H264 bad video after passing through network; issue with packetization/depacketization apparently.. Dec 2, 2022
@forlayo
Copy link
Contributor Author

forlayo commented Dec 2, 2022

This could be related with #378 I think..

@forlayo
Copy link
Contributor Author

forlayo commented Dec 3, 2022

I am checking with latest version of master, just wondering if the changes to rtp mtu to 1200 fixes my issue. But it's still happening..

@forlayo
Copy link
Contributor Author

forlayo commented Dec 3, 2022

Could it be an issue related to packet loss ? Just basing my answer as the receiving side is somehow corrupt and the effect is like this one (more or less) -> http://www.mediapro.cc/rtp抗丢包传输方案/

If so.. I think I am on a big issue as this library doesn't have any mechanism for packet loss right ?

@forlayo
Copy link
Contributor Author

forlayo commented Dec 7, 2022

I saw on a bit old Microsoft example a full implementation of FEC using XOR and also Reed Solomon, just in case this helps -> https://github.com/conferencexp/conferencexp/blob/master/MSR.LST.Net.Rtp/fec.cs#L47

And Java implementation of ULPFEC (like what's currently in use in WebRTC) https://github.com/jitsi/libjitsi/tree/master/src/main/java/org/jitsi/impl/neomedia/transform/fec

@sipsorcery
Copy link
Member

There is no proper RTCP feedback mechanism in the sipsorcery library and minimal work has been done to wire up the video encoders to trigger key frames in the event of packet loss. I'm adding this issue to the list of enhancements. It's a BIG job to sort this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants