Re: [FFmpeg-devel] [PATCH 0/2] Interpret a degenerate SAR as 1/1.

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3061 bytes --]

On Tue, Jul 30, 2024 at 06:15:30PM -0300, James Almer wrote:
> On 7/30/2024 5:54 PM, Michael Niedermayer wrote:
> > 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
> 
> afair we use 0/1 for unspecified, since it prevents division by 0 without
> having to worry about extra sanity checks.

why this is a bad idea:

if a rectangle W/H with unspecified AR is 0/1, now the H/W rectangle has 1/0

OTOH if you use 0/0 then both W/H and H/W are naturally 0/0

what about scaling?

0/1 scaled by a/b is 0/b, while 0/0 scaled by a/b is 0/0

what about adding ratios ? 0/1 + a/b = a/b (thats not unspecified anymore)
OTOH
0/0 + a/b = 0/0 :)

so people may argue about this, but 0/0 behaves much closer to unspecified than 0/1
so fewer special cases are needed if 0/0 is used. And 0/1 really is 0 and 0
is not unspecified in a mathematical sense which is why it works so poorly for that

And in floats 0/0 is NaN which is again behaving much closer to unspecified.
If you do an operation with a NaN the result is NaN, same as if you do an
operation with a unspecified ratio, the result is unspecified

Thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".