GNOME Bugzilla – Bug 765660
baseparse: use gst_util_uint64_scale to avoid overflow.
Last modified: 2018-11-03 12:34:29 UTC
use gst_util_uint64_scale_int will overflow as parse->priv->avg_bitrate is unsigned int.
Created attachment 326842 [details] [review] Patch to fix the issue.
Will have below log without the patch for large bitrate stream. (gplay-1.0:2125): GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'denom > 0' failed
You get diffs or avg bitrates higher than 2 billion bits per second but less than 4 billion? There might be other problematic places related to the bitrate, and if you already get into those dimensions it might make sense to convert it to a 64 bit integer, and/or store it as bytes per second (do we already?), etc.
Can you provide a stream where this happens btw?
I found the root cause is the special stream report invalid fps. It report 90000fps. So the calculate bitrate is very large and cause overflow. We can add one invalid fps check in our special demuxer to fix the issue. Our demuxer can demux the special stream. tsdemux will report fail.
How to share large video file to you? video file size is 65M.
Use something like dropbox. If tsdemux fails on it, we should make it work :)
Please get the video file: https://www.dropbox.com/s/4aoeexntsu77jul/HD_8M.mpg?dl=0
Ok, this fails because "mpegtsbase.c:1328:mpegts_base_scan:<tsdemux0> Couldn't find any PCR within the first 655360 bytes". Where is the PCR? :) Can you open another bug against tsdemux for this specific file? Inside baseparse what should happen probably is to guard against overflows not only in this place but in general, I don't think your patch is complete here as it could still overflow (bitrate is still an int).
What shall we do with this? mpegtsbase warning still happens.
Created attachment 346063 [details] [review] baseparse: reset data_bytecount in gst_base_parse_reset I have usecase where we have master on one unit and slave on another. Master encoder pcm data in flac and send over to slave. On slave we dont recreate pipeline but reset the flacparser when new stream-start is detected to fix it internal variable. In this scenario i have seen GStreamer-CRITICAL **: _gst_util_uint64_scale_int: assertion 'denom > 0' failed when you change the track etc. Proposed fix fixes the issue for me, it actually reset one of the variable which get used to calculate avg_buffer.
-- 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/gstreamer/issues/170.