Opened 4 months ago

Last modified 4 months ago

#9787 new defect

The movie filter fails to preserve SAR for png resource

Reported by: Arnon Owned by:
Priority: minor Component: ffmpeg
Version: Keywords: movie filter png sar
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Encoding a png image using a lossless codec, and then extracting the frame back out, the resulting image is identical to the source, as expected:

ffmpeg -i 000001.png -c:v libx264rgb -crf 0 test.image1.mp4
ffmpeg -i test.image1.mp4 t.1+%06d.png
cmp 000001.png t.1+000001.png

Using the (I believe) equivalent command with a movie filter input, the extracted image differs from the source, unexpectedly:

ffmpeg -filter_complex movie=000001.png -c:v libx264rgb -crf 0 test.image2.mp4
ffmpeg -i test.image2.mp4 t.2+%06d.png
cmp 000001.png t.2+000001.png
000001.png t.2+000001.png differ: byte 45, line 3

A hint comes from showinfo. This is the input:

[Parsed_showinfo_5 @ 0x55cd65f862c0] n:   0 pts:      0 pts_time:0       pos:        0 fmt:rgb24 sar:12/11 s:176x144 i:P iskey:1 type:I checksum:9E034500 plane_checksum:[9E034500] mean:[119] stdev:[67.4]

And this is the output:

[Parsed_showinfo_0 @ 0x5556aa2eb5c0] n:   0 pts:      0 pts_time:0       pos:       48 fmt:gbrp sar:1/1 s:176x144 i:P iskey:1 type:I checksum:CA0C4500 plane_checksum:[DE18A2C2 94056061 390141CE] mean:[118 120 120] stdev:[68.0 68.0 66.1]

So it looks like SAR is not preserved. This is confirmed by ffprobe, and indeed, setting SAR explicitly solves the problem:

ffmpeg -filter_complex "movie=000001.png,setsar=12/11" -c:v libx264rgb -crf 0 test.image3.mp4
ffmpeg -i test.image3.mp4 t.3+%06d.png
cmp 000001.png t.3+000001.png

I can reproduce this with ffmpeg 3.4.9 and ffmpeg 4.4.2.

Attachments (1)

000001.png (8.4 KB ) - added by Arnon 4 months ago.

Download all attachments as: .zip

Change History (3)

comment:1 by Balling, 4 months ago

Attach 000001.png and check with the only supported stable from master here:

by Arnon, 4 months ago

Attachment: 000001.png added

comment:2 by Balling, 4 months ago

Yes, indeed the file has (use exiftool)
Pixels Per Unit X : 12
Pixels Per Unit Y : 11

which means that this file has not square pixels.

The simplest and least correct approach is to ignore the chunk; most current viewers do this.
The best approach is to resample the image, a procedure that amounts to converting the image to a continuous (or analog) representation and then overlaying the desired pixel grid on that.

Of course in pratice that is not what should be done when you convert between formats that all have this metadata. t.1+000001.png also has the same metadata, so all is good. In fact the video itself has

176x144 [SAR 12:11 DAR 4:3]

while your filter_complex command does a video with

176x144 [SAR 1:1 DAR 11:9],

Is movie filter supposed to preserve PNG metadata?

Last edited 4 months ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.