Created attachment 369922 [details]
annotated log showing h264parse bug

I'm using an h264parse to convert H264 from byte-stream to avc for feeding into a qtmux/filesink for movie recording. When recording for the first time after creating the parser, it works normally. The parser has to drop frames (with a message like 'broken/invalid nal Type: 1 Slice, Size: 4725 will be dropped') until an SPS/PPS is received, but once that happens it creates a proper caps event with codec_data and everything works.

But after stopping recording (blocking data, sending EOS through the pipeline, setting h264parse to NULL state) and then starting recording again, the h264parse doesn't work right. Rather than dropping frames until SPS/PPS comes in, it attempts to parse the frames but fails:

gsth264parser.c:962:gst_h264_parser_parse_pic_timing: didn't get the associated sequence paramater set for the current access unit
gsth264parser.c:1007:gst_h264_parser_parse_pic_timing: error parsing "Picture timing"
gsth264parse.c:530:gst_h264_parse_process_sei:<vparser> failed to parse one or more SEI message

The parser then sends a caps event without codec_data since no SPS/PPS has been received, I don't believe this is even legal for stream-format=au. qtmux rejects the caps, and video doesn't flow.

The problem appears to be that h264parse->state is not reset when the nalparser is recreated, i.e. in gst_h264_parse_start(). From 'h264parse->state' in the previous run, h264parse thinks that the nalparser has already parsed an SPS, when it actually hasn't (it was just free'd and recreated). The nalparser then fails to parse any non-SPS/PPS messages, and bad caps are sent out.

Patch against master is attached. I've tested the same patch against 1.12.2 with success. Also attached an annotated/condensed log.