> [...]
> are the same in both cases (I assume these are respectively the
> sequence and picture parameter sets).  The question is, why are
> the lead-in bytes different, and what do they mean?
> 
>   00000001 != 0164000dffe10019 (lead-in to sequence parameter set)
> 
> and
> 
>   00000001 != 010005 (lead-in to picture parameter set)

I have studied the FFmpeg source code, and now I think I know the
meaning of the lead-in bytes found in FFmpeg's extradata:

0164000dffe10019:
      01 = always 0x01 for H.264
      64 = profile_idc
      00 = bit   7 = constraint_set0_flag,
           bit   6 = constraint_set1_flag,
           bit   5 = constraint_set2_flag,
           bit   4 = constraint_set3_flag,
           bit 3:0 = reserved zero bits
      0d = level_idc 
      ff = NAL unit length size (0xff & 3 + 1 = 4 bytes)
      e1 = number of sequence parameter sets (0xe1 & 0x1f = 1 unit)
      00 19 = sequence parameter set length (0x0019 = 25 bytes)

010005:
      01 = number of picture parameter sets
      00 05 = picture parameter set length (0x0005 = 5 bytes) 

> In summary: If I only have the CodecPrivateData as Microsoft encodes
> it:
> 
>   000000016764000dac2cc506077e5840000003004000000ca3c50a65800000000168ebecb22c
> 
> then how can I use it to properly decode video with FFmpeg's
> H.264 decoder?  I don't know the algorithm used to convert this into
> 
>   
> 0164000dffe100196764000dac2cc506077e5840000003004000000ca3c50a658001000568ebecb22c
> 
> which FFmpeg seems to require.

Now it seems that information has been lost here.  I cannot
reproduce these three bytes from nothing:

      64 = profile_idc
      00 = bit   7 = constraint_set0_flag,
           bit   6 = constraint_set1_flag,
           bit   5 = constraint_set2_flag,
           bit   4 = constraint_set3_flag,
           bit 3:0 = reserved zero bits
      0d = level_idc

Hopefully, I can set these values to the least restrictive
configuration of all (H.264 with no constraints whatsoever),
and it will still work.  Looking at the H.264 specification,
these settings actually look pretty unrestricted, so maybe I
can assume that 64000d will work for all H.264 encoded video?

-- 
 Haakon
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user

Reply via email to