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 26th February 2018, 16:31   #1  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
x264 (MABS build) with integrated FFMS2 and LAVF fails opening AVI sources

LoRd_MuldeR pointed me at it, and I can only confirm:

The x264 builds created by media-autobuild_suite including FFMS2 and L-SMASH Source (video codecs only = mode 6/"fullv") can't open AVI sources and eventually fall back to AviSynth, trying to use AviSource.

Code:
x264 -o *.mp4 *.avi
ffms [error]: could not create indexer
lavf [error]: could not open input file
avs [info]: trying AVISource... succeeded
...
I will try to create a full build (mode 4/"full"), wondering if possibly the limiting to video codecs only may cause issues. Could anyone else with enough insight possibly check if MABS might be misconfigured for this case? Or is it possible that there is indeed a mistake in current x264 sources?
_

In the meantime, issue #758 appeared, and commit c566f85; will build again...
__________________

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

Last edited by LigH; 26th February 2018 at 16:44.
LigH is offline   Reply With Quote
Old 26th February 2018, 17:08   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
Just want to add that the problem is not limited to AVI. Happens with MP4 or MKV as well.

The problem is always the same: FFMS reports "could not create indexer", and LAVF reports "could not open input file". Then x264 falls back to AVS.

Builds from here do not have FFMS enabled (unfortunately), but LAVF input does work.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 26th February 2018 at 17:11.
LoRd_MuldeR is offline   Reply With Quote
Old 26th February 2018, 17:46   #3  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th February 2018, 17:51   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
Quote:
Originally Posted by LigH View Post
I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.
Great. BTW, index is written to file (or reused from file) when using "--index" option.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 26th February 2018, 18:55   #5  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
Updated on MediaFire. Regards to wiiaboo for a quick response.

Fun fact: They are even smaller now.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th February 2018, 19:26   #6  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
It is working now, thanks!
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 2nd March 2018, 18:16   #7  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 182
I didn't thought that others stumbled upon this problem, too. I actually thought that it never ever worked at all and that no one used it so no one complained. It seems that I stand corrected. Just out of curiosity: When did it stop working?
PS: That they are smaller now is probably due to the disabling of some audio codecs. (I tested an earlier version of MABS and there was code for disabling, but it didn't work.) One can reduce the size of the builds even further:
The size of my light x264 build with MABS: 17376256 B (all builds are x64).
After disabling all bitstream filters and enabling the extract_extradata-bsf (my test show this to be needed to actually get the codec parameters from transport streams; the h2645_mp4toannexb bsf are not needed for h2645 in mp4/Matroska) this is down to 17159680 B.
After also (trying to, see below) disabling subtitle decoders this is down to 17126912 B.
And looking at the list of disabled codecs I noticed that quite a few audio and subtitle decoders aren't disabled. The reason: MABS currently only disables decoders for which there is an encoder of the same name (I think I will report this). Fixing this brings the size down to 14960128 B. (Side issue: I have observed that if the input file has an mp2 audio track, lavf now emits a warning that it couldn't find the codec parameters for this stream. This might also happen for other codecs; similar things might also happen with the currently used list of codecs to deactivate. Does anyone know a way to stop lavf emitting warnings for non-video codecs?)
Finally, I also disabled some of the things that ffmpeg enables by default, but which is (to the best of my knowledge) unusable for lavf inside x264.exe: I added --disable-amf --disable-d3d11va --disable-dxva2 --disable-iconv --disable-schannel --disable-cuda --disable-cuvid. Now the size is only 13884928 B.
The relevant part of my script now looks like the following:
Code:
                audio_codecs=(
                    $(sed -n '/audio codecs/,/external libraries/p' ../libavcodec/allcodecs.c | \
                      sed -n "s/^[^#]*extern.* *ff_\([^ ]*\)_decoder;/\1/p")
                )
                LDFLAGS+=" -L$MINGW_PREFIX/lib" \
                    log configure ../configure "${FFMPEG_BASE_OPTS[@]}" \
                    --prefix="$LOCALDESTDIR/opt/lightffmpeg" \
                    --disable-{programs,devices,filters,encoders,muxers,debug,sdl2,network,protocols,doc,bsfs} \
                    --enable-protocol=file,pipe \
                    --disable-decoder="$(IFS=, ; echo "${audio_codecs[*]}")" --enable-gpl \
                    --enable-bsf=extract_extradata \
                    --disable-amf --disable-d3d11va --disable-dxva2 --disable-iconv --disable-schannel --disable-cuda --disable-cuvid
                unset audio_codecs
Any suggestions/comments/improvements?
mkver is offline   Reply With Quote
Old 10th August 2018, 19:31   #8  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
Quote:
Originally Posted by LigH View Post
I just updated MABS and recompiled. x264 in 32 bit is already done, and here FFMS2 starts indexing (to RAM, I'd assume).

So I will release a new set soon.
Some new commits have arrived in the official development tree. Any chance for updated x264 builds?
https://git.videolan.org/?p=x264.git;a=summary

(Highlights seem to include "4:0:0 (monochrome) encoding support" and "Sony XAVC" support)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 10th August 2018 at 19:33.
LoRd_MuldeR is offline   Reply With Quote
Old 10th August 2018, 20:08   #9  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
New upload: x264 core:157 r2932 303c484

Code:
x264 0.157.2932 303c484
(libswscale 5.2.100)
(libavformat 58.17.101)
(ffmpegsource 2.30.0.0)
Win32: built on Aug  8 2018, gcc: 7.3.0
Win64: built on Aug  8 2018, gcc: 8.2.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 10th August 2018, 20:53   #10  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,039
Quote:
Originally Posted by LigH View Post
New upload: x264 core:157 r2932 303c484

Code:
x264 0.157.2932 303c484
(libswscale 5.2.100)
(libavformat 58.17.101)
(ffmpegsource 2.30.0.0)
Win32: built on Aug  8 2018, gcc: 7.3.0
Win64: built on Aug  8 2018, gcc: 8.2.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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 10th August 2018, 21:11   #11  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 903
Thanks for the update!
__________________
Win10 (x64) build 18362| GPU Caps Viewer 1.42.4.0
NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4)
NTSC | DVD: R1 | BD: A
Intel Xeon X5660 @2.80GHz
Sparktank is offline   Reply With Quote
Old 2nd November 2018, 14:14   #12  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
New (and updated) upload: x264 core:157 r2935 545de2f

Code:
x264 0.157.2935 545de2f
(libswscale 5.2.100)
(libavformat 58.19.102)
(ffmpegsource 2.30.0.0)
Win32: built on Nov  1 2018, gcc: 7.3.0
Win64: built on Nov  1 2018, gcc: 8.2.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 13th December 2018, 15:13   #13  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
New (and updated) upload: x264 core:157 r2935 545de2f

Code:
x264 0.157.2935 545de2f
(libswscale 5.4.100)
(libavformat 58.24.100)
(ffmpegsource 2.30.0.0)
Win32: built on Dec 13 2018, gcc: 7.4.0
Win64: built on Dec 13 2018, gcc: 8.2.1 20181207
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

Last edited by LigH; 17th December 2018 at 07:22.
LigH is offline   Reply With Quote
Old 14th December 2018, 06:05   #14  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,614
Thanks for the new build,
for me it is the fastest of all the current r2935 builds (only tested 32-bit version).

(Probably stupid) question:
What do I do with the included ffmsindex.exe?
I use X264 under StaxRip with the latest stable ffms2 version 2.23.1. I only use the 32-bit versions.
Should I replace the 2.23.1 version of ffmsindex with the version which comes with your build? Is it compatible, is it necessary, what are the advantages?

Cheers
manolito
manolito is offline   Reply With Quote
Old 14th December 2018, 06:12   #15  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
I am not sure myself how useful a separate indexer is, but MABS builds it along x264. So I assume that x264 can make use of the index files if they are provided together with a source file, and the FFMS2 demultiplexer is used in x264.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 15th December 2018, 21:26   #16  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,067
ffmsindex isn't built alongside x264, it's part of the FFMS2 build. It does nothing with/for x264.

From x264's --fullhelp,
Code:
--index <string>        Filename for input index file
I just tested it; that parameter makes x264 output the index from the initial pass to <output filename> rather it being used from RAM, and it also specifies a previously-generated index file to use, skipping the indexing step.

The FFMS2 version will have to match exactly for any index written by ffmsindex.exe or ffms2.dll (via AviSynth, for instance) to work with x264. And if the FFMS2 linked into x264 is static, then that only holds true for the exact binaries used there - if/when an update to ffms2.dll/ffmsindex.exe happens, FFMS2 will be newer than the one in x264 and force x264 to re-generate the index file rather than re-using it (or vice-versa; in my short test, x264 and its linked FFMS2 was newer - October 2018 - than the C-plugin build, from September).

In other words, only bother with ffmsindex if you're using FFMS2 as a plugin for AviSynth or VapourSynth, not when using the FFMS2 input on x264. If you're only using x264, stick with the indices it saves when using the --index parameter.
qyot27 is offline   Reply With Quote
Old 15th December 2018, 21:31   #17  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
sigh

And ffms2.dll is not built by MABS.

OK, so I can omit the separate indexer safely.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 6th February 2019, 17:34   #18  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
New (and updated) upload: x264 core:157 r2935 545de2f

Code:
x264 0.157.2935 545de2f
(libswscale 5.4.100)
(libavformat 58.26.100)
(ffmpegsource 2.30.0.0)
Win32: built on Feb  6 2019, gcc: 7.4.0
Win64: built on Feb  6 2019, gcc: 8.2.1 20181214
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 13th March 2019, 09:30   #19  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,936
New upload: x264 core:157 r2945 72db437

Code:
x264 0.157.2945 72db437
(libswscale 5.4.100)
(libavformat 58.26.101)
(ffmpegsource 2.30.0.0)
Win32: built on Mar 12 2019, gcc: 7.4.0
Win64: built on Mar 12 2019, gcc: 8.3.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
_

But wait! There's more...

New upload: x264 core:157 r2969 d4099dd

Code:
x264 0.157.2969 d4099dd
(libswscale 5.4.100)
(libavformat 58.26.101)
(ffmpegsource 2.30.0.0)
Win32: built on Mar 13 2019, gcc: 7.4.0
Win64: built on Mar 13 2019, gcc: 8.3.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
Interesting commitdiff remark:

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...
__________________

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

Last edited by LigH; 13th March 2019 at 10:50.
LigH is offline   Reply With Quote
Old 14th March 2019, 03:16   #20  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 2,614
Quote:
Originally Posted by LigH View Post
So keep your decoders up to date. I don't know how old is "too old" here...
Please I need some clarifications here...
Quote:
This will break decoding with older versions of FFmpeg/Libav.
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?

Out of curiosity I encoded a file with this latest r2969 32-bit version and tested if all my playing or transcoding software could handle it. No problem whatsoever, even under XP where I need to use some older decoders. And my Xtreamer box (latest firmware from 2011) also had no problems decoding the file.

Looks like a non-issue to me...


Cheers
manolito
manolito 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 04:57.


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