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