FFmpegSource

[LigH]

Would it be easy/complicated/expensive/illegal to have FFMS2 support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

[stax76]

Would it be easy/complicated/expensive/illegal to have FFMS2 support HWAccel (https://trac.ffmpeg.org/wiki/HWAccelIntro) features of ffmpeg for decoding?

IIRC it's already supported but don't work (I don't remember if it was l-smash or ffms2), maybe you can find something in the docs.

[LigH]

Again, regarding playlist support:

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

A similar case just came up, a consumer camera recording MTS segments of up to 2 GB per piece, due to FAT32 restrictions of SD*C memory cards. Using a source call for each MTS segment separately goes out of memory easily on a 32 bit AviSynth.

I believe any source plugin supporting MPLS could help here. At the moment, the owner of such a camera may have to buy DGDec* or concatenate the segments before use.

[TheFluff]

Playlist support was rejected in the core since it just added a dependency on a playlist parser lib for no good reason (it could just as well be done on the calling side of the API). For VS there's ReadMPLS (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-ReadMpls) as a standalone thing but I really don't think anyone cares about 32-bit Avisynth anymore.

[LigH]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

[Myrsloik]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

Yes, it's 2017. You're free to write a wrapper that creates/destroys source instances in a memory conserving way if you really care.

[LigH]

... if I was a C/C++ programmer. What I am not; I am only a user. So I have to hope that more competent people than me are able.

I am not sure if implementing a support for playlists is more complicated than implementing a different "partially shared" handling for source plugins which must be re-entrant per se.

I hope AviSynth+ author(s) know better.

Apart from that: What if a large medium is split without respect of GOP or even frame borders? It would be perfectly legal. Independent treatment of such segments would be a loss of content, instead. Thus, handling several source plugin instances would be a failure, in contrast to handling segments as continuous stream; but that would only work in a playlist.

[sneaker_ger]

Would it be difficult to implement ffmpeg's concat features (e.g. the "concat demuxer")?

[Myrsloik]

Would it be difficult to implement ffmpeg's concat features (e.g. the "concat demuxer")?

That's kinda been considered but I stopped thinking about it after d2vsource was released. It's useful for real segmented stuff at least that won't decode properly with just multiple sources. Add it to the maybe pile (create an issue about it if you want to make sure I don't forget it). I'm a busy person at the moment.

[TheFluff]

So because a 64-bit AviSynth is less likely to run out of memory, supporting playlists (not only for convenience, but even for correct handling of segmented media formats) becomes automatically irrelevant?! :confused:

Segmented source files is a different thing. As far as I know MPLS isn't that, it's literally just a playlist.

As far as your whining about running out of memory goes, I created 20 ffms2 instances for a 2GB MP4 in VS and the entire process ate less than 500 MB memory, so, well. It's kind of an insult from the 1970's, but really, if you want to encode big video files maybe you should get a real computer? Or if you have a real computer, stop using 32-bit Avisynth; it's not like there's been any reason to use it other than pure obstinacy for the last few years. You're kinda complaining about getting wet when you go outside in the rain while intentionally not bringing your umbrella, here.

[LigH]

Regarding my "whining":

a) not mine, just reporting what happened to another person; in the meantime we discovered that he used a way to open sources which took a lot more RAM per clip, but not yet why he claims to be unable to use a different source plugin as well as the 64-bit AviSynth+ at all. We will now concentrate on debugging these issues first.

b) it would be technically wrong anyway to use a sequence of source calls separately on each segment, because segments could be split regardless of GOP or even frame borders. Instead, one single source call would have to process a sequence of segment files. But how do you tell the order of the sequence, if not by using a playlist, in one or another form?

[TheFluff]

Segmented source files is a different thing. Didn't I just say that? I don't think MPLS is supposed to be used with things like GOP's split over file boundaries.

[LigH]

Then it would require a new proprietary "segmented sources sequence" (file list) format to be recognized as meta-input file. Similar to the header part of DG project files (the body part would already exist as the index file).

[TheFluff]

Why? If support for that kind of thing was added, the obvious way to access it would be to pass an array of filenames. If you want everything in a directory that starts with a given string and ends with .vob, just do the listing etc in Python. If you're using VS, that is.

[LigH]

No, the environment is still AviSynth{+}, no arrays here (maybe sprintf format string as alternative to a list file); and the owner of the mentioned camera has a sequence of MTS segments (similar to the content of Blu-ray, maybe, therefore the "obvious" thought of MPLS).

[TheFluff]

This would not be Avisynth specific if implemented, I'm talking about how it'd be exposed in the FFMS2 API.

[Andouille]

What does this have to do with video processing ?



Since crap Vapoursynth developers have read this wirthout replies...
NOTHING.

[Myrsloik]

Since crap Vapoursynth developers have read this wirthout replies...
NOTHING.

It has everything to do with video processing. You are NOTHING.

[mandarinka]

But what if Microsoft fixes the issue in the POSready branch? :devil:

[TheFluff]

Yes, and according to this:
https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
I will also not get a slowdown of my computer for up to 30% which these (future) patches will introduce... :devil:

Cheers
manolito

The 30% figure is a vast exaggeration even for actually syscall-heavy workloads in practice. The impact for video processing is completely negligible.

I'm also kind of amused that you're bringing up performance. Since you don't have SSE2 I'm gonna guess you have an Athlon XP, which was the last even remotely common desktop CPU line that didn't have that. The ultimate Athlon XP's (Barton) launched in 2003, fifteen years ago. One single core on my current CPU is at least four times faster than an Athlon XP 3200+, and I have six such cores with two threads each. I'm really not that worried about a few percent lower performance.

More seriously, using a non-SSE2 CPU for any serious work in 2018 would be - measured in years - like running an Intel 486 (launched 1989) was in 2004 when Barton CPU's were still relatively recent. You need to recognize it for what it is: a retrocomputing nostalgia trip. It's cute, but don't demand that people should support modern software on it. I really don't recommend accessing the web with an XP machine simply because of the alarming and constantly increasing number of unpatched security vulnerabilities, and you definitely shouldn't be doing anything sensitive on it. Even if you insist on doing it, you're probably going to get shut out from various internet-connected services sooner rather than later, because by June this year a lot of internet stuff is going to be requiring at least TLS 1.0, which the XP system crypto libraries do not support. You can keep browsing the web with Firefox for a few more months because it bundles its own crypto, but anything that relies on system cryptography is simply not going to work anymore, and once Firefox stops getting updates you'll gradually lose secure internet access because you won't get certificate updates anymore.

[lvqcl]

But what if Microsoft fixes the issue in the POSready branch? :devil:

Currently their position is: (https://support.microsoft.com/en-us/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe)

My Operating system (OS) is not listed. When can I expect a fix to be released?
Addressing a hardware vulnerability with a software update presents significant challenges and mitigations for older operating systems require extensive architectural changes. Microsoft is continuing to work with affected chip manufacturers and to investigate the best way to provide mitigations, which may be provided in a future update.

[FranceBB]

@lvqcl... and @TheFluff... Windows XP/POSReady machines will probably get the fix next week, on "patch Tuesday", together with other normal updates released every month 'till 2019.

[Andouille]

It has everything to do with video processing. You are NOTHING.

The impact for video processing is completely negligible.

Pretty :goodpost:

[Selur]

xp doesn't bother telling you about it.
lol,..

[mandarinka]

@lvqcl... and @TheFluff... Windows XP/POSReady machines will probably get the fix next week, on "patch Tuesday", together with other normal updates released every month 'till 2019.

Actually it seems that they won't. The kernel/user memory mapping split is apparently for 64bit only. Even 32bit Windows 10 don't apply it (small adress space maybe?) and leave Meltdown vulnerability open I guess. :scared::scared::scared:

https://twitter.com/aionescu/status/949442882062073856

[sneaker_ger]

When decoding TrueHD ffms outputs 32 bit (e.g. "Amaze (Lossless-ATMOS)" sample (https://thedigitaltheater.com/index.php/dolby-trailers/)). Isn't TrueHD 24 bit max?

[Myrsloik]

When decoding TrueHD ffms outputs 32 bit (e.g. "Amaze (Lossless-ATMOS)" sample (https://thedigitaltheater.com/index.php/dolby-trailers/)). Isn't TrueHD 24 bit max?

I didn't look at the file yet but basically there are no formats between 16 bit per channel and 32 bits per channel in ffmpeg. So most likely the decoder output it as 32 bit to not lose information.

[tebasuna51]

...but basically there are no formats between 16 bit per channel and 32 bits per channel in ffmpeg.

And what is this?: -acodec pcm_s24le

[dipje]

And what is this?: -acodec pcm_s24le

A codec name, not an internal processing format.

ffmpeg -sample_fmts:
name depth
u8 8
s16 16
s32 32
flt 32
dbl 64
u8p 8
s16p 16
s32p 32
fltp 32
dblp 64
s64 64
s64p 64

[tebasuna51]

Then ffmpeg is not a lossless decoder?

A lossless decoder must output the input depth of lossless formats, no mather the internal processing format.

[LigH]

Adding insignificant bits is no "loss", just "stuffing" (similar to video modes using 32 bit even though displays only support RGB 8880 with 24 bit, just because treating 24 bit data would be horribly slow, compared to stuffed 32 bits with DWORD memory alignment).

[dipje]

Then ffmpeg is not a lossless decoder?

A lossless decoder must output the input depth of lossless formats, no mather the internal processing format.

I guess.. from my own experience: Good luck changing minds on the ffmpeg-devel list :).

The thing to remember is, if they made sure the 'upscaling and then downscaling' produces bit for bit output, it's still lossless in my mind.

If you have a lossless 24bit integer codec, that outputs to 32bit integer in the ffmpeg pipeline, but the final output codec is pcm_s24le and they made sure the 'downscaling' procudes the exact same bits, it's lossless. At least to me :).

The moment you apply filters / effects / calculations on the s32 material, then yes, downscaling to pcm_s24le won't be bit for bit the same.. but you applied filters / effects, so lossless is out of question anyway.

Take a (short) 24bit wav file. Export it as a raw file containing s24 audio samples. Now encode the original wav file to the lossless codec of your choice that works internally in 24bit integer. Decode it through ffmpeg, and convert it to a raw file containing s24 audio samples again. Compare - bit-for-bit - the two raw files. I'm guessing they will be the same.


edit:
I just bought an album in 'hires audio 24bit / 44khz flac' to have some true 24bit lossless source files :).
Decoded the flac file with the 'official' flac utility to raw pcm, little endian, signed.
Then ffmpeg -i <inputfile> -f s24le <output file>
I compared (binary) the two raw output files, they were exactly the same. Not a single bit different.
And when I do 'ffprobe <input file>' the flac file is reported as being 's32 (24 bit)'

So ffmpeg _is_ lossless. Yes, it decoded s24 to s32 and then truncates it to s24 again, but the result is still bit for bit the same.

[Myrsloik]

I need your opinion about changing the default ffms2 behavior. As you know interlaced h264 files return double framerate output and this isn't what most of you want. So I'm thinking about making dropping every other frame automatic. The only problem is that I don't know if this has any negative effects or not.

Are there any additional problems when doing this? I know some of you even automatically generate scripts where this is done.

[sneaker_ger]

Mixed content?

[Myrsloik]

Mixed content?

Ok, you got me there. Won't change it then

[sneaker_ger]

Would it be difficult to integrate DXVA? The software VC-1 decoder in ffmpeg has been buggy for many years and it seems no one is interested or able to fix it making it more or less useless.

[LigH]

I would enjoy seeing an update after more than a year. I believe the libav* core developed a bit since... maybe API's changed and need some adaption.

[sneaker_ger]

Yes, it's about time. There were even a bunch of fixes for the software VC-1 decoder recently so maybe it's finally useful now.

[Daemon404]

You are always free to build it yourself or follow on GitHub. There have been significant changes in FFMS2 since 2.23.1, and it's almost ready for a new release, I think.

I want to finish some required VP9 changes (needed to fix some ridiculous libavcodec stuff that broke), and the last bit of stuff needed to keep MP4 edit lists from causing sync issues. After those, an RC or two and a release?

[Gser]

Yes, it's about time. There were even a bunch of fixes for the software VC-1 decoder recently so maybe it's finally useful now.

So you are saying it is not useful now? What should I use instead?

[sneaker_ger]

Alternatives for VC-1:
DGDecNV (http://rationalqm.us/dgdecnv/dgdecnv.html)
FRIMSource (https://forum.doom9.org/showthread.php?t=169651)
DirectShowSource() with LAV Video (https://forum.doom9.org/showthread.php?t=156191) (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 copy-back or D3D11)
DSS2() with LAV Video (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 or D3D11 - at least until it's built with newest ffmpeg)
DSS2mod (https://forum.doom9.org/showpost.php?p=1699301&postcount=33) (DSS2 with LAV inbuilt, I don't know if there are more recent versions but it's probably still good enough for VC-1 Blu-Ray)

Basically anything not based on non-recent ffmpeg software decoder ..

[LigH]

You are always free to build it yourself ...

... if you have both the knowledge how to use the required tools in general, and to handle the quirks of this specific project.

Especially for software which requires a Microsoft Visual Studio, I cannot build it myself, because I lack both the installation of its building environment and the experience to use it. I am already happy to run an MSYS2 environment if there are no failures.

I don't mind waiting another week or more if there is some certainty that a competent person will have success faster than me learning a completely new technology, up to a level where I am not completely clueless when issues arise.

:helpful:

[DJATOM]

You should try VS2017 community edition, it's free and I don't see any problems with compiled binaries.
Prev. update had some bugs in compiler (it was crashing on attempt to compile few projects), but now they are fixed.

[LigH]

Is there a verbose guide how to compile FFMS2? ffms2-api.md (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-api.md) is a bit too brief for my level of VS knowledge. It would probably take a while to learn how to start a compilation, and where to take header files from and where to copy them to, and ...

It feels like telling me "just drive this car" when I am just used to driving a bicycle.

[Gser]

Alternatives for VC-1:
DGDecNV (http://rationalqm.us/dgdecnv/dgdecnv.html)
FRIMSource (https://forum.doom9.org/showthread.php?t=169651)
DirectShowSource() with LAV Video (https://forum.doom9.org/showthread.php?t=156191) (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 copy-back or D3D11)
DSS2() with LAV Video (in LAV Video do not deactivate WMV MFT decoder, or use DXVA2 or D3D11 - at least until it's built with newest ffmpeg)
DSS2mod (https://forum.doom9.org/showpost.php?p=1699301&postcount=33) (DSS2 with LAV inbuilt, I don't know if there are more recent versions but it's probably still good enough for VC-1 Blu-Ray)

Basically anything not based on non-recent ffmpeg software decoder ..
Thanks, I have used all of those DSS versions at some point but due to its fps issue I moved to ffmpegsource. I did not know about FRIMSource, it seems to be working nicely.

[LigH]

L-SMASH Works for AviSynth was just updated as well. VapourSynth version may follow?

[Gser]

L-SMASH Works for AviSynth was just updated as well. VapourSynth version may follow?

Yeah the newest L-smash does not work for VC-1 at all,at least not in avs+. Getting super corrupt frames with grey bits everywhere.

[LigH]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).

[l33tmeatwad]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).
Oops, it's fixed now.

[Gser]

Well, l33tmeatwad (https://forum.doom9.org/showthread.php?p=1843162#post1843162) added a shared FFMS2 (so his shared L-SMASH Works build can use the same libav DLL's) ... but he made a mistake:

Note: The FFMS2_2.23.1_MSVC_SharedLibs.7z contains 64 bit libav DLL's in the x86 subdirectory. The ones in LSMASHSource_r941_MSVC_SharedLibs_hydra3333.7z are correct for 32 bit.

Regarding VC-1 decoding, as replied in the L-SMASH Source thread (https://forum.doom9.org/showthread.php?p=1844785#post1844785) already: It seems that there is a splitter issue; FFMS2 does it correctly. — Known as L-SMASH-Works issue #58 (https://github.com/VFR-maniac/L-SMASH-Works/issues/58).
I updated to that version of FFMS2 and now I get this error
Process exits with error: 0xC000007B STATUS_INVALID_IMAGE_FORMAT (-1073741701)
I didn't get any errors before.