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. |
![]() |
#9681 | Link | |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,530
|
Quote:
Yes but time to encode wav to mp3 with lame is not really a problem. Encoding video source can take several hours. And multipart or ABR Ladder to saturate CPU are simply well-known techniques in the professional world. For exemple ABR Ladder is full option include directly in x265 codec. Make multiscession encoding is option too and directly in handbrake. Why buy a $600 CPU to do the fastest possible encoding in AOM AV1, when you can do it 4 times faster with a $200 CPU using the right encoding technique.
__________________
Le Sagittaire ... ;-) 1- Ateme AVC or x264 2- VP7 or RV10 only for anime 3- XviD, DivX or WMV9 Last edited by Sagittaire; 2nd January 2025 at 20:52. |
|
![]() |
![]() |
![]() |
#9682 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
Since m4 pro only comes with severely overpriced memory, if you are planning on only use the CPU to do "work" (but why) that's just not worth it. Or maybe it's the other way around, the basic model of mac mini m4 is underpriced? You know, like the razor and blades model? I don't know, I don't own a mac. (wait a minute, m4 pro has 2 variants? and they are very different errrr it's a great cpu but apple is just confusing) It's a great chip, but it doesn't come as just a chip, I just don't want to buy it this way. (and the "large scale" customers are likely don't want as well) It seems like even a m4 in basic model mac mini has more transistors than 9950X (although with integrated memory and GPU), and with the best process node at the time, I'm not surprised that it's performant and efficient, and the best model (m4 max 12p+4e) can come close to 9950X with less power draw. Physics works, how surprising. I have to say this is very out of topic now. Last edited by Z2697; 3rd January 2025 at 10:25. |
|
![]() |
![]() |
![]() |
#9684 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 492
|
x265 v4.1+78-5223ea7
Built on January 03 2025, GCC 14.2.0 Win32/64 / 8bit+10bit+12bit https://bitbucket.org/multicoreware/.../branch/master DL : https://www.mediafire.com/file/86pd5zd03csrk67
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else. |
![]() |
![]() |
![]() |
#9685 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,871
|
Finally I have a working build with --frame-dup working and I'd like to play with it a bit, as I mostly encode animes.
What value of --dup-threshold should be ok? The default is 70 but it doesn't tell too much to me. Is there a way to calculate the "difference" between two frames in a way similar to what x265 does?
__________________
@turment on Telegram |
![]() |
![]() |
![]() |
#9686 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,179
|
Quote:
YDifferenceFromPrevious() UDifferenceFromPrevious() VDifferenceFromPrevious() and the corresponding YDifferenceToNext() UDifferenceToNext() VDifferenceToNext() |
|
![]() |
![]() |
![]() |
#9687 | Link | |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,871
|
Quote:
As far as I’ve read, it uses some sort of PSNR.
__________________
@turment on Telegram |
|
![]() |
![]() |
![]() |
#9690 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 4,955
|
Quote:
Since the setting hadn't been working until this, we've not had much experience with it. Experimentally, I'd play around with different values and look at how frames get classified in a bitstream analyzer (or just comparing the log file). What you want to see is frames that are duplicated in the source are mostly set as duplicated frames in the bitstream, and that frames that aren't duplicates in the source are distinct frames in the output. Anime tends to have more frames duplicates than not, and are pretty distinct between no dup and dup, so it's really the best case for this feature, and you can probably use a lot more aggressive settings than for other classes of content. |
|
![]() |
![]() |
![]() |
#9691 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,388
|
I take a look at the last Patman's commits, and didn't notice anything specific to a frame-dup fix. If it's fixed, it seems to be a side effect of something else (unless i missed something).
__________________
My github. |
![]() |
![]() |
![]() |
#9692 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
There're detailed explanations a few pages back in this thread. I think the claims about how it's "not working" or "now working" by tormento is untrustworthy. And what he actually means is that somehow on his computer the x265 crashed when enabling frame-dup, and is now not crashing, without any change to the code regadring frame-dup feature. Not how the feature itself is broken. No offense. I mean the fact that the observation changed without any related interaction is not trustworthy. Not the guy (hopefully). BTW, was there a x264 feature (or x264 mod) that does the similar thing? I think there was but I don't trust my memory. Last edited by Z2697; 15th January 2025 at 06:33. |
|
![]() |
![]() |
![]() |
#9693 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,871
|
Counter-order, guys.
It happens that I am not having --frame-dup working anymore. It's now crashing as the previous build did. I am trying to reproduce the conditions under which it worked without errors, i.e. resolution and parameters. Stay tuned but I fear it will be a long path, as it was a random test and I need to recall the conditions when it worked.
__________________
@turment on Telegram |
![]() |
![]() |
![]() |
#9694 | Link | ||
Registered User
Join Date: Feb 2022
Posts: 166
|
Quote:
If a decoder does not support VFR, they should (shall?) support Pic Timing SEI. The decoded frame PTS timeline should appropriately reflect this. Gaps in the timeline should be filled by using the appropriate pic_struct entry to deliver CFR. Quote:
EDIT: I dived in x265 codebase, and I think it does not set the frame PTS appropriately ![]() Last edited by cubicibo; 15th January 2025 at 12:52. |
||
![]() |
![]() |
![]() |
#9695 | Link | |
Registered User
Join Date: Apr 2017
Location: Hungary
Posts: 9
|
Quote:
TPU uses x265 with preset slow at 4K resolution. It fully saturates my 5900X and I'm guessing it fully saturates a 9900X as well. Yet, the 9900X is only 25% faster than 5900x while the 9950x is 27% faster than 5950x in he TPU benchmark and it sounds about right. Power consumption is on a different level though. The 9900X consumes around 170W fully loaded while an M4 Pro consumes less than 50W. Unfortunately X86 is years behind in this regards and also in single core performance. |
|
![]() |
![]() |
![]() |
#9696 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
And as I already mentioned, x265 with container output mod or FFmpeg libx265 can get around with that VFR "hack". As for the bits, x265 now signals that timing SEI for every frame, no matter it's duped (removed) or not. It results in I think around 2.5kbps for 24fps video. How many duped frames should be removed to compensate that (average out), and how to decide the thresholding... well I just don't even bother. But yeah, that will outweight the signaling overhead very soon. Worst case it's just a few kbps, not really a big deal at all. But since he is not seeing incorrect timing, the probability of that worst case happening is high. Last edited by Z2697; 15th January 2025 at 19:01. |
|
![]() |
![]() |
![]() |
#9697 | Link |
Registered User
Join Date: Feb 2022
Posts: 166
|
VFR can be signaled both on the entire stream or at a CWS level. But specifying the actual picture output-presentation delay is overly complicated here.
Anyway, it does not matter for the current problem. pic_struct should be used with CFR. But frame entry time in decoder must be adapted with respect to the last pic struct instruction. I can't find any such code in x265, so VBV conformance must be way off. |
![]() |
![]() |
![]() |
#9698 | Link | |
Registered User
Join Date: Aug 2024
Posts: 370
|
Quote:
It shouldn't be necessary for "normal" CFR, only for "de-duped" CFR. Last edited by Z2697; 15th January 2025 at 21:10. Reason: is pic_struct -> contains and utilizes pic_struct |
|
![]() |
![]() |
![]() |
#9699 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,871
|
Well, it happens that I've found something about the --frame-dup crashing on my PC.
The very same video can be encoded when
Video encoding returned exit code: -1073741819 (0xC0000005) Any idea?
__________________
@turment on Telegram Last edited by tormento; 15th January 2025 at 20:33. |
![]() |
![]() |
![]() |
#9700 | Link | |
Registered User
Join Date: Feb 2022
Posts: 166
|
Quote:
Since there's a copy paste error on the CLI documentation for --pic-struct (claims to be needed for HLG), I will assume they never tested the feature or verified it was working correctly. |
|
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|