GNOME Bugzilla – Bug 619548
qtdemux: Guess bitrate if only one stream's bitrate is unknown
Last modified: 2011-06-15 22:43:40 UTC
If the bitrates for all but one audio/video streams are known, and the total stream size and duration can be determined, this calculates the unkown bitrate as (stream size / duration) - (sum of known bitrates). While this is not guaranteed to be very accurate, it should be good enough for most purposes. For example, this is useful for H.263 + AAC streams where no 'btrt' atom is available for the video portion.
Created attachment 161894 [details] [review] qtdemux: Guess bitrate if only one stream's bitrate is unknown
As a reference for how far off this patch can be, I have a sample H.263 + AMR-NB stream with the following parameters: System bitrate (video size/duration): ~26304.5 bps H.263 avg. bitrate (from header): 10250 bps H.263 max. bitratE (from header): 26634 bps AMR-NB bitrate (guessed): 16838 bps AMR-NB bitrate (actual) 4750 bps So because of the high variance of the video bitrate, the estimated bitrate was >3x the actual bitrate. This particular instance will be solved by the more accurate AMR bitrate estimation in qtdemux that I will be submitting soon. In the general case. the bitrate estimation is necessarily going to be inaccurate at times, which could be misleading. I am wondering if it might not be better to use an "estimated-bitrate" tag, or some such when we're not sure. It would also be useful for other cases too, such as baseparse where we guess the bitrate by taking a running average on the stream and thus can get wildly inaccurate initial estimates. On the flip side, this requires that clients need to figure out which to look for, based on the application and what its accuracy requirements are.
Comment on attachment 161894 [details] [review] qtdemux: Guess bitrate if only one stream's bitrate is unknown Found an overflow bug. Attaching a fixed patch.
Created attachment 162405 [details] [review] qtdemux: Guess bitrate if only one stream's bitrate is unknown If the bitrates for all but one audio/video streams are known, and the total stream size and duration can be determined, this calculates the unkown bitrate as (stream size / duration) - (sum of known bitrates). While this is not guaranteed to be very accurate, it should be good enough for most purposes. For example, this is useful for H.263 + AAC streams where no 'btrt' atom is available for the video portion.
gst/qtdemux/qtdemux.c 7960 * the overall bitrate minus the sum of the bitrates of all other streams. This 7961 * should be useful for the common case where we have one audio and one video 7962 * stream and can estimate the bitrate of one, but not the other. */ You're forgetting to take into account the size of the header. This might have a non-trivial impact on files with small duration. 8009 8010 sys_bitrate = (size / (duration / GST_SECOND)) * 8; 8011 Use the scale_uint64 functions just in case, and remove the size of the header from 'size'. scale(size, GST_SECOND * 8, duration); (Sorry about the uglyness of this, looks like splinter is broken right now)
Comment on attachment 162405 [details] [review] qtdemux: Guess bitrate if only one stream's bitrate is unknown Thanks for the review and suggestions, Edward - attaching an updated patch
Created attachment 162675 [details] [review] qtdemux: Guess bitrate if only one stream's bitrate is unknown If the bitrates for all but one audio/video streams are known, and the total stream size and duration can be determined, this calculates the unkown bitrate as (stream size / duration) - (sum of known bitrates). While this is not guaranteed to be very accurate, it should be good enough for most purposes. For example, this is useful for H.263 + AAC streams where no 'btrt' atom is available for the video portion.
Created attachment 186658 [details] [review] qtdemux: guess bitrate if only one stream's bitrate is unknown Patch updated to current git along with some fixes/modifications: * adjust some debug statement and format specifiers code style * more reliable way to determine header size (since moov can be located anywhere, this cannot be obtained from an offset, and other atoms may also count as "header") * avoid parallel bitrate book-keeping in stream->bitfield, but rely on pending_tag throughout (which should still be around at that time) Pushing following release ...
commit f89caeff5c1820caecfd2e1d9b93ffeb0a477a17 Author: Arun Raghavan <arun.raghavan@collabora.co.uk> Date: Tue May 25 01:04:43 2010 +0530 qtdemux: guess bitrate if only one stream's bitrate is unknown If the bitrates for all but one audio/video streams are known, and the total stream size and duration can be determined, this calculates the unkown bitrate as (stream size / duration) - (sum of known bitrates). While this is not guaranteed to be very accurate, it should be good enough for most purposes. For example, this is useful for H.263 + AAC streams where no 'btrt' atom is available for the video portion. https://bugzilla.gnome.org/show_bug.cgi?id=619548