[FFmpeg-devel] [PATCH] lavf: let av_find_best_stream use bitrate info if available
michaelni at gmx.at
Sun Nov 18 00:43:57 CET 2012
On Sat, Nov 17, 2012 at 11:23:38PM +0100, Marton Balint wrote:
> On Sat, 17 Nov 2012, Michael Niedermayer wrote:
> >On Sat, Nov 17, 2012 at 02:15:00PM +0100, Marton Balint wrote:
> >>On Sat, 17 Nov 2012, Michael Niedermayer wrote:
> >>>On Sat, Nov 17, 2012 at 12:39:26AM +0100, Marton Balint wrote:
> >>>>I guess the user expects to see the stream with the highest bitrate, not with
> >>>>the most frames, this is especially useful for multi bitrate streams.
> >>>>This patch changes av_find_best_stream to select the stream with the highest
> >>>>bitrate which has at least one frame.
> >>>this will fail with streams that have no frame (but a incorrect high
> >>>bitrate possibly)
> >>That should not be a problem, because of this:
> >>+ count = st->codec_info_nb_frames;
> >>+ bitrate = count ? avctx->bit_rate : 0;
> >>We reset the bitrate to 0, if frame count is 0.
> >>>or just one frame like an jpeg/png
> >>You mean files with e.g. cover art and a the real video? If I change
> >>the bitrate check to reset the bitrate if frame count is less than
> >>2, that fixes this as well, right?
> >it does seem ok but should be tested if possible with the files that
> >needed the original code
> I've posted a new patch, and also made some test with it.
> For most of the samples where this change made a difference, it
> worked, well, it chose the best quality stream, it even fixed some
> files (where the bitrate based decision chose the proper stream, and
> not the silent one), but I have also found a sample where the frame
> number heuristics did not work, because the bad stream contained not
> zero, but 2 frames...
> Which seems the be the file which inspired the whole frame count
> based decision. :/
> Should I change the FFMIN(frame_count, 2) to FFMIN(frame_count, 3)
> in the highest priority condition? It would fix that particular
> case, and probably work most of the time for the other cases...
I dont think setting the threshold so narrow is a good idea.
there sure will be a file with 3 frames then ...
what we want is to drop streams that have a oddly small number of
frames for their kind, because they likely dont represent the
content the user wants to see.
we could just try a threashold of 5 and see if that works out in
reality or we could try to set the threshold depening on the max
number of frames of any stream of a matching type.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel