>> I don't see why should a decoder deal with this at all? >>This can be just as well done by the caller.
This implementation takes a reference of the h.264 supporting cropping. In h264, if width (stored in ACCodecContext) parsed from container is different from width parsed from elementary, it will trigger cropping. This is essentially a kind of cropping that related with container. It will infer parameters cb(crop bottom), cr(crop right), and then finally assigned them to AVFrame. This gives the inspiration when we get direct cropping parameters from container. We can us the same methodology. Parser cropping parameters from container in demuxer -> stored container cropping parameters in AVCodec -> pass container cropping parameters to AVFrame-> Apply Crop in frame.c of libavutil. I agree that the caller decide container cropping. To support caller decide the behaviors of cropping,I declare a new field “container_apply_cropping”. The value of this fields container_apply_cropping is decided by caller. This field is by default 1. - When set to 1 (the default), libavcodec will apply container cropping to codec cropping additionally. - When set to 2, libavcodec will use container cropping to overwrite codec cropping (the final cropping uses container cropping parameters) - When set to 0, libavcodec will ignore container cropping parameters (the final cropping uses codec cropping parameters) Caller can total decide the behaviors of container cropping. This field “container_apply_cropping” subject the value of “apply_cropping" (an existing field ). Only apply_cropping is 1, this field works. This make sure the container cropping parameters supporting is consistent with the current cropping mechanism. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
