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. |
14th March 2019, 04:38 | #21 | Link | |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
Code:
- if( i_csp >= X264_CSP_I444 && h->param.b_cabac ) - { - /* Disable 8x8dct during 4:4:4+CABAC encoding for compatibility with libavcodec */ - h->param.analyse.b_transform_8x8 = 0; Last edited by filler56789; 14th March 2019 at 04:38. Reason: disambiguation |
|
14th March 2019, 07:48 | #23 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
I assume that libav fixed the decoding of strict video streams already a while ago, so x264 can now safely remove the compatibility changes for libav before a threshold date. But I don't know which date.
|
14th March 2019, 07:52 | #24 | Link | ||
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
FFmpeg avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 Libav h264_cabac: Fix CABAC+8x8dct in 4:4:4 h264dec: fix Lossless Decoding (Profile 244) for 8x8 Intra Prediction With old versions of FFmpeg/Libav you can have problems decoding lossless or 4:4:4+CABAC streams encoded with new x264. |
||
14th March 2019, 11:14 | #26 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
You can remain compatible to "old" and "new" lossless ffmpeg decoding by setting --no-8x8dct at <1% compression loss.
But: is "Remove compatibility workarounds" really in your builds? It's still only part of the "master", not the "stable" branch. Has been like that since almost 2 years now. |
14th March 2019, 11:35 | #27 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Actually "Remove compatibility workarounds" was only in the experimental sandbox for 2 years, it moved to master 7 days ago, and will presumably be in the next stable push, unless they take it back out at some point, since stable is generally "just" an older master.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
14th March 2019, 11:35 | #28 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
MABS update logs for x264-git report:
Code:
HEAD is now at d4099dd4 Remove compatibility workarounds |
14th March 2019, 11:44 | #29 | Link | |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
Quote:
Can confirm the changes are also already in the "official" binaries from videolan. |
|
18th July 2019, 07:53 | #30 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
New upload: x264 core:157 r2971 98ee9d2
Code:
x264 0.157.2971 98ee9d2 (libswscale 5.4.101) (libavformat 58.28.102) (ffmpegsource 2.31.0.0) Win32: built on Jul 17 2019, gcc: 9.1.0 Win64: built on Jul 17 2019, gcc: 9.1.0 x264 configuration: --chroma-format=all libx264 configuration: --chroma-format=all x264 license: GPL version 2 or later libswscale/libavformat/ffmpegsource license: GPL version 2 or later Last edited by LigH; 18th July 2019 at 07:56. |
18th July 2019, 18:40 | #32 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
https://pastebin.com/HkvZdjnQ
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 18th July 2019 at 18:42. |
|
18th July 2019, 20:00 | #34 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Thanks for the info...
This leads to the question how well new commits are tested before they are called stable. From FFmpeg I learned it the hard way that it is a bad idea to always use the very latest "stable" build because thorough testing is not a particular strength of the FFmpeg devs. Is this different for X264? Should I upgrade to a new stable build immediately after it is released, or is it wiser to stick with older versions until there is a real need for an upgrade (like support for new formats, important bug fixes etc) ? |
18th July 2019, 20:35 | #35 | Link | |
Registered User
Join Date: Jul 2007
Posts: 552
|
Quote:
https://artifacts.videolan.org/x264/ |
|
18th July 2019, 21:26 | #36 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
19th July 2019, 12:40 | #37 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
New upload: x264 core:158 r2984 3759fcb
Code:
x264 0.158.2984 3759fcb (libswscale 5.4.101) (libavformat 58.28.102) (ffmpegsource 2.31.0.0) Win32: built on Jul 19 2019, gcc: 9.1.0 Win64: built on Jul 19 2019, gcc: 9.1.0 x264 configuration: --chroma-format=all libx264 configuration: --chroma-format=all x264 license: GPL version 2 or later libswscale/libavformat/ffmpegsource license: GPL version 2 or later |
20th July 2019, 17:08 | #38 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
https://git.videolan.org/ says:
MOVING TO GITLAB We're moving projects to code.videolan.org, notably: - x264 - VLC for WinRT - VLC for Android - VLMC - NPAPI-VLC - libdvdread - libdvdnav - libdvdcss - biTStream - DVBlast - libdvbpsi - libbluray - libudfread - libaacs - libdplus Regarding x264 specifically (or at least), the problem is that it's impossible to clone the x264 repository on GitLab through git :–/ => git clone git://code.videolan.org/videolan/x264.git Cloning into 'x264'... warning: blah-blah-blah fatal: unable to connect to code.videolan.org: code.videolan.org[0: 88.191.250.9]: errno=No error Oh, yes, anyone can download the latest tarball or zipball through a web browser, but then the compiled binary doesn't show the correct version /commit number -_- |
20th July 2019, 18:04 | #39 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Did you construct that URL yourself? Because I don't see it anywhere on the GitLab page.
When you select the Clone button there, it'll give you a valid URL: https://code.videolan.org/videolan/x264.git - which works just fine with "git clone". The git protocol is being deprecated all over the web because its insecure and unscalable, in favor of HTTPS.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
20th July 2019, 18:47 | #40 | Link | |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
In this case specifically: Code:
$ git clone https://code.videolan.org/videolan/x264.git Cloning into 'x264'... fatal: unable to access 'https://code.videolan.org/videolan/x264.git/': error setting certificate verify locations: CAfile: R:/MAKE6T4/usr/lib/ssl/certs/ca-bundle.crt CApath: none EDIT 1: Okay, I found a workaround, and now git finally 1) "understands" HTTPS and 2) found the damn certificate because I created the directory where the stupid application expected to find it. </CASE_CLOSED> EDIT 2: So far Mercurial has never shown the limitations that git shows on Windows... Until 2 days ago, I had always used git with cmd.exe and in this way it only works with the git protocol... whereas Mercurial has always worked fine on the so-called command-prompt of Windows. Last edited by filler56789; 20th July 2019 at 19:41. Reason: edits |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|