On Thu, Jun 11, 2020 at 9:41 PM Michael Bradshaw <[email protected]> wrote: > > On Thu, Jun 11, 2020 at 9:42 AM Gautam Ramakrishnan <[email protected]> > wrote: > > > Got it. In that case we can safely ignore the patch to fix libopenjpeg. > > However, p1_03.j2k is one of the 2 files to have ppm marker. How could I > > validate a patch to add ppm marker? I need something to cross validate. > > Any suggestions for that? > > > Does the other file with a ppm marker have a sane pixel format? If not the > only the only way I can think of to test this is to hack ffmpeg to remap > the planes in libopenjpegdec.c (e.g., remap them to yuva format). You can > use that for initial validation but it'll have to be reverted when > committing/pushing. > > Long-term I'm not sure how one would regression test this without having a > different file with a sane pixel format. I'm not sure how feasible it is to > hack p1_03.j2k to remove a plane while retaining the ppm marker or perhaps > hacking opj_compress to add a ppm marker to a new test file. > _______________________________________________ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe".
The other image with a PPM marker has only 3 components. I guess it will be a recognized format. However, it has a marker which is not yet implemented in the native decoder. I guess I'll just implement the other feature and we will be able to test this as well. -- ------------- Gautam | _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
