[FFmpeg-devel] [PATCHv3] lavf: add av_guess_frame_sample_aspect_ratio function

Michael Niedermayer michaelni at gmx.at
Mon May 14 23:17:05 CEST 2012


On Mon, May 14, 2012 at 09:29:07PM +0200, Marton Balint wrote:
> On Sat, 12 May 2012, Michael Niedermayer wrote:
> >On Sat, May 12, 2012 at 09:06:04PM +0200, Marton Balint wrote:
> >>On Tue, 8 May 2012, Marton Balint wrote:
> >>>
> >>>On Tue, 8 May 2012, Joakim Plate wrote:
> >>>
> >>>>On Mon, May 7, 2012 at 11:03 PM, Michael Niedermayer
> >>>><michaelni at gmx.at> wrote:
> >>>>>On Mon, May 07, 2012 at 08:39:32PM +0200, Joakim Plate wrote:
> >>>>>>Just thought i'd chime in here. We (xbmc) ended up using that special
> >>>>>>handling of stream aspect being 1:1 and codec aspect not being 1:1 to
> >>>>>>solve a few samples we found in the wild. Thing the where mp4's
> >>>>>>recorded by some camera if i remember correctly. So i'm sort of in
> >>>>>>favor of that solution even if it's ugly.
> >>>>>
> >>>>>iam in favor of whatever works best and is simple
> >>>>>
> >>>>>in that sense, does anyone know how common in the wild files are that
> >>>>>change the sample aspect ratio midstream but have a valid and not 1:1
> >>>>>sample aspect at the format level ?
> >>>>
> >>>>Can't really say.
> >>>>
> >>>>Here our our ticket and change for this. Seems it was an MKV after allH
> >>>>so maybe i should just have asked him to re-mux the file.
> >>>>https://github.com/xbmc/xbmc/commit/f08c8f01d1014a7f161d40a7cc8ede0680f9fe77
> >>>>http://trac.xbmc.org/ticket/12187
> >>>>
> >>>>And now that i look at it I notice the commit message is wrong. It's
> >>>>the opposite order of what it does (what it does matches what was
> >>>>proposed here).
> >>>
> >>>You don't need the 1:1 hack to fix the file in this bug, because
> >>>here the stream sample aspect ratio is 4:3 (DAR is 16:9),
> >>>therefore it got priority over the codec sample aspect ratio
> >>>anyway.
> >>>
> >>>So the reason for keeping the 1:1 hack was probably some other
> >>>file which is not in the report.
> >>>
> >>>Anyway, I really agree with Reimar here and rather not handle 1:1
> >>>aspect specially. If we do find a device (camera, etc.) which sets
> >>>these fields to wrong values, then I think it is better to match
> >>>for some identification of the creator device in the file if it is
> >>>possible and handle _that_ specially.
> >>
> >>Is there anybody who is against the v3 patch for some reason? If no
> >
> >>objections come in a day or two, then Michael, can you apply it?
> >
> >sure just send me a reminder in a day or 2 otherwise i will forget
> 
> No further comments received, please apply the v3 patch.

locally applied, will be in my next push

Thanks
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/20120514/8f1a8d61/attachment.asc>


More information about the ffmpeg-devel mailing list