[gstreamer-bugs] [Bug 623821] qtmux produces brocken .mov files

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jul 9 03:29:51 PDT 2010


https://bugzilla.gnome.org/show_bug.cgi?id=623821
  GStreamer | gst-plugins-bad | 0.10.x

--- Comment #5 from Ivan Zoli <overkill.shining at tiscali.it> 2010-07-09 10:29:45 UTC ---
That's make sense, but if I remove the codec_data ffmux_mov stop working. 
I take a quick look at the code and ffmux_mov build the avcC atom from SPS and
PPS.

from file avc.c of gst-ffmpeg packet:

int ff_isom_write_avcc(ByteIOContext *pb, const uint8_t *data, int len)
{
    if (len > 6) {
        /* check for h264 start code */
        if (AV_RB32(data) == 0x00000001 ||
            AV_RB24(data) == 0x000001) {
            uint8_t *buf=NULL, *end, *start;
            uint32_t sps_size=0, pps_size=0;
            uint8_t *sps=0, *pps=0;

            int ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
            if (ret < 0)
                return ret;
            start = buf;
            end = buf + len;

            /* look for sps and pps */
            while (buf < end) {
                unsigned int size;
                uint8_t nal_type;
                size = AV_RB32(buf);
                nal_type = buf[4] & 0x1f;
                if (nal_type == 7) { /* SPS */
                    sps = buf + 4;
                    sps_size = size;
                } else if (nal_type == 8) { /* PPS */
                    pps = buf + 4;
                    pps_size = size;
                }
                buf += size + 4;
            }
            assert(sps);
            assert(pps);

            put_byte(pb, 1); /* version */
            put_byte(pb, sps[1]); /* profile */
            put_byte(pb, sps[2]); /* profile compat */
            put_byte(pb, sps[3]); /* level */
            put_byte(pb, 0xff); /* 6 bits reserved (111111) + 2 bits nal size
length - 1 (11) */
            put_byte(pb, 0xe1); /* 3 bits reserved (111) + 5 bits number of sps
(00001) */

            put_be16(pb, sps_size);
            put_buffer(pb, sps, sps_size);
            put_byte(pb, 1); /* number of pps */
            put_be16(pb, pps_size);
            put_buffer(pb, pps, pps_size);
            av_free(start);
        } else {
            put_buffer(pb, data, len);
        }
    }
    return 0;
}

while qtmux seems to copy the avcC atom provided in codec_data.
>From gstqtmux.c line 2299

  } else if (strcmp (mimetype, "video/x-h264") == 0) {
    entry.fourcc = FOURCC_avc1;
    qtpad->is_out_of_order = TRUE;
    if (!codec_data)
      GST_WARNING_OBJECT (qtmux, "no codec_data in h264 caps");
    ext_atom = build_codec_data_extension (FOURCC_avcC, codec_data);
    if (ext_atom != NULL)
      ext_atom_list = g_list_prepend (ext_atom_list, ext_atom);

So it seems that the request for codec_data format is not the same. It is
correct?
Is qtmux asking for a complete "avcC atom" on codec_data?

Sorry but I'm not a developer of video container, I have to face this, trying
to fix the plugin provided by the maker of the processor. I spent 3 month of
phone calls with their technical service without get any usefull information.
Then I discover that if I push out of caps in codec_data the header of h264
ffmux_mov is working, while qtmux didn't. I ask assitance on GStreamer mailing
list and they ask me to open a bug here. So please let me know if I'm on wrong
place.

Thank you

Ivan

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list