On Fri, 11 Mar 2022 12:05:13 +0100 Andreas Rheinhardt <andreas.rheinha...@outlook.com> wrote: > Niklas Haas: > > On Fri, 11 Mar 2022 11:17:42 +0100 Niklas Haas <ffm...@haasn.xyz> wrote: > >> Oops. `-c copy` doesn't actually test the PNG writing code. Need to use > >> `-c png` instead. Fixed in v2. > > > > Hmm, actually, even this doesn't work. I can comment out the iCCP > > writing code and the iCCP chunk still gets written, somehow. Even though > > the file hash is different from the `-c copy` case! > > > > Any idea how to force a re-encode? > > What makes you believe that an iCCP chunk gets written? Is it the size > of the framecrc output? The reason for this is that this is the output > of the decoded png frame and not the hash of the demuxed packet or the > output file. The latter is included in the > +7e412f6a9e2c7fcb674336e5c104518d *tests/data/fate/png-icc.image2. > Comparing +49398 tests/data/fate/png-icc.image2 and the relevant line > from V1 shows that there is indeed more output. > You could use -c copy on the encoded file; and you can also use ffprobe > to directly inspect the side data. > > - Andreas
I was running the ffmpeg command (as printed by `make fate-png-icc V=1`) directly and using `exiftool` to look at the png-icc.image2 file it wrote. But it looks as though I accidentally ran the `-c copy` command twice during testing. With the `-c png`, the iCCP chunk is written by the new code, as intended. So never mind this comment. V2 appears to be testing correctly. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
