Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
18th October 2020, 11:52 | #1 | Link |
Registered User
Join Date: Jul 2015
Posts: 697
|
New codecs 2020 with std::thread, mutex, condition_variable, future, invoke
As you know, the mingw compiler doesn't support such functions in C11/C⁺⁺11 under Windows. So pirate replacements are needed. Mingw substitutes don't take responsibility for the correct operation of the software because they are free add-ons. On many pages you can read rough answers like: what is Visual Studio for? Why are you posting mingw junk. My library supports a specific version of a different codec. It doesn't matter if it's five years ago and I'm not going to fix anything else {no extra money}. Github is a cloud for volunteers but not for amateurs and ignoramuses.
https://github.com/meganz/mingw-std-threads I have followed this trail for five years with doom9, which promotes developer programs on github. What can we meet in 2020? Compatibility, interchangeability and lossless storage of data between containers. Who needs it for? Who needs a universal container? That's what Adobe Photoshop is for. These assumptions and ideas could already be deduced from the first merging of all the old JPEG codecs in only into one container. Eg in libmox or jpegXL projections. However, there has been a clear distinction between video and photo codecs. There is nothing in the assumptions for JPEGXS about compatibility with MPEG5 containers. If they exist, because I am more and more convinced that mpeg5 will be in mp4. This is probably a joke. JPEGXS is tested on satellite, but no one has seen a free codec yet. It is also not known what about applications such as JPEG PLENO in C⁺⁺17, which is too modern to the old garbage C11/C⁺⁺11 for github and already too old for advertised with new features C⁺⁺20. What do we know about JPEG (LS) Lossless and the modified libJPEG XT? Everything indicates that they will remain less known libraries and will go down in history. What about openjpeg (2000)? This is an archaic project that patented the makers of jasper. But who needs HTJ2K when we have JPEGXS? It is about investing in patents from large companies that do not want to add novelties immediately. Hence there are transitional forms. There is nothing like transitional forms. The assumptions of JPEGXS creators are ambitious. They are designed to be compatible with all old video containers and more. Only who else uses MXF. JPEGXS and HEIF: I don't know anything about this. JPEGXS and MP4: it's probably a joke. Code:
Transport/Container Type Description – Main purpose extension RTP RTP Payload Format for IP-based transport JPEG XS (IETF draft) MPEG2-TS ISO/IEC 13818-1:2019 Carriage of associated CMAF boxes AMD1:2020 for audio-visual elementary streams and JPEG XS in MPEG-2 TS Video over SMPTE 2110-22:2019 Encapsulation of compressed video IP streams in SMPTE 2110 as RTP stream JXS JPEG XS file format For storing of single images .jxs defined in: ISO/IEC 21122-3 Annex A JPEG 2000 syntax based MP4 ISO Base Media File For storing of video .mp4 format (ISOBMFF) defined: ISOBMFF syntax based ISO/IEC 21122-3 Annex B HEIF High Efficiency Image For storing of mixed image .heif File Format defined in: and video content ISO/IEC 21122-3 Annex C MXF SMPTE 2124 (FCD) For storing of video .mxf MXF syntax based https://github.com/fraunhoferhhi/vvenc https://github.com/fraunhoferhhi/vvdec https://github.com/marksfink/cfenc https://gitlab.com/wg1/jpeg-xl https://github.com/strukturag/libheif Last edited by Jamaika; 18th October 2020 at 11:59. |
Thread Tools | Search this Thread |
Display Modes | |
|
|