-
Notifications
You must be signed in to change notification settings - Fork 442
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
Add H264 depacketisation #378
Comments
@sipsorcery You can use my payload processor to do it. Just call ProcessRTPPayload and if return != NULL, the frame is completed (Support Annex-b Slices). Ex: seqNum 1 timestamp 100 markbit 0 Ex2: seqNum 1 timestamp 100 markbit 0
|
Awesome, thanks! I'll see about incorporating that class pronto. |
@sipsorcery i wounder if you could add a way to disable this "internal" frame processmentments to prevent duplicity in depackanization when we try to use custom logics. As i said, this internal implementations don't use any kind of JitterBuffers.... So, if we want to perform our own custom logic to decode a Frame using OnRtpPacketReceived we are doomed to perform this 2 times, as inside RTPSession you always perform Depackanization from packets of a know format (H264/VP8). Maybe let us decide if we want to perform this internal depackanization checking internally if (OnVideoFrameReceived != null) before call internal processors is a good way to go... what do you think? Best regards |
I added that change and merged the PR. The H264 depacketisation now works in some circumstances, which is a big improvement! In other circumstances FFmpeg is unhappy with the encoded frames:
In the same situations VP8 works. The good thing is there is now a starting point to work from. |
@sipsorcery i already tested this depackanization logic with 720p in chrome As i said before you must ensure finish a timestamp before apply another timestamp to H264PayloadProcessor. if you receive packet in order below and put it directly on H264PayloadProcessor boths frames are lost... seqNum 1 timestamp 100 markbit 0 KeyFrames can be surprisely long... you can receive more than 50 packets from UDP to handle one keyframe so using H264PayloadProcessor directly without check if payload is already processing another timestamp will cause a huge amount of frames lost. Another tip is to always use FormatDescription with PackanizationMode == 1 before send SDP with H264 as this depackanization only handle this mode. Best Regards |
Yep I understand what you mean regarding packet loss and out of sequence arrival. I recently added a log warning message so I can quickly identify when that occurs. The Chrome 720p failure was my fault. In the FFmpeg logic I wasn't re-creating the pixel converted dimensions when the decoded source frame changed. I fixed that and I'm able to decode H264 at 720p and 1080p. The MicroSIP softphone is using packetization mode 0 but I don't think that's the issue as that's what Chrome is defaulting to as well (I'm sending the SDP offer without specifying a H264 packetization mode so Chrome uses 0). I'll keep looking into this one, |
When using packatization mode == 0 the PPS and SPS (required to decode all frames) was not sended with KeyFrames... In PackatizationMode == 1 the SPS/PPS was sended with KeyFrame so the KeyFrame will have 3 or more Nals (SPS, PPS, (IDR)*)... In this mode you can always recover from SPS/PPS when new KeyFrame arrive. |
From my understanding the packetization mode does not influence the H264 byte stream produced by an encoder. Whether or not the byte stream includes additional It also seems like packetisation-mode 0 and 1 are well understood. I tested with two different softphones as well as Chrome and a H264 stream packetised as mode 1 was understood whether or not the parameter was set in the SDP or not. |
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 ? |
There's no packet loss recovery mechanism by now... i started building support for it but it's not finished |
@rafcsoares so happy on hearing that, if I can help you somehow count with it! If you've the work on a branch and I could contribute or testing I'll happy on helping :) |
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 |
is there any packet loss rec available now? What to do if udp h264 packets drop and decoder gives error when expected timestamp/sequence frame is lost? |
Currently the
RTPSession
class supportsH264
packetisation but not depacketisation. That leavesVP8
as the only fully supported video codec. This issue is to capture the need to add the feature. IdeallyH264
packetisation logic should be refactored out ofRTPSession
into a separate class at the same time.The text was updated successfully, but these errors were encountered: