Making progress re: jpeg2000dec patchsets
Hi Caleb, Tomas et al., I have been experimenting with combining the HTJ2K patchset [1] and the J2K test patchset [2]: (a) neither valgrind nor the fuzzer seem to complain (b) there are code style/cosmetic issues (c) the HTJ2K block decoder does not yet support placeholder passes [3], which are not necessarily present I do not think that (c) is a blocker and recommend that we plan on merging the combined patchset once the code style/cosmetic issues are fixed. The idea is to have a baseline from which performance and feature set can be improved. Any major concerns with this plan? I am happy to take a stab at cleaning up the code, unless someone wishes to do it. Best, -- Pierre [1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8117 [2] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8108 [3] https://ds.jpeg.org/documents/jpeg2000/wg1n100431-098-COM-Guidelines_on_Pack...
Sorry for replying a bit late to this. Anyway:
Hi Caleb, Tomas et al.,
I have been experimenting with combining the HTJ2K patchset [1] and the J2K test patchset [2]:
(a) neither valgrind nor the fuzzer seem to complain
Excellent.
(b) there are code style/cosmetic issues (c) the HTJ2K block decoder does not yet support placeholder passes [3], which are not necessarily present
Can we error out in that case and ask for patches?
I do not think that (c) is a blocker and recommend that we plan on merging the combined patchset once the code style/cosmetic issues are fixed. The idea is to have a baseline from which performance and feature set can be improved.
Sounds good. /Tomas
I haven't seen an open source implementation that implements place holder passes, the best one is currently openhtj2k( https://github.com/osamu620/OpenHTJ2K) which only acknowledges their existence but doesn't do anything with them I would suggest we move forward if that's the only thing blocking this. On Mon, Mar 6, 2023 at 3:45 PM Tomas Härdin <git@haerdin.se> wrote:
Sorry for replying a bit late to this. Anyway:
Hi Caleb, Tomas et al.,
I have been experimenting with combining the HTJ2K patchset [1] and the J2K test patchset [2]:
(a) neither valgrind nor the fuzzer seem to complain
Excellent.
(b) there are code style/cosmetic issues (c) the HTJ2K block decoder does not yet support placeholder passes [3], which are not necessarily present
Can we error out in that case and ask for patches?
I do not think that (c) is a blocker and recommend that we plan on merging the combined patchset once the code style/cosmetic issues are fixed. The idea is to have a baseline from which performance and feature set can be improved.
Sounds good.
/Tomas
_______________________________________________ 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".
While supporting it is feasible, it requires significant changes which would probably interfere with this patch, hence the suggestion Kind regards, Caleb On Tue, Mar 21, 2023 at 5:33 PM Caleb Etemesi <etemesicaleb@gmail.com> wrote:
I haven't seen an open source implementation that implements place holder passes, the best one is currently openhtj2k( https://github.com/osamu620/OpenHTJ2K) which only acknowledges their existence but doesn't do anything with them
I would suggest we move forward if that's the only thing blocking this.
On Mon, Mar 6, 2023 at 3:45 PM Tomas Härdin <git@haerdin.se> wrote:
Sorry for replying a bit late to this. Anyway:
Hi Caleb, Tomas et al.,
I have been experimenting with combining the HTJ2K patchset [1] and the J2K test patchset [2]:
(a) neither valgrind nor the fuzzer seem to complain
Excellent.
(b) there are code style/cosmetic issues (c) the HTJ2K block decoder does not yet support placeholder passes [3], which are not necessarily present
Can we error out in that case and ask for patches?
I do not think that (c) is a blocker and recommend that we plan on merging the combined patchset once the code style/cosmetic issues are fixed. The idea is to have a baseline from which performance and feature set can be improved.
Sounds good.
/Tomas
_______________________________________________ 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".
participants (3)
-
Caleb Etemesi -
Pierre-Anthony Lemieux -
Tomas Härdin