Hi,
Morfsta schrieb:
It seems that you must start scanning the mpeg stream for a Sequence Parameter Set with a NAL Access Code of 7. At first glance this doesn't appear too bad, as the code is already in src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit Delimiter), which it uses to detect the presence of H264 stream.
Correct.
I thought it would be quite straightforward to find the NAL code of 7 and then parse the SPS and in turn find the height and width parameters. However, trying to get this to work in sequence is not that easy as the parse_video_stream seems to want to identify MPEG1/2 or H264 and then just init the decoders. This is where the initialisation of CoreAVCDecoder.ax is made, currently with the hardcoded video size of 1920x1080. What I want it to do is identify the H264 stream and then keep scanning for an SPS to identify the size prior to initting the decoder.
It seems that once it's found the AUD it doesn't really want to keep looking for a SPS. I tried modifying the code to look for a SPS to init the H264 sequence, however haven't had much success with that either.
Typically, a SPS is found in the same memory block which starts with an AUD for an "I frame". From VDR's remux.c, cRemux::ScanVideoPacket():
if (!p[-2] && !p[-1]) { // found 0x000001 if (h264) { int nal_unit_type = p[1] & 0x1F; switch (nal_unit_type) { case 9: { // access unit delimiter int primary_pic_type = p[2] >> 5; switch (primary_pic_type) { case 0: // I case 3: // SI case 5: // I, SI PictureType = I_FRAME; break;
It might be the case that the whole initialisation of the CoreAVC decoder would be better suited somewhere else in the code.... :-\
Doesn't the decoder support a callback function where it tells you, the detected frame size? It'll really be a mess to do H.264 "decoding" in the demuxer.
Bye.