On Sun, Apr 03, 2016 at 02:31:06PM +0200, Hendrik Leppkes wrote: > On Sun, Apr 3, 2016 at 2:07 PM, Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > Without this or some other change moving data back and forth corrupts it > > as the cropped & possibly low res resolution modified w/h will be taken > > a the pre lowres resolution > > also without 2 sets theres no place to communicate the cropped dimensions > > > > can be reproduced with > > ./ffplay_g -vlowres 2 tickets/162/avid.avi > > > > lowres is supposed to be applied in the decoder, not the demuxer, so I > don't see how this is required here.
if iam not mistaken (please correct me if iam wrong) the demuxer runs a decoder, which initializes various AVCodecContext fields these then get copied into AVCodecParameters and back into the users AVCodecContext used for the user appliations decoder the first decoder will set width & height to the low resolution with lowres, coded_width / height will represent the stored, true width/height the data copied into the AVCodecParameters will have lost the width & height that is stored anywhere but rather contain the lowres variant. the user app then will initialize its decoder based on coded_width and coded_height which it will find set to 0 so it fallback to the compatibility hack of using width & height which are the lowres values and the decoder will apply the lowres stuff again above is based on some assumtations i have not verified very step with a debugger > AVCodecParameters is supposed to contain container information, not > pre-interpreted info based on some decoding options. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
