On 30.05.2020 12:41, Kieran O Leary wrote:
Hi,
On Fri 29 May 2020, 22:47 Neil Birkbeck, <neil.birkb...@gmail.com> wrote:
[...]
I've changed the side data to be PixelCrop (instead of CleanAperture) given
the intent to reuse as cropping elsewhere.
-For now, I've kept the rational representation--although CLAP seems to be
the only required case of it. Maybe Kieran could comment on the requirement
of having maintaining the rationals for CLAP (only works on mov to mov
transmuxing).
I'm no expert, but I think a lot of this just comes from video standards
that stipulate those rational numbers? I've cc'd tobias Rapp and Christoph
Gerstbauer of NOA just to bring this to their attention, as I'm pretty sure
that they use cropping values in AVI, so perhaps all of this could be
useful to them in some way.
Hi Kieran,
when digitizing SD video carriers we indeed store some offset
information in case VBI is preverved (i.e. PAL 720x608). But these
offset values are currently not stored in the AVI container itself. The
OpenDML "vprp" chunk defines some offset values but for the purpose of
compressed image data where the codec implies some multiple-of-N
height/width dimension on the data. So it did not seem to match our
use-case.
Besides AVI and the mentioned MKV and MOV formats I remember some
display offset/cropping information being stored in MXF with the Display
X/Y-Offset values.
Regardless whether the frame crop/offset values are stored as frame
fields or side data: how would this information be affected by filters
like "crop" or "scale"?
Regards,
Tobias
_______________________________________________
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".
