[FFmpeg-devel] [PATCH] set bitrate from rc_max_rate for duration estimation will fix ticket #3678

Michael Niedermayer michaelni at gmx.at
Wed Aug 20 20:43:52 CEST 2014


On Wed, Aug 20, 2014 at 03:37:58PM +0200, Marc-Antoine Arnaud wrote:
> From: Marc-Antoine Arnaud <arnaud.marcantoine at gmail.com>
> 
> ---
>  libavformat/utils.c |    7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index b4ca342..738d1f0 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -2280,6 +2280,13 @@ static void estimate_timings_from_bit_rate(AVFormatContext *ic)
>                  }
>                  bit_rate += st->codec->bit_rate;
>              }
> +            if (st->codec->rc_max_rate > 0) {
> +                if (INT_MAX - st->codec->rc_max_rate < bit_rate) {
> +                    bit_rate = 0;
> +                    break;
> +                }
> +                bit_rate += st->codec->rc_max_rate;
> +            }

this is not correct, the bitrate and maxbitrate when summed do not
give the bitrate of a stream except by chance.
also the max bitrate is only equal the bitrate for CBR streams.

the case described by Ticket 3678, is about bitrate in MXF.
the solution for this is to set the bitrate based on some
header structures in MXF, or at MXF level.

a slightly different heuristic for the mpeg2 parser that also
improves this ive just posted, comments welcome

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140820/3b82584a/attachment.asc>


More information about the ffmpeg-devel mailing list