Re: [FFmpeg-devel] HAP QuickTime codec support
On Sat, 15 Nov 2014 12:34:57 +0100 Reimar Döffinger reimar.doeffin...@gmx.de wrote: Are you sure this compression format makes any sense whatsoever? You get a 1:6 compression (exactly, compared to RGB888), but also horrible compression artefacts. Simply going to half the resolution in x and y with YUV420 gives you 1:8 compression and I would bet it would even look better. At least I have a hard time seeing how it could look much worse. Looking at texture compression formats, I don't think any make much sense for video that is originally in 4:2:0 format. The first that might be interesting (but is limited to a few mobile devices) is ASTC. Besides better quality at same bitrate, it allow for (relatively) fine-grained per-frame compression ratio selection (and thus a kind of rate-control), enough encoding options for perceptual encoding and temporal compression (by using 3D textures). But even with those improvements the usefulness for video even compared to uncompressed seems questionable, especially since even with uncompressed textures you could implement delta encoding on the GPU. Well the intended use for me is solely to be able to process more videos in parallel from a single hard drive using the mentioned video compositing application, quality is (for now) secondary, but I will do some comparisons myself as soon as I can get my hands on a MacOS or Windows machine again. The problem with 4:2:0 (which we are currently using for most content) is that it is still too heavy on the CPU load to make streaming of many videos in parallel completely smooth, which is our primary requirement. Simply using uncompressed actually did not occur to me beforehand. Next time we get together I will see how far we can get with this until the drive's bandwidth is the bottleneck, which I fear might become an issue quickly. Thanks for having a look at this! Best regards, -- Patric Schmitz bzk0...@aol.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Mon, 17 Nov 2014 11:24:56 +0100 René J.V. Bertin rjvber...@gmail.com wrote: On Friday November 14 2014 18:47:53 bzk0...@aol.com wrote: We need Hap encoded videos to use them with a video compositing / VJing software on MacOS, Modul8 (http://www.modul8.ch/). When using lots of Really, MacOS? (MacOS =/= Mac OS X!) It is Mac OS X. -- Patric Schmitz bzk0...@aol.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Mon, Nov 17, 2014 at 09:52:31AM +0100, bzk0...@aol.com wrote: The problem with 4:2:0 (which we are currently using for most content) is that it is still too heavy on the CPU load to make streaming of many videos in parallel completely smooth, which is our primary requirement. Simply using uncompressed actually did not occur to me beforehand. Next time we get together I will see how far we can get with this until the drive's bandwidth is the bottleneck, which I fear might become an issue quickly. Thanks for having a look at this! I am not sure you understood my question/suggestion correctly. Uncompressed YUV 4:2:0 has half the bandwidth of uncompressed RGB, and any half-modern GPU can play it directly (MPlayer's -vo gl for example for one implementation). Reduce the resolution a bit and the bandwith is the same as with this codec (well, depending on compression mode). Also some of those old codecs are probably also an option if bandwidth to the GPU is not the problem. NUV (both with and without RT JPEG) and cinepack are examples for such codecs (though the latter is horribly slow to encode with FFmpeg at least). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, Nov 14, 2014 at 08:59:45PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 08:43:25PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote: Dear ffmpeg developers, is there any (planned) support for the Hap video codec in ffmpeg? https://github.com/vidvox/hap The implementation for Windows and Mac is available freely under a permissive license. Where is the actual source of these implementations? Above repository only contains some boilerplate wrapper, it lacks the core part: DXT (texture compression format) compressor/decompressor and is of very little value on its own. Seems it should be possible to use https://code.google.com/p/libsquish/, though unfortunately it is C++ code. Just using OpenGL drivers might give simple code, though it won't be regression-testable properly: https://www.opengl.org/sdk/docs/man3/xhtml/glGetCompressedTexImage.xml Are you sure this compression format makes any sense whatsoever? You get a 1:6 compression (exactly, compared to RGB888), but also horrible compression artefacts. Simply going to half the resolution in x and y with YUV420 gives you 1:8 compression and I would bet it would even look better. At least I have a hard time seeing how it could look much worse. Looking at texture compression formats, I don't think any make much sense for video that is originally in 4:2:0 format. The first that might be interesting (but is limited to a few mobile devices) is ASTC. Besides better quality at same bitrate, it allow for (relatively) fine-grained per-frame compression ratio selection (and thus a kind of rate-control), enough encoding options for perceptual encoding and temporal compression (by using 3D textures). But even with those improvements the usefulness for video even compared to uncompressed seems questionable, especially since even with uncompressed textures you could implement delta encoding on the GPU. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote: Dear ffmpeg developers, is there any (planned) support for the Hap video codec in ffmpeg? i dont know of anyone working on it but that doesnt say much ... do you want to work on implementing / porting it to FFmpeg ? https://github.com/vidvox/hap The implementation for Windows and Mac is available freely under a permissive license. If not, does anyone know of any other means of encoding with Hap under Linux? Thanks in advance -- Patric Schmitz bzk0...@aol.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, 14 Nov 2014 15:56:11 + (UTC) Carl Eugen Hoyos ceho...@ag.or.at wrote: bzk0711 at aol.com writes: is there any (planned) support for the Hap video codec in ffmpeg? Could you elaborate a little on the use-case? I am curious what hardware does not allow to playback the usual codecs but allows SSD upgrades. We need Hap encoded videos to use them with a video compositing / VJing software on MacOS, Modul8 (http://www.modul8.ch/). When using lots of video sources in parallel, the SSD optimizations really pay off and we are able to process much more content smoothly at once. There are transcoders for MacOS, so i don't critically depend on having it available. But since I do not own any Apple system myself it would be great if I could do the video encoding on Linux. Regarding developing this myself, I would be really interested, however I have a pretty tight time schedule at the moment due to my master's thesis. Best regards -- Patric Schmitz bzk0...@aol.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote: Dear ffmpeg developers, is there any (planned) support for the Hap video codec in ffmpeg? https://github.com/vidvox/hap The implementation for Windows and Mac is available freely under a permissive license. Where is the actual source of these implementations? Above repository only contains some boilerplate wrapper, it lacks the core part: DXT (texture compression format) compressor/decompressor and is of very little value on its own. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote: Dear ffmpeg developers, is there any (planned) support for the Hap video codec in ffmpeg? https://github.com/vidvox/hap The implementation for Windows and Mac is available freely under a permissive license. Where is the actual source of these implementations? Above repository only contains some boilerplate wrapper, it lacks the core part: DXT (texture compression format) compressor/decompressor and is of very little value on its own. Seems it should be possible to use https://code.google.com/p/libsquish/, though unfortunately it is C++ code. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] HAP QuickTime codec support
On Fri, Nov 14, 2014 at 08:43:25PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 08:37:47PM +0100, Reimar Döffinger wrote: On Fri, Nov 14, 2014 at 03:19:26PM +0100, bzk0...@aol.com wrote: Dear ffmpeg developers, is there any (planned) support for the Hap video codec in ffmpeg? https://github.com/vidvox/hap The implementation for Windows and Mac is available freely under a permissive license. Where is the actual source of these implementations? Above repository only contains some boilerplate wrapper, it lacks the core part: DXT (texture compression format) compressor/decompressor and is of very little value on its own. Seems it should be possible to use https://code.google.com/p/libsquish/, though unfortunately it is C++ code. Are you sure this compression format makes any sense whatsoever? You get a 1:6 compression (exactly, compared to RGB888), but also horrible compression artefacts. Simply going to half the resolution in x and y with YUV420 gives you 1:8 compression and I would bet it would even look better. At least I have a hard time seeing how it could look much worse. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
