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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th March 2019, 04:38   #21  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by manolito View Post
Please I need some clarifications here...

Does this only apply to the X264 input, or does this mean that older player software or hardware won't be able to decode files created with this version any longer?
Applies to the 4:4:4 [i.e., without chroma subsampling] streams generated by the newer x264 binaries:

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
filler56789 is offline   Reply With Quote
Old 14th March 2019, 05:06   #22  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Thanks, I don't care about 4:4:4 chroma so I won't be affected...
manolito is offline   Reply With Quote
Old 14th March 2019, 07:48   #23  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th March 2019, 07:52   #24  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by LigH View Post
Quote:
Remove compatibility workarounds
This will break decoding with older versions of FFmpeg/Libav.
So keep your decoders up to date. I don't know how old is "too old" here...
Too old versions would mean versions before June/July of 2017. Corresponding patches where:
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.
MasterNobody is offline   Reply With Quote
Old 14th March 2019, 11:02   #25  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Okay ...
Quote:
Originally Posted by MasterNobody View Post
versions before June/July of 2017
means that ffmpeg v3.4 (released shortly after) should have it fixed already, and v4.x quite certainly.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th March 2019, 11:14   #26  |  Link
sneaker_ger
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.
sneaker_ger is offline   Reply With Quote
Old 14th March 2019, 11:35   #27  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by sneaker_ger View Post
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.
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
nevcairiel is online now   Reply With Quote
Old 14th March 2019, 11:35   #28  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
MABS update logs for x264-git report:

Code:
HEAD is now at d4099dd4 Remove compatibility workarounds
And it jumped from x264 0.157.2945 72db437 to x264 0.157.2969 d4099dd within few hours yesterday. So maybe there was a merge?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th March 2019, 11:44   #29  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by nevcairiel View Post
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.
I see.

Can confirm the changes are also already in the "official" binaries from videolan.
sneaker_ger is offline   Reply With Quote
Old 18th July 2019, 07:53   #30  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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
Luckily, there was quite recent activity.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 18th July 2019 at 07:56.
LigH is offline   Reply With Quote
Old 18th July 2019, 16:04   #31  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Any reason why VideoLan still has r2969 as the latest stable version? Is r2971 not ready for prime time yet?
manolito is offline   Reply With Quote
Old 18th July 2019, 18:40   #32  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by manolito View Post
Any reason why VideoLan still has r2969 as the latest stable version? Is r2971 not ready for prime time yet?
At this time, the x264 "master" branch is at r2984, and the "stable" branch is at r2980, both committed yesterday. VideoLAN apparently haven't updated their build since March 12th.

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.
LoRd_MuldeR is offline   Reply With Quote
Old 18th July 2019, 19:24   #33  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Ah, I built mine the day before. Maybe I will update soon™ again.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 18th July 2019, 20:00   #34  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
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) ?
manolito is offline   Reply With Quote
Old 18th July 2019, 20:35   #35  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 552
Quote:
Originally Posted by LoRd_MuldeR View Post
At this time, the x264 "master" branch is at r2984, and the "stable" branch is at r2980, both committed yesterday. VideoLAN apparently haven't updated their build since March 12th.

https://pastebin.com/HkvZdjnQ
If you were subscribed to the <x264-devel (at) videolan.org> mailing list, you would know that new binaries can be downloaded from the new URL:
https://artifacts.videolan.org/x264/
MasterNobody is offline   Reply With Quote
Old 18th July 2019, 21:26   #36  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by MasterNobody View Post
If you were subscribed to the <x264-devel (at) videolan.org> mailing list, you would know that new binaries can be downloaded from the new URL:
https://artifacts.videolan.org/x264/
Thanks for the info! Maybe the link on the x264 web-site should be updated to the new location then...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 19th July 2019, 12:40   #37  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 20th July 2019, 17:08   #38  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
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 -_-
filler56789 is offline   Reply With Quote
Old 20th July 2019, 18:04   #39  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
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
nevcairiel is online now   Reply With Quote
Old 20th July 2019, 18:47   #40  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by nevcairiel View Post
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.
HTTPS+git has never worked for me on Windows...
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
OTOH, the git protocol has always worked with the old URL, git.videolan.org/x264.git

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
filler56789 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:14.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.