On Mon, Feb 23, 2015 at 10:24 PM, Vittorio Giovara <[email protected]> wrote: > These value represent the original bitstream size, before any extra > operation, such as rotation or container cropping, may be applied. > > Container cropping is one of the ways to encode an odd-size h264 video > in yuv420 color space. Right now, when it is applied, the original frame size > is lost, and there is no way to understand where the cropping took place > (eg. at the bitstream level or at the container level). > > Not only analysis might want to preserve that information, but users > may carry out additional padding when it is actually not necessary. > > This change allows to preserve all sizes from container and bitstream in > the AVCodecContext. The values are to be considered as follows: > * coded_width/coded_height: size of the full coded video surface; > * orig_width/orig_height: size of the video frame to be displayed; > * width/height: size of the actual video to be displayed. > > When container cropping is not present, orig_width/orig_height match > width/height; under no circumstance, they are allowed to be greater than > coded_width/coded_height or smaller than width/height. >
IMHO, this seems rather ugly. Especially with Anton's plans to liberate demuxing from the codec context, there ought to be a better way to store this. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
