[FFmpeg-devel] [PATCH v2] avcodec/pngenc: support writing iCCP chunks

Niklas Haas Haas ffmpeg at haasn.xyz
Fri Mar 11 15:11:16 EET 2022


On Fri, 11 Mar 2022 12:05:13 +0100 Andreas Rheinhardt <andreas.rheinhardt at outlook.com> wrote:
> Niklas Haas:
> > On Fri, 11 Mar 2022 11:17:42 +0100 Niklas Haas <ffmpeg at 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.


More information about the ffmpeg-devel mailing list