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. |
6th February 2020, 00:43 | #7381 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
git pull (like was mentioned above) More exact (like when following more than one upstream HEAD): git fetch <remote> git merge <remote>/<branch> which would look like: git fetch origin git merge origin/master (to update the master branch to its current remote state) If you don't care about being able to recover the file or commit history and just want raw download speed: git clone --depth 1 https://bitbucket.org/multicoreware/x265_git Git is, as others have noted elsewhere, basically a time-based file system that happens to work great as a DVCS. Mercurial is just a DVCS. |
|
6th February 2020, 02:00 | #7382 | Link | ||||
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
Quote:
Because I'm old and therefore much more impatient than you? Because I think that "huge and cheap" storage space is not an excuse for inefficiency? Quote:
Quote:
|
||||
6th February 2020, 06:15 | #7383 | Link |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Then do a shallow clone like we posted.
We are developers and functionality is much more important for us than a few hundred megabytes. No, huge and cheap storage is not an excuse for inefficiency, however this is not inefficiency, this is only "space" inefficiency. You don't say ffmpeg is garbage because it's a 60MB binary. BTW, compared to a few seconds of downloading, the actual compiling is much more time consuming. I'm too impatient but each time I compile my x265 mod it will take a good 2 hours on a Xeon E5 server. |
7th February 2020, 14:00 | #7384 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Since the media-autobuild suite switched to the x265 Git repository, I have trouble retrieving the sources. It seems like git receives all the expected data, but then suddenly handles the closing connection as if it was interrupted in an error. Here from an interactive MSYS2/MinGW console:
Code:
$ git clone https://bitbucket.org/multicoreware/x265_git.git x265_git-git Cloning into 'x265_git-git'... remote: Counting objects: 88154, done. remote: Compressing objects: 100% (88115/88115), done. remote: Total 88154 (delta 2853), reused 85263 (delta 0) error: RPC failed; curl 56 OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal because this is a curl debug build) Receiving objects: 100% (88154/88154), 277.47 MiB | 1.58 MiB/s, done. Resolving deltas: 100% (2853/2853), done. |
7th February 2020, 15:03 | #7385 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
I'll see if this Windows 7 hotfix has any impact...
Oh, it has been discontinued. I need Windows 10 to solve it. Or it is a different one? It's errno 0, not SysCall 10054. Cloning x264 and dependent ffmpeg/ffms2/lsmash works without abort. After x264 was retrieved (I deleted build/x264-git), now x265 was retrieved too? ... Strange technology. Last edited by LigH; 7th February 2020 at 15:34. |
7th February 2020, 16:20 | #7386 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
No issues with the change to x265 git. Just running smooth here.
Sent from my SM-G975F via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else. |
8th February 2020, 00:19 | #7387 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
|
|
14th February 2020, 09:11 | #7391 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
x265.exe 3.3_RC1+2-e386d3a8a713
(64-bits, multilib, GCC 9.2, Win32-threads) Code:
regression: fix analysis-save/load commands |
15th February 2020, 13:16 | #7392 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
|
|
16th February 2020, 05:58 | #7393 | Link |
Registered User
Join Date: Apr 2018
Posts: 61
|
Against the last 3.2x nightly builds, or against 3.2 release?
Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering. |
17th February 2020, 04:37 | #7394 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
Last edited by nakTT; 17th February 2020 at 04:52. |
|
17th February 2020, 22:19 | #7395 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Sent from my SM-T837V using Tapatalk |
|
18th February 2020, 15:55 | #7396 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
x265.exe 3.3+3-c2769ac5fa9d
Release notes: https://bitbucket.org/multicoreware/...leasenotes.rst download: http://www.mediafire.com/file/op10k0...c5fa9d.7z/file |
18th February 2020, 16:09 | #7397 | Link | ||
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
Quote:
|
||
18th February 2020, 16:51 | #7398 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,731
|
Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
18th February 2020, 18:13 | #7399 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I didn't mention the Adaptive frame duplication feature. This promises some significant efficiency savings and also faster random access for content where there are identical frames. Credits, screen activity, and anime/cel animation seem particularly likely to get improvements. I wish there was an optional flag that can allow --keyint to limit total encoded frames, so --keyint 240 would mean 240 unique coded frames. Thus, with 24 fps where the animation is at 8 fps (so three duplicate frames in a row), --keyint 240 would yield a GOP covering 30 seconds instead of 10. Not great for adaptive streaming, but could save space for a file without impacting random access. |
|
18th February 2020, 18:15 | #7400 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
With a codec as complex as HEVC, I would expect we'll be seeing material year-on-year encoder improvements for at least another five years. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|