On Tue, Jul 30, 2024 at 03:11:47PM +0200, Giovanni Mascellani wrote:
> I came across some H.264 files in the wild whose SAR is set to
> 20480/0. The files are provided by the Ubisoft game OddBallers, and
> are seemingly accepted and played properly when the game is played on
> Windows (thus using the Microsoft Media Foundations
> implementation).
> 
> When running the game with Wine the files are ultimately decoded by
> libavcodec (via GStreamer), and playback is broken. It seems that only
> a frame each second or so (maybe the key frames? I didn't check) is
> decoded and presented, the others are discarded. After dumping the
> video, I ran it with ffplay and it has the same problem, and the
> following message is emitted many times:
> 
>   [h264 @ 0x7fd7301ef440] ignoring invalid SAR: 20480/1
> 
> Interestingly the invalid SAR is dumped as 20480/1 (which would be
> strange, but in princple legal), while the file has 20480/0 (which
> doesn't make sense at all). Equally interestingly, the frames that are
> presented are indeed presented with SAR 1/1, like they are on Windows.
> 
> The H.264 standard says that "When aspect_ratio_idc is equal to 0 or
> sar_width is equal to 0 or sar_height is equal to 0, the sample aspect
> ratio shall be considered unspecified by this Recommendation |
> International Standard". Given the behavior on Windows it seems that
> the de facto standard way to solve the missing specification is to
> assume that SAR is 1/1, which is what my patches seek to do.

Why does playback fail ?

1/1 and unspecified are different things, 0/0 would be unspecified
where does 20480/0 turn into 20480/1 ? or did i misunderstand this?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA