Kieran O Leary <kieran.o.leary <at> gmail.com> writes: > I posted a similar issue recently where an unknown SAR was > declared as 1:1 when stream copied to matroska.
Allow me to repeat that this is not correct: If SAR is unknown, no sar is written to mkv output (when stream copied or reencoded). The demuxer does indeed output a sar even if no sar was specified in the mkv file. This could be changed but as said, for 3D content with unspecified sar, the demuxer would have to output sar, so the change would make the behaviour less consistent. > I think this is a different issue because the SAR is > declared in the source in this instance. I am running some > tests on the xiph/derf collection and found that a lot of > the videos had different aspect ratios when stream copied > to matroska. > > I am wondering if this is an issue with the Matroska > specifcation or some issue with ffmpeg. For what it's worth, > I looked at the output file in mediaconch and PixelWidth is > listed as 176, and DisplayWidth is listed as 193. Which - without really verifying myself! - are probably the correct display dimensions for the given input. I don't know why FFmpeg writes display dimensions instead of DAR: My guess is that there are players which would fill the screen if your input would be remuxed with dar instead of display dimensions. (Difficult to test with your use case since many video players do not support rawvideo in mkv...) Feel free to open a ticket. > ffmpeg version N-44317-g7af44ce Unrelated: I am curious how this version string gets created (it should be "N-80980-g7af44ce"): What does the following command show for you? $ git describe --tags --match N Thank you for the interesting report, Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".