> > Haakon Riiser wrote: > > I'm doing some experimentation with Microsoft's Smooth streaming, > > and I have some questions regarding picture/sequence parameter > > sets in H.264. > > > > In Microsoft's layout, this data is stored out of band in a > > so-called "manifest" file. The data is marked "CodecPrivateData", > > and, as I understand it, corresponds to FFmpeg's extradata > > concept. > > > > Unfortunately, it wasn't as simple as filling in the extradata > > array with the data from the CodecPrivateData string. Here's a > > specific example. It shows what happens if I take a video file, > > encode it to work with Smooth streaming, and compare the > > CodecPrivateData from Microsoft with extradata from FFmpeg. Note > > that only remuxing is done, no transcoding, so the parameters sets > > are identical. > > > > >From Microsoft's manifest-file (line-breaks at strategic places to > > illustrate the differences): > > > > Microsoft's CodecPrivateData = \ > > 00000001 \ > > 6764000dac2cc506077e5840000003004000000ca3c50a6580 \ > > 00000001 \ > > 68ebecb22c > > > > If I use libavformat to parse the source material used to > > generate the Smooth streaming stuff that produced the above > > CodecPrivateData, I get the following extradata: > > > > FFmpeg's extradata = \ > > 0164000dffe10019 \ > > 6764000dac2cc506077e5840000003004000000ca3c50a6580 \ > > 010005 \ > > 68ebecb22c > > > > So, it looks like the two blocks > > > > 6764000dac2cc506077e5840000003004000000ca3c50a6580 > > > > and > > > > 68ebecb22c > > > > 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) > > > > In summary: If I only have the CodecPrivateData as Microsoft encodes > > it: > > > > > 000000016764000dac2cc506077e5840000003004000000ca3c50a65800000000168ebe > cb22c > > > > 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 > > > > > 0164000dffe100196764000dac2cc506077e5840000003004000000ca3c50a658001000 > 568ebecb22c > > > > which FFmpeg seems to require. > > > > > FFmpeg stores H264 PPS&SPS headers in avcC format. CodecPrivateData > stores PPS&SPS headers as NAL units. Use function ff_isom_write_avcc > from file "libavformat/avc.c" to convert CodecPrivateData to normal > extradata form. > > Anatoly.
Hi, >From what I can see in h264.c (0.5 release version), you can put NAL units in >extradata too. It will only see it as avcC if you have 0x01 as the first byte. Additionally, you can pass NAL units directly into the bitstream - just decode them just before your first packet. Andrew :) --------------------------------------------------------- Andrew G D Rowley Senior Development Officer Research Computing Services The University of Manchester Devonshire House, Oxford Road Manchester, M13 9PL t : +44 (0) 161 275 0685 e : [email protected] w : www.manchester.ac.uk/researchcomputing --------------------------------------------------------- _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
