2017-12-29 22:02 GMT+01:00 Devin Heitmueller <dheitmuel...@ltnglobal.com>: > >> On Dec 29, 2017, at 3:48 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> >> 2017-12-29 19:12 GMT+01:00 Devin Heitmueller <dheitmuel...@ltnglobal.com>: >> >>> + /* FIXME: Should really rely on the coded_width but seems like that >>> + is not accessible to libavdevice outputs */ >>> + if ((st->codecpar->width == 1280 && st->codecpar->height == 720) || >>> + (st->codecpar->width == 1920 && st->codecpar->height == 1080)) >>> + pkt->aspectRatio = ASPECT_16x9; >>> + else >>> + pkt->aspectRatio = ASPECT_4x3; >> >> I most likely won't use this (and I have never seen a decklink card) >> so please feel free to ignore: >> Similar code has caused some trouble with mxf files, is there >> really no saner solution? Like comparing what the actual aspect >> ratio is more similar to? Is SAR really always 1 for decklink? >> ("All the world's a VAX.") > > So this is definitely a confusing block of code, and you aren’t the first one > to > ask about it (there were questions in the last round of review as well). The > aspect ratio referred to here is actually of the original coded video - not > how > it’s supposed to be displayed. Hence, for example, 720x480 in widescreen > with a non-square PAR would still have the aspect ratio set to 4x3, since > that particular field describes the coded video (i.e. *not* how it’s supposed > to be rendered).
And a resolution of 1024x576 does not exist for decklink? What about 1920x1088? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel