0

Suppose I am receiving packets containing H264 encoded NAL Units, and each NAL has correct START_CODE (0x00 00 00 01).

But in some NALUs, the later Bytes of the NAL may have been corrupted. Is there any standard way to validate whether the information represented by a NALU is correct or not?

And if it can be validated, is there any standard way to correct it according to the H264 standards ?

Further Clarification:

The problem to specify is somewhat like this ->

Server sends a x264 NALU like 0x 00000001abcdefgh and, when I receive the packet, it contains : 0x 00000001abcmnopdefgh.

This leads to failure of decompression , hence I was looking for a way to eliminate these bad data bytes.

FahimAhmed
  • 497
  • 3
  • 14
  • I don't understand this concept, but : Error Resiliency and Concealment in H.264, could answer to your question... – mofo77 Jan 09 '20 at 22:33
  • The problem to specify is somewhat like this -> Server sends a x264 NALU like 0x 00000001abcdefgh and, when I receive the packet, it contains : 0x 00000001abcmnopdefgh. This leads to failure of decompression , hence I was looking for a way to eliminate these bad data bytes. – FahimAhmed Jan 10 '20 at 05:38
  • You can’t remove it. You need to prevent it. There is no real protocol that does this without including continuity counters. If you are using raw UDP, without FEC, or CC, there is literally no solution. – szatmary Jan 10 '20 at 07:13

1 Answers1

1

The only way to validate it is to parse the entire nal and make sure you have the correct number of bits. Even then some errors may not be detected.

No there is no way to correct the errors unless the container/file includes erasure codes.

szatmary
  • 29,969
  • 8
  • 44
  • 57
  • 1
    Could you kindly tell me which bytes of a NAL describes the number of bits it should contain? – FahimAhmed Jan 09 '20 at 17:04
  • 1
    There is no such thing. That would add unnecessary size to the compressed file. The only way to know the size is to decompress the whole NAL. You need to read ISO-14496-10, But be warned, its about 1000 pages. – szatmary Jan 09 '20 at 18:14
  • 1
    Actually the problem I am facing is, I am receiving h264 encoded packets over a network. Now, sometimes the NALUs that I receive contain garbage bytes in between them, and when I am sending them over to Apple's VTDecompressionSession, it is failing to decompress them, giving error 12909. Hence I was thinking if I could find some way to validate and remove the garbage bits from the NALU, and then send them to the decompression session. – FahimAhmed Jan 10 '20 at 05:34
  • 1
    “Garbage bits”? New bits don’t just appear. Something is producing them for some reason. I suggest you figure out what is inserting “garbage bits” and for what purposes. Then figuring out how to remove them by understanding how they were inserted the first place. – szatmary Jan 10 '20 at 05:40
  • 1
    Actually "the garbage bits" turn out to be bits from some earlier packets which were lost and not received. – FahimAhmed Jan 10 '20 at 05:43
  • 1
    There are some initial packet losses sometimes. Where 2 or 3 packets do not reach the receiving side from the server. And later some fragments of those lost packets are appearing in the middle of other NALUs as garbage. – FahimAhmed Jan 10 '20 at 05:46
  • This has deviated significantly from your original question. If you have more questions, open another post. Please be as detailed as possible and put ALL the information you have into the question. It is difficult to help when I have to extract little bits of the problem out in the comments. – szatmary Jan 10 '20 at 07:09
  • 1
    Sorry for the deviation, but the reason I didn't reveal info about packets is that, even after these garbage bits, mp4box seems to be able to generate a valid mp4 file over the received h264 dump, which can be playedback with media players. So I thought there is some sort of error detection and correction mechanism that I was unaware of, thus resulted in asking this question. – FahimAhmed Jan 10 '20 at 07:29