[FFmpeg-user] SAR changes when stream copying y4m video to Matroska when SAR is present in source
Carl Eugen Hoyos
cehoyos at ag.or.at
Mon Jul 25 10:47:21 EEST 2016
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
More information about the ffmpeg-user