Different behaviour of h264parse in Linux and Windows

[4ernov]

Hello,
I stuck with a problem of strange difference in behaviour of h264parse in
my program compiled in Linux and Windows. The pipeline in the program is
like this:

appsrc -> h264parse -> ffdec_h264 -> ffmpegcolorspace -> autovideosink

I push avc format H.264 stream to the appsrc element. In Linux it works
flawlessly, but when I just built it in Windows (version 7 SP1 and
GStreamer SDK 2012.9) an error with the very first keyframe appeared:
somehow it can't be decoded. Here's ERROR's of ffdec_h264 element:

On the screen it looks like the first keyframe was dropped and for some
seconds there're only B-frames on grey background. After the second
keyframe it becomes normal.

I a little bit dug into the problem, dumped data from both pipelines and
compared it (they are quite similar), got DEBUG log of the pipelines and
found some interesting difference: somehow in Windows the branch of code
inside h264parse element is skipped. The code is in
gst/videoparsers/gsth264parser.c:1858:

      if (h264parse->split_packetized) {
        /* convert to NAL aligned byte stream input */
        sub = gst_h264_parse_wrap_nal (h264parse,
GST_H264_PARSE_FORMAT_BYTE,
            nalu.data + nalu.offset, nalu.size);
        /* at least this should make sense */
        GST_BUFFER_TIMESTAMP (sub) = GST_BUFFER_TIMESTAMP (buffer);
        /* transfer flags (e.g. DISCONT) for first fragment */
        if (nalu.offset <= nl)
          gst_buffer_copy_metadata (sub, buffer, GST_BUFFER_COPY_FLAGS);
        /* in reverse playback, baseparse gathers buffers, so we cannot
         * guarantee a buffer to contain a single whole NALU */
        h264parse->packetized_chunked =
            (GST_BASE_PARSE (h264parse)->segment.rate > 0.0);
        h264parse->packetized_last =
            (nalu.offset + nalu.size + nl >= GST_BUFFER_SIZE (buffer));
        GST_LOG_OBJECT (h264parse, "pushing NAL of size %d, last = %d",
            nalu.size, h264parse->packetized_last);
        ret = h264parse->parse_chain (pad, sub);
      } else {
        /* pass-through: no looking for frames (and nal processing),
         * so need to parse to collect data here */
        /* NOTE: so if it is really configured to do so,
         * pre_push can/will still insert codec-data at intervals,
         * which is not really pure pass-through, but anyway ... */
        gst_h264_parse_process_nal (h264parse, &nalu);

      }

According the logs, in Linux it goes to 'then' branch while in Windows it
goes to the 'else' branch. So it seems that split_packetized field is
deviating somehow. I can't recompile bad plugins in Windows currently to
test it, but in Linux I tried to switch off the first branch and it results
in decoder isn't able to decode stream at all. I really don't know how
Windows h264parse variant works, but it parses the stream significantly
different than Linux one for me.

Maybe someone faced something similar or can help me with the problem? Any
help is much appreciated.

Alexey Chernov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20121120/b984dc90/attachment.html>