[FFmpeg-devel] [PATCH] lavf: let av_find_best_stream use bitrate info if available

[Michael Niedermayer]

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...
> 
> samples/ffmpeg-bugs/roundup/issue1499/hpim0054.mpg
> 
> http://roundup.libav.org/issue1499
> 
> 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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121118/66cce953/attachment.asc>