GNOME Bugzilla – Bug 699302
h264parse doesn't wait for complete output caps, leading to not-negotiated errors when remuxing
Last modified: 2013-06-07 10:09:55 UTC
Looks like problem appears with streams streams without SPS/PPS at the beginning of the stream and if element after parser doesn't accept caps without such information as width and height. I've also found Sebastian's comment about possible root case of this bug: https://bugzilla.gnome.org/show_bug.cgi?id=698679#c2 Thanks, Ilya.
Created attachment 242904 [details] Issue stream This is issue h264 elementary stream.
*** Bug 695206 has been marked as a duplicate of this bug. ***
Bug #699398 should fix the same for mpegvideoparse.
Created attachment 243395 [details] [review] Patch that fixes #699302 bug. Please review this patch, I'm not sure that it the correct place in code where the fix for this bug should be. Thanks, Ilya.
Comment on attachment 243395 [details] [review] Patch that fixes #699302 bug. >diff --git a/gst/videoparsers/gsth264parse.c b/gst/videoparsers/gsth264parse.c >index 6da80f2..5b4a50a 100644 >--- a/gst/videoparsers/gsth264parse.c >+++ b/gst/videoparsers/gsth264parse.c >@@ -882,7 +882,16 @@ gst_h264_parse_handle_frame (GstBaseParse * parse, > } > } > >- gst_h264_parse_process_nal (h264parse, &nalu); >+ if ((!h264parse->have_sps && nalu.type == GST_H264_NAL_SPS) || >+ (!h264parse->have_pps && nalu.type == GST_H264_NAL_PPS) || >+ (h264parse->have_sps && h264parse->have_sps)) { >+ gst_h264_parse_process_nal (h264parse, &nalu); >+ } >+ else { >+ GST_WARNING_OBJECT (h264parse, "no SPS/PPS yet, nal Type: %d, Size: %u will be dropped", nalu.type, nalu.size); >+ *skipsize = nalu.size; >+ goto skip; >+ } > > if (nonext) > break;
This is related to bug #646327.
Comment on attachment 243395 [details] [review] Patch that fixes #699302 bug. >diff --git a/gst/videoparsers/gsth264parse.c b/gst/videoparsers/gsth264parse.c >index 6da80f2..5b4a50a 100644 >--- a/gst/videoparsers/gsth264parse.c >+++ b/gst/videoparsers/gsth264parse.c >@@ -882,7 +882,16 @@ gst_h264_parse_handle_frame (GstBaseParse * parse, > } > } > >- gst_h264_parse_process_nal (h264parse, &nalu); >+ if ((!h264parse->have_sps && nalu.type == GST_H264_NAL_SPS) || >+ (!h264parse->have_sps && nalu.type == GST_H264_NAL_PPS) || >+ (h264parse->have_sps && h264parse->have_sps)) { >+ gst_h264_parse_process_nal (h264parse, &nalu); >+ } I think there are some have_sps/pps mixups here?
Created attachment 243484 [details] [review] Patch that fixes #699302 bug. There were some typos in last patch so here is the new one.
Created attachment 243487 [details] [review] Patch that fixes #699302 bug.
Comment on attachment 243487 [details] [review] Patch that fixes #699302 bug. >- gst_h264_parse_process_nal (h264parse, &nalu); >+ if ((!h264parse->have_sps && nalu.type == GST_H264_NAL_SPS) || >+ (!h264parse->have_pps && nalu.type == GST_H264_NAL_PPS) || >+ (h264parse->have_sps && h264parse->have_pps)) { >+ gst_h264_parse_process_nal (h264parse, &nalu); >+ } Apologies for the nitpicking, but shouldn't it be: if (nalu.type == SPS || nalu.type == PPS || (have_sps && have_pps)) { .. process_nal(); } (there can be multiple PPS, no? And we want to update the SPS even if we already have one (irrespective of whether we have an PPS or not))
Created attachment 243583 [details] [review] Patch that fixes #699302 bug. Patch with fixes which were suggested by Tim.
Let's close this bug here and make it a duplicate of #646327. It's exactly the same problem, let's continue there :) *** This bug has been marked as a duplicate of bug 646327 ***