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. |
24th January 2023, 14:36 | #741 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
For instance, you might have Grass Valley playout ports that play such a file and then output a signal via SDI. Such a signal is then received by an hardware encoder which encodes it as either MPEG-2 for SD channels, H.264 for HD/FULL HD channels and H.265 for UHD channels at consumer tier bitrates, generally around 2.5 Mbit/s for MPEG-2, 12 Mbit/s for H.264 FHD and 25 Mbit/s for H.265 UHD. Internally, though, it's really not uncommon to see those kind of mezzanine files used and stored/archived. Keep in mind that what users see is not what studios archive. As I said, AVID systems use DNxHR, which is quite similar and can reach similar bitrates. |
|
24th January 2023, 21:02 | #742 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
Quote:
__________________
madVR options explained |
|
31st January 2023, 19:11 | #744 | Link |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 337
|
The biggest takeaway from today's MulticoreWare x266 webinar: the codec has actively been developed, it's not ready yet, version 1.0 will be released as open source in the second half of this year. The webinar will be published later.
The codec is developed from scratch, i.e. code from VVenc and the VTM reference coder is not used but consulted with. ffmpeg integration is absolutely planned. A lot more was said and shared but I wasn't paying enough attention. |
1st February 2023, 01:28 | #747 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
It's still early stages, but x266 is currently 13.3 times faster than VTM15 using the same input sources (tested with both FULL HD and UHD materials) and settings thanks to the manually written asm, however it requires about 5% more bitrate. This is with lossy encoding, however it will also support lossless encoding. It's not open source yet but it will supposedly be in Q2 2023 although there's no official date just yet. Once it will, it will take a bit more time to implement a few more stuff 'till version 2.0, then the ffmpeg implementation will probably happen. Down the line GPU acceleration will also be something that will be looked into, however it won't be OpenCL lookahead like we had in x264, but something new entirely and probably CUDA based but it's really too early to tell.
This is the exciting official roadmap (in green it's what has already been done): I'm surprised not to see you at the zoom meeting, Ben. I would share the slides from the meeting but I just noticed that it says "confidential - limited distribution", so I guess you'll have to wait for the multicoreware guys themselves to upload them. Last edited by FranceBB; 1st February 2023 at 01:42. |
2nd February 2023, 21:15 | #749 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
Green team would be happy, but I doubt AMD / Intel / ARM/ Apple/ everyone else / would be happy Thanks for the info & progress update |
|
2nd February 2023, 22:14 | #750 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
They said that it's still really far too early to tell, v1.0 is barely there and a lot of coding tools + CPU Assembly optimizations need to be added before we'll even start to talk about that, however they said that given that NVIDIA has some nice things they can leverage on, they MIGHT consider CUDA. No problem, it's something I care about and I really look forward to gets my hands dirty and make some real comparisons myself as soon as the first build is out. |
|
10th February 2023, 22:18 | #752 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,041
|
As from some version of Microsoft DX12 at the beginning of 202x the motion estimation data from hardware MPEG encoder ASIC is now available as operation system API service (AMD/NVIDIA and in some time Intel accelerators independent) I hope the designers of MPEG codecs may finally start to use it. At least as some starting point of motion estimation with possible onCPU refinement. Though even in its initial release ME API have full mature precision of 1/4 pel. The progress may be with quality of motion vectors in the future ASIC releases (more correct MVs with naturally noised sources and many-frame analysis instead of current 2-frames only).
Last edited by DTL; 10th February 2023 at 22:21. |
13th February 2023, 12:23 | #755 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
Last edited by FranceBB; 13th February 2023 at 12:25. |
|
13th February 2023, 13:07 | #756 | Link | |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 337
|
Quote:
I want to compile the upcoming FFMPeg 6.0 release with these patches and start experimenting with VVC a lot more. I love the codec ;-) Last edited by birdie; 13th February 2023 at 14:26. |
|
13th February 2023, 14:35 | #757 | Link |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 570
|
I'm not sure but I think the reason is mostly that a native decoder in FFmpeg is preferable, and it is already an ongoing project.
So there isn't much point to adding vvdec, at least IMO.
__________________
LG C2 OLED | GitHub Projects |
13th February 2023, 17:48 | #758 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
|
Quote:
None of these patches were ever actually "rejected" at all, having a large patch set go through various iterations is entirely normal part of development, as reviews point out problems and improvements. This is just how the development process works. Large patchsets rarely get merged on the first try, even less so if they are from external contributors or companies, since those don't necessarily know all the details to make it work perfectly without review. It may be going slow as review bandwidth is limited, but there certainly was no rejection, and just the normal development process going on. And as pointed out above, a native VVC decoder for ffmpeg is actually in development as well, independent of vvdec or other external libraries. Contrary to some other projects, development of new features does not happen inside the main ffmpeg tree. So unfinished/in-progress things don't just get merged unless they are considered "finished", at least to a degree of being usable and not making future changes harder.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 13th February 2023 at 18:01. |
|
13th February 2023, 18:04 | #759 | Link | |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 337
|
Quote:
I've not seen a single development tree/tag/branch with anything VVC decoding related either. |
|
13th February 2023, 18:56 | #760 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
|
Quote:
The development tree is here: https://github.com/ffvvc/FFmpeg Its still quite under development and not finished yet, but should be somewhat usable. There is also a GSoC 2023 project listed to enlist a student to help with writing Assembly for it, as well as a general task to get involved with work on it, if you need any more "evidence" that its a real thing endorsed by the FFmpeg project itself.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 13th February 2023 at 19:03. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|