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. |
3rd September 2020, 17:59 | #321 | Link |
Registered User
Join Date: Jul 2015
Posts: 706
|
I don't know how it is in the US, but in the EU popularization and lack improvement MP4 codec is justified by company patents and legal acts RODO or ACTA2. New codec AV1 in mp4 - ok, but codec description is limited and archaic. Is the description recommended for processed video? Not recommended.
Card payments were reluctantly introduced in logistics in the era of KV. And it turned out that nobody don't want to pay in the KV era. GPS in the movie, money and crazy vacations. It's tax proof on the tray. What youtube or facebook? The MKV container is considered by many companies as a pirate that has ruined DVD / Bluray. Great that it has extra subtitles, other functions. Unfortunately, it is for amateur programs. What will the MP5 be like? I have no illusions as a layman. The MP5 will be an even more encrypted container for fast tracking by security systems. Will MKV contain MPEG5 container under VVC ??? How should I know, but it probably won't be free. |
8th September 2020, 14:55 | #322 | Link | |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 345
|
News: x266 is already in development:
Quote:
|
|
12th September 2020, 23:34 | #323 | Link |
Registered User
Join Date: Apr 2018
Posts: 61
|
non-reference (?) VVC implementation by Fraunhofer HHI:
https://github.com/fraunhoferhhi/vvenc Seems to be in a very early state. Offers a simple encoder with 4 presets and one tuning option, and multithreading, but no screen-content features, together with a complex encoder which seems to be a re-implementation of the VTM. Last edited by Greenhorn; 13th September 2020 at 01:59. |
13th September 2020, 05:31 | #324 | Link | |
Registered User
Join Date: Jul 2015
Posts: 706
|
Quote:
Edit: Added encoder VVEncoderApp.exe: VVEncoderApp.exe --preset medium -i 111.yuv -s 1280x720 -t 4 -b 3000 -o str.266 Strange. Encoder isn't compatibile with Elecard StreamEye 4.5.974. Time consuming coding problem. The encoder and decoder have to be created separately. I don't know can user create any GOP? https://www.sendspace.com/file/tjn6vy Last edited by Jamaika; 13th September 2020 at 15:30. |
|
16th September 2020, 09:42 | #325 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
There is a test transmission on a european satellite for a VVC broadcast: https://www.digitalbitrate.com/dtv.p...&sec=0&lang=en
|
21st September 2020, 05:36 | #326 | Link |
Registered User
Join Date: Jul 2015
Posts: 706
|
I've been using GPAC MPEG4 very little lately. I noticed that 'initial tests for VVC support' has been added under OPENVVC.
I wonder. Will VVC be possible to import into MPEG4 container or become MPEG5 container? https://github.com/gpac/gpac/commit/...87924b47e2ba3e |
21st September 2020, 06:34 | #327 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Quote:
Astra 2E (28.2 ° E) tp. 14 (11.973 GHz, pol. V, SR: 31000, FEC: 9/10; DVB-S2 / 8PSK) It was an 8K H.266 VVC 20.55 Mbit/s before. Together with the audio channels it seems to be 27 Mbit/s now, though. Doesn't look bad: 8K VVC Screenshot I mean, sure, if you take a look at low lights like in this part, there's a lot of noise in both luma and chroma: And in other parts, everything looks blurry and averaged out, but still, we're talking about 20-27 Mbit/s for an 8K stream, so it's not really bad. As a matter of fact, broadcasting 8K contents at around 25 Mbit/s in H.266 VVC just like we're doing for 4K contents in H.265 HEVC at the very same bitrate would be a huge achievement. Besides, I would totally prefer a blurry approach compared to a blocky one; after all, blocking is immediately noticeable by human eyes, while blurring is kinda not. It looks like H.266 VVC continued with the same approach H.265 HEVC had and improved from there: (Remember that those last screenshots are parts of an 8K frame) Last edited by FranceBB; 21st September 2020 at 10:50. |
|
21st September 2020, 19:14 | #329 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
And the psychovisual value of a pixel at 8K is very, very different than at 1080p. Different kinds of visual distortion will have different impacts at such different pixel density. For example, dithering-like artifacts are going to be essentially invisible at 8K, since small-moderate differences between individual pixels are effectively invisible.
|
4th October 2020, 22:51 | #330 | Link | |
Registered User
Join Date: Dec 2012
Posts: 197
|
Quote:
The most relevant performance graph: The higher quality modes are still a magnitude too slow, but it's nice to see a (more) performant encoder that matches reference quality. If they add scene-change detection and rate-control, the project becomes an almost-useable enthusiast encoder. |
|
5th October 2020, 21:49 | #331 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
A huge but rarely discussed advantage of the MPEG line of codecs is that each generation is heavily based on the previous one. So it's relatively straightforward to take an existing encoder and add some of the tools of the next one to get a compliant bitstream of reasonable quality. Not easy in absolute terms by any means, but relatively easy compared to building an encoder for a new codec without high-quality encoders to start with. Back in the streaming wars, this was also a big reason why RealVideo and Windows Media codecs were able to come out with improvements so rapidly. Newer versions used the prior encoder as the basis, with new tools added. Being closed source and software only made compatibility a lot easier too, of course. H.264 was the first time an open standards based approach demonstrated a huge advantage over proprietary codecs, a testament to the effectiveness of having many experts and stakeholders collaborating together. |
|
21st October 2020, 23:33 | #332 | Link |
Registered User
Join Date: Mar 2004
Posts: 1,126
|
VTM 10.2 is out: https://vcgit.hhi.fraunhofer.de/jvet...VTM/-/releases
|
17th November 2020, 09:27 | #333 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
New upload: VTM Encoder Version 10.2 [Windows][GCC 10.2.0][64 bit] ec4bb116
|
8th December 2020, 23:30 | #334 | Link |
Registered User
Join Date: Nov 2020
Posts: 1
|
Calculating how many percent of the frame has been encoded using the affine transform
Hi, I am working on the latest version of VTM for VVC (10.2). I would like to know how many percent of a given frame is encoded using the affine transform. I assume that to figure it out, I need to know the total number of encoded macroblocks, and then how many of them were encoded using the affine transform, but I have no idea what lines of code in which encoder / decoder .cpp files I should add / modify. I would be grateful for any suggestions / tips. Thank you in advance
|
9th December 2020, 13:51 | #335 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Code:
ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe -vf scale=848:480:in_color_matrix=bt709:in_range=limited:out_color_matrix=bt709:out_range=limited,format=yuv420p 111.yuv | encoder.exe -i 111.yuv -b "raw_video.vvc" -wdt 848 -hgt 480 --Profile=auto --Level=5.1 --Tier=main --FramesToBeEncoded=150 --FrameRate=30000/1001 --InputBitDepth=8 --OutputBitDepth=8 --InternalBitDepth=8 --InputChromaFormat=420 --ProgressiveSource --IntraPeriod=-1 --GOPSize=4 --TargetBitrate=25000 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --Log2MaxTbSize=5 --ConformanceWindowMode=0 --SEIDecodedPictureHash=3 --BitstreamFile=vvc.bitsteam pause Output: Error: found fewer Reference Picture Sets than GOPSize Error: Invalid GOP structure given How can I set the reference picture sets? --ref doesn't clearly work and I can't find anything in the documentation Last edited by FranceBB; 9th December 2020 at 15:55. |
9th December 2020, 15:08 | #336 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
As this seems to be a question specific to x266, it might better be asked in the x266 VVC Encoder thread. This one is rather generic or related to the Fraunhofer HHI reference.
I just even learned that x266 is already available... Or not? Do you refer to the work of chenm001 who is not related to Multicoreware? Ooh, horay for trademarks. Last edited by LigH; 9th December 2020 at 15:12. |
9th December 2020, 15:57 | #337 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Ah, no, no, sorry (I made a mistake and pasted something I shouldn't have pasted), now I'm referring to the VTM reference encoder by Fraunhofer, the one Jamaika has been posting about all the time.
But yeah, there are a lot of weird naming conventions out there right now, it's a bit of a mess. And... no, x266 by Multicoreware isn't publicly available yet. Still, my issue is that I get Error: found fewer Reference Picture Sets than GOPSize Error: Invalid GOP structure given however I specified the correct GOP with a size of 4 and I set the --IntraPeriod to -1 which means automatic, so it should be ok. I also took care of the CTU size and made sure that all the Slices were the same (so at least equal or less than it) and I set --Log2MaxTbSize to be less than 6, as suggested. Still, it's complaining again. Why? Besides, I think it should really allow default settings to go through rather than throwing errors all the time. I mean, if someone doesn't specify anything, it throws an error 'cause it wants things to be specified. If someone specifies them wrong, it doesn't clearly work, however there's very little documentation (at least, that's what I've found). It's a bit of a pain to work with it, honestly... Last edited by FranceBB; 9th December 2020 at 16:01. |
Thread Tools | Search this Thread |
Display Modes | |
|
|