GNOME Bugzilla – Bug 767957
gstjpeg2000.h : store all JPEG 2000 file format and code stream marker information in single header file
Last modified: 2016-09-23 00:17:06 UTC
And the name of the file shall be: gst_jpeg2000_file_format.h stored in gst-libs/gst/codecparsers/
*** Bug 767956 has been marked as a duplicate of this bug. ***
It seems like it should rather be called gstjpeg2000.h :) And at a later point this should probably move to libgstpbutils/codecutils.[ch]
Created attachment 330312 [details] [review] store file format and code stream info in header file
Comment on attachment 330312 [details] [review] store file format and code stream info in header file Not sure if those four 4s are worth their own header :) Opinions?
(In reply to Sebastian Dröge (slomo) from comment #4) > Comment on attachment 330312 [details] [review] [review] > store file format and code stream info in header file > > Not sure if those four 4s are worth their own header :) Opinions? I will be adding more information as I implement jp2 parsing. This patch is simply to get the new header created in the proper project, with proper naming conventions.
Created attachment 330324 [details] [review] store file format and code stream info in header file Flesh out the header a bit more :)
Let's get this in once it's actually used then :)
Created attachment 330445 [details] [review] store file format and code stream info in header file I am now using the new header in the jpeg 2000 parser, and also the j2k decimator. Eventually, would like to use in rtp payload/depayload, but I guess we would need to move the header into gst-base ?
It could end up in libgstpbutils for that, yes. Or alternatively copy the header for now and make sure the canonical location is mentioned at the top.
Review of attachment 330445 [details] [review]: ::: gst-libs/gst/codecparsers/gstjpeg2000.h @@ +98,3 @@ + GST_JPEG2000_PROGRESSION_ORDER_CPRL, + GST_JPEG2000_PROGRESSION_ORDER_MAX +} GstJPEG2000ProgressionOrder; Is this ever going to be used by anything but the decimator or a decoder/encoder?
(In reply to Sebastian Dröge (slomo) from comment #9) > It could end up in libgstpbutils for that, yes. Or alternatively copy the > header for now and make sure the canonical location is mentioned at the top. yes.
(In reply to Sebastian Dröge (slomo) from comment #10) > Review of attachment 330445 [details] [review] [review]: > > ::: gst-libs/gst/codecparsers/gstjpeg2000.h > @@ +98,3 @@ > + GST_JPEG2000_PROGRESSION_ORDER_CPRL, > + GST_JPEG2000_PROGRESSION_ORDER_MAX > +} GstJPEG2000ProgressionOrder; > > Is this ever going to be used by anything but the decimator or a > decoder/encoder? A parser may be interested in progression order changes - for example, a 4K image has one progression order change to separate the lower res 2K image from the full 4K image, so that decoders that do not support 4K can still decode the low res 2K image.
This is a nice-to-have refactor that isn't really necessary at this stage. Don't have time to revisit this now, so will resolve as WONTFIX.