[FFmpeg-user] SAR changes when stream copying y4m video to Matroska when SAR is present in source

[Carl Eugen Hoyos]

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