Re: [FFmpeg-soc] Support for JPEG 2000 image files
Peter B. wrote: Hello, I hope this is the right list, since FFmpeg's JPEG 2000 support is always mentioned as Summer-of-Code project. I am currently evaluating the usage of free (as in free speech, not free beer) software tools (e.g. FFmpeg) for a national, long term video archive project. The plan is to store the archival copy of a video not as a video file, but each frame separately - using JPEG 2000 lossless compression. Therefore we'd need a tool that could handle encoding and decoding of JPEG 2000 image sequences to and from video files. My question now is: What is the current status of FFmpeg's JPEG 2000 support, and would it be possible to fund FFmpeg developers to finalize that feature - and if yes, whom should I contact? Thanks in advance, Peter B. Hi, try contacting Jai Menon at jmeno...@gmail.com. MvH Benjamin Larsson ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
On Sun, Dec 13, 2009 at 12:22:26PM +0100, Peter B. wrote: Hello, I hope this is the right list, since FFmpeg's JPEG 2000 support is always mentioned as Summer-of-Code project. I am currently evaluating the usage of free (as in free speech, not free beer) software tools (e.g. FFmpeg) for a national, long term video archive project. The plan is to store the archival copy of a video not as a video file, but each frame separately - using JPEG 2000 lossless compression. Therefore we'd need a tool that could handle encoding and decoding of JPEG 2000 image sequences to and from video files. My question now is: What is the current status of FFmpeg's JPEG 2000 support, and would it be possible to fund FFmpeg developers to finalize that feature - and if yes, whom should I contact? jpeg2000 is a poor choice as lossless codec, there are better ones like jpeg-LS which is simpler and has better performance [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
Thanks for the tip! I must admit that I haven't focused on JPEG-LS, because according to information about it I've found on the web, it seemed that JPEG-LS is less known/supported/used than JPEG 2000. Theoretically it seems a valuable alternative to JPEG 2000 by offering faster processing and better compression [1] in many cases, but there are some issues that I'd have to evaluate about JPEG-LS: - lack of applications/tools that support it (e.g. ImageMagick can't do JPEG-LS [2]) - partial data retrieval for thumbnail previews (possible with JPEG-LS?) For a long-term archive it is important to use open standards that are as widespread as possible. I was even surprised that given the age of JPEG 2000 it's still not supported as seamlessly as I'd expected. :( However, I'll reconsider JPEG-LS in my evaluation, because processing performance is still a major issue in this project. According to FFmpeg documentation [3][4], it is already supported as image format. Thanks, Pb [1] http://www.jpeg.org/public/wg1n1816.pdf [2] http://www.imagemagick.org/script/formats.php [3] http://ffmpeg.org/general.html#SEC5 [4] http://ffmpeg.org/changelog.html Michael Niedermayer wrote: jpeg2000 is a poor choice as lossless codec, there are better ones like jpeg-LS which is simpler and has better performance ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
On Sun, Dec 13, 2009 at 05:09:47PM +0100, Peter B. wrote: Thanks for the tip! I must admit that I haven't focused on JPEG-LS, because according to information about it I've found on the web, it seemed that JPEG-LS is less known/supported/used than JPEG 2000. well ffmpeg supports jpeg-ls encoding decoding, the code for that is just ~1000 lines: 89 397 2977 jpegls.c 377 1397 11414 jpeglsdec.c 395 1534 12249 jpeglsenc.c 41 193 1266 jpeglsdec.h 111 396 3014 jpegls.h 1013 3917 30920 total compare that to our unfinished jpeg2000 implementation: 384 1498 9557 dwt.c 389 1558 14122 j2k.c 1075 3923 36767 j2kdec.c 1045 3862 36837 j2kenc.c 108445 2975 mqc.c 93343 2396 mqcdec.c 119381 2738 mqcenc.c 63297 2038 dwt.h 234901 7335 j2k.h 75287 1902 mqc.h 3585 13495 116667 total or libopenjpeg through which ffmpeg supports jpeg2000 currently 187695 4491 bio.c 125608 3956 bio.h 190729 4872 cio.c 86478 3106 cio.h 40 63682 CMakeLists.txt 661 3146 19332 dwt.c 113681 4514 dwt.h 121547 3827 event.c 58367 2455 event.h 64366 2384 fix.h 87378 3038 image.c 48288 1854 image.h 119605 3554 int.h 2630 9970 77828 j2k.c 525 2548 17030 j2k.h 76421 2730 j2k_lib.c 75389 2632 j2k_lib.h 700 2398 18777 jp2.c 176800 5752 jp2.h 155701 4659 jpt.c 75390 2701 jpt.h 132700 3859 mct.c 98571 3860 mct.h 542 1757 13951 mqc.c 197903 5952 mqc.h 307905 8443 openjpeg.c 751 3311 24093 openjpeg.h 102380 2957 opj_includes.h 1078 3585 32188 pi.c 152837 5503 pi.h 87372 2653 raw.c 100538 3514 raw.h 1210 4372 30369 t1.c 295 1246 7667 t1_generate_luts.c 147680 5198 t1.h 402 6209 27167 t1_luts.h 721 2724 19951 t2.c 102586 3901 t2.h 1409 6049 51062 tcd.c 270 1293 8793 tcd.h 213740 5180 tgt.c 114608 4012 tgt.h 14740 64934 460447 total Theoretically it seems a valuable alternative to JPEG 2000 by offering faster processing and better compression [1] in many cases, but there are some issues that I'd have to evaluate about JPEG-LS: - lack of applications/tools that support it (e.g. ImageMagick can't do JPEG-LS [2]) As you can see above jpeg-ls is quite a bit simpler thus also simpler to add. And we have a jpegls implementation while we dont have a finished jpeg2000 one not counting the use of external libs like libopenjpeg. imagemagick surely could use ours ... - partial data retrieval for thumbnail previews (possible with JPEG-LS?) you can decompress the whole frame and scale it down, you can also store that image in the video file in some user data or in a seperate file for faster access. You can even store the whole video as lossless jpeg-ls + in a seperate file some lossy codec like mjpeg, h263 or mpeg4 or h264 (maybe at a lower resolution). The options are many Also as you mentioned support, how many jpeg2000 implementations support retrieving lower resolution content? ive not checked but i would suspect that not all support this. ffmpeg supports btw, decoding most DCT based codecs in lower resolution. For a long-term archive it is important to use open standards that are as widespread as possible. I was even surprised that given the age of JPEG 2000 it's still not supported as seamlessly as I'd expected. :( j2k is complex, we had 2 students during SOC fail getting the code in useable shape. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
Wow! Thank you very much for that detailed insight description. From what I've researched today on the web, JPEG-LS would be great for our archive project: It's faster, smaller and still an open standard. If it's so easy to add support for it, we could think about funding JPEG-LS integration into apps/tools we'd need for this archiving project. Of course, that's only reasonable with FOSS - and impossible with proprietary apps (which we try to avoid using at all, since vendor lock-in seems to be standard in professional video handling gear). Licensing and Implementation of JPEG-LS libs/tools is yet unclear (and as it seems, also for Debian packagers [4]): Did the FFmpeg team implement the JPEG-LS codec themselves or use an existing implementation? I'm asking, because the only available implementations I've found so far that look a bit reliable (and still maintained) are Loco-I by HP [1], CharLS [2] and the UBC implementation (which seems to be no longer accessible [3]) However, I think if I can find a commandline tool for JPEG-LS-to-something conversion, I could pipe that together with any image processing chain I'd need, so lack of client-side apps would not really matter. The additional overhead would probably still be less than handling JP2. Also as you mentioned support, how many jpeg2000 implementations support retrieving lower resolution content? ive not checked but i would suspect that not all support this. It's not mandatory, I'm just used thinking in possible long-term requirements/optimizations when thinking about archives. It would be awesome if JPIP (http://en.wikipedia.org/wiki/JPIP) was already a widespread option, but you're right: Sophisticated JP2 handling is hardly implemented. :( ffmpeg supports btw, decoding most DCT based codecs in lower resolution. Sounds useful - Although I'm not sure if I got you 100% right: lower resolution means less pixels or less quality? Is there any documentation about that you could point me to? Thanks again for your time, Peter == References == [1] http://www.hpl.hp.com/loco/ [2] http://charls.codeplex.com/documentation [3] http://www.stat.columbia.edu/~jakulin/jpeg-ls/ [4] http://www.mail-archive.com/debian-le...@lists.debian.org/msg40029.html ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
On Sun, Dec 13, 2009 at 10:31:55PM +0100, Peter B. wrote: Wow! Thank you very much for that detailed insight description. From what I've researched today on the web, JPEG-LS would be great for our archive project: It's faster, smaller and still an open standard. If it's so easy to add support for it, we could think about funding JPEG-LS integration into apps/tools we'd need for this archiving project. Of course, that's only reasonable with FOSS - and impossible with proprietary apps (which we try to avoid using at all, since vendor lock-in seems to be standard in professional video handling gear). Licensing and Implementation of JPEG-LS libs/tools is yet unclear (and as it seems, also for Debian packagers [4]): Did the FFmpeg team implement the JPEG-LS codec themselves or use an existing implementation? I'm asking, because the only available implementations I've found so far that look a bit reliable (and still maintained) are Loco-I by HP [1], CharLS [2] and the UBC implementation (which seems to be no longer accessible [3]) its our implementation AFAIK, but ask kostya if you want to be sure About debian, i assumethe libavcodec they include comes with jpeg-ls support but i didnt check. However, I think if I can find a commandline tool for JPEG-LS-to-something conversion, I could pipe that together with any image processing chain I'd need, so lack of client-side apps would not really matter. The additional overhead would probably still be less than handling JP2. i think so too also being simpler, jpeg-ls should also be easier to optimize if its not fast enough. [...] ffmpeg supports btw, decoding most DCT based codecs in lower resolution. Sounds useful - Although I'm not sure if I got you 100% right: lower resolution means less pixels or less quality? less pixels, its also less quality inevitably Is there any documentation about that you could point me to? the C source, grep for lowres ;) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Re: [FFmpeg-soc] Support for JPEG 2000 image files
On Mon, Dec 14, 2009 at 03:52:37AM +0100, Michael Niedermayer wrote: On Sun, Dec 13, 2009 at 10:31:55PM +0100, Peter B. wrote: Wow! Thank you very much for that detailed insight description. From what I've researched today on the web, JPEG-LS would be great for our archive project: It's faster, smaller and still an open standard. If it's so easy to add support for it, we could think about funding JPEG-LS integration into apps/tools we'd need for this archiving project. Of course, that's only reasonable with FOSS - and impossible with proprietary apps (which we try to avoid using at all, since vendor lock-in seems to be standard in professional video handling gear). Licensing and Implementation of JPEG-LS libs/tools is yet unclear (and as it seems, also for Debian packagers [4]): Did the FFmpeg team implement the JPEG-LS codec themselves or use an existing implementation? I'm asking, because the only available implementations I've found so far that look a bit reliable (and still maintained) are Loco-I by HP [1], CharLS [2] and the UBC implementation (which seems to be no longer accessible [3]) its our implementation AFAIK, but ask kostya if you want to be sure Welll, I borrowed some ideas from UBC implementation (it was the only one available at that time and I could verify our codec against it). [...] ___ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
