GNOME Bugzilla – Bug 734124
h264parse: output frames with no pts causes jerky rendering
Last modified: 2018-11-03 13:25:40 UTC
Playing a specific ts file using this kind of pipeline: gst-launch-1.0 filesrc location=1seg.ts ! tsdemux program-number=23992 ! h264parse ! video/x-h264,stream-format=byte-stream,alignment=au ! avdec_h264 ! autovideosink causes the rendering to be jerky. The test file can be downloaded here: http://www.darkosphere.fr/tmp/gstreamer/1seg.ts I think it could be caused by the h264parse element sending frame to decoder without pts. Here is what I understand about the issue: I notice that h264parse, in this case, rely on timestamp provided by upstream, ie tsdemux. But buffers pushed by tsdemux element can contain more than one AU, so sone of them will be pushed with a non valid PTS causing decoder to be confused. Currently, I wrote an ugly ugly ugly hack (and pretty unclear) which slightly improve the rendering. My approach was to try to interpolate PTS using timing info through using gst_h264_parse_get_timestamp() in pre_push_frame(). What do you think about this issue, do you have better ideas ? P.S: This issue can be a duplicate of bug #659489, but I'm not sure.
Created attachment 282273 [details] [review] codecparsers_h264: initialize some fields of pic_timing structure When working on this issue, I also found that some fields of SEI pic timing message could be unitialized and cause error in h264parse element since they are blindly use in h264parse. A better approach could be to set to 0 sei variable in gst_h264_parser_parse_sei() before calling gst_h264_parser_parse_sei_message().
Created attachment 282274 [details] [review] h264parse: interpolate pts instead of pushing frame with none The ugly hack :)
Comment on attachment 282273 [details] [review] codecparsers_h264: initialize some fields of pic_timing structure commit 41df512eb9cbaf84e0464b866c3241f0f0736950 Author: Aurélien Zanelli <aurelien.zanelli@parrot.com> Date: Fri Aug 1 16:40:49 2014 +0200 codecparsers_h264: initialize some fields of pic_timing structure Otherwise pic timing structure can have invalid cpb_removal_delay, dpb_output_delay or pic_struct_present_flag which are blindly retrieved in h264parse. https://bugzilla.gnome.org/show_bug.cgi?id=734124
I have similar problems too, please take a look at the file here: http://195.250.34.59/temp/734124.gdp and try a pipeline like this (double h264parse is not a typo) filesrc ! gdpdepay ! h264parse ! h264parse ! fakesink you'll see that alls buffer will have pts none, so if you change fakesink with matroskamux all buffers will be dropped for invalid timestamp, a single h264parse will preserve pts. The patch here partially solve the issue (still there are some buffer without pts)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/166.