FFmpegSource

[Thunderbolt8]

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?

[qyot27]

Originally Posted by Thunderbolt8

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?

Either you encode it through ffmpeg.exe, or ffdshow-tryouts VfW interface (although ffdshow is way, way outdated; you can't use FFV1v3, you're restricted to v1).

[filler56789]

Originally Posted by qyot27

FFMS2 C-plugin 1140+101

Many again.

I switched to your C-plugin "ages ago" , and I never looked back

[TheRyuu]

Originally Posted by FranceBB

FFMS2 v 2.23 - Windows XP

https://drive.google.com/file/d/0BzH...ew?usp=sharing

Yep, it's working!
There are several dlls you'll need to put in your plugin folder because FFMS2 uses some APIs that are not natively available in XP.
(you may get some "weird" error at the startup, but it's just a warning, it will load)

Dlls are x86 only.

Enjoy!

The official build works on XP. I've no idea how you're building this but it looks very very wrong with those included dependencies. What exactly is wrong with linking to the static runtime? Why are you including Windows system files?

In any case I cannot recommend anyone use this since the official builds should still work perfect fine with XP and don't contain the dll hell that this does. Using the system dll's from this package also has the potential to be dangerous.

[manolito]

Originally Posted by qyot27

FFMS2 C-plugin 1140+101

Thanks so much for this version, works perfectly on my WinXP Non-SSE2 computer...

So far I was using version r1103 because the followup version FFMS2 C-plugin r1110+98 crashed right on startup. But this new version is perfect.

And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.

Except for you XP users. HAHAHAHAHAHAHAHAHA

Funny how such a very disrespectful remark triggered a lot of activity in this area...


BTW I tested the official Myrsloik release and the FranceBB release on my old Non-SSE2 machine, and they both did not work. Probably because they both expect a CPU with SSE2 capability.


Cheers and thanks again
manolito

[TheFluff]

Most things started requiring SSE2 years ago. There really isn't much benefit to supporting 15 year old CPU's when SSE2 brings so much useful stuff.

XP is kinda the same, nobody wants to test that shit and maintain additional codepaths (however few they might be) for a 15 year old OS that like three people on d9 use (it's the same three or four people who pop up every time this gets brought up). It's just not worth the effort, so if you want support you better provide it yourself - and do it right, don't ship with this huge pile of DLL garbage you found God knows where.

Sticking to XP is pure obstinacy at this point. If you're concerned about UGH EVIL M$!!! business practices you could just switch to Linux - while it has its own issues, not supporting modern software on old hardware isn't one of them. There's a reason we don't respect XP users: if you insist on using an ancient OS, you should expect to have to use ancient software with it. It's your choice to remain stuck in the past, nobody's forcing you to do it.

[FranceBB]

Use the official ones, don't use mine. I'll remove the link.

Edit: link removed.

Anyway, I'm sure I tried a previous releases (the test build he released before the official ones) and they didn't work in XP saying "it's not a valid C plugin". That's why when he released the new stable version, I didn't even download it, because I was sure they wouldn't have been working anyway. Then I read the comment, so... xD
Anyway, since the official ones work, there's no need to use mine, so I removed the link
Thank you for supporting XP

[qyot27]

Originally Posted by manolito

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.

The problem hasn't really been sorted out (I said I was still getting Access Violations when using a couple of the patches not included in the newest build), but whether the problem with Access Violations I was referring to getting hit by in the first half of the year is the same problem with them I'm seeing now, I don't know.

[StainlessS]

It's strange what some people get their knickers in a twist over.
Come on Fluffy, stop living in the past and get on with your own life
(and let others get on with theirs).

[Myrsloik]

You're right, I shouldn't have posted those statements. Without a trigger warning. I'm so sorry about that. It's really great that we can settle this in a civilized and progressive way.

[FranceBB]

Myrsloik:
TRIGGER WARNING

The posts contained in this thread may be very upsetting for users of old operating systems

lol...
Well, now we have been warned xD

[GMJCZP]

Thank you for your builds, friends.

[Emulgator]

Because I have to maintain and run useful, but partly abandoned, and beautifully working software
from many different years across 8 different machines ranging from 2x XP32ProSP2, 3x XP32ProSP3, 2x Win7U64, 1x Win10...
Many thanks for the joint efforts to support XP, older hardware and the new stuff !

[Kein]

Original:

Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : 40
Duration                                 : 5mn 8s
Source duration                          : 5mn 7s
Bit rate mode                            : Constant
Bit rate                                 : 192 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 KHz
Compression mode                         : Lossy
Stream size                              : 7.19 MiB (1%)
Source stream size                       : 7.19 MiB (1%)
mdhd_Duration                            : 308000

Processed through FFMS2:



Is it, um, supposed to output it like that, pardon the dumb question?

Same recording opened through Vdub's FFMPEG's plugin:

[dipje]

what is weird with this output? That it outputs float?

Those audio compression formats are actually always something 'like float' internally. They most often don't have a concept of 'bitdepth' like hard PCM has.

So most decoders output to float if the other side supports it.
You see from that Vdub FFMPEG plugin screenshot that it also outputs to float (fltp) but the plugin directly converts the float to 16-bit integer.

The differences in length I wouldn't worry too much about. Most readers estimate the length by using the detected bitrate and such.

FFMS2 uses the index so it should know the exact number of samples so I'm betting it's the most precise length, the others lengths are estimates.

I (always) might be wrong though :P

[tebasuna51]

Originally Posted by dipje

I (always) might be wrong though

Nope, you are (here) right.

[leoenc]

Let's say I don't need indexing. How difficult would it be to disable it in the code? Is it completely rooted in the design of ffms?
Is there any reason to expect problems when not indexing? Considering ffms is only used to decode the full source linearly. No trimming, no filters.

[Groucho2004]

Originally Posted by leoenc

Is it completely rooted in the design of ffms?

Yes (pretty sure).

Originally Posted by leoenc

Is there any reason to expect problems when not indexing?

The decoder won't work.

Originally Posted by leoenc

Considering ffms is only used to decode the full source linearly. No trimming, no filters.

In that case use DSS or AVIsource, no indexing required.

[LigH]

Yes, indexing is a quite important part of FFMS2, it will not rely on container formats having any keyframe index at all, but instead gather positions of all keyframes on its own, which is necessary for quick seeking across the whole movie to be able to know the decoding start position of each GOP (this is even more important when decoding with several threads).

But you can use FFVideoSource(cache=false); in this case, no cache file will be generated, instead a keyframe index will be kept in RAM. Still, it needs to be generated, each time you run the script.

If you don't want indexing at all, but rely on the container having a valid keyframe index (or a source filter handling the source format anyway), you have to use a different source filter. AviSource will use a keyframe index chunk in AVI containers. LSMASHVideoSource does this for ISO Media containers (MP4, MOV, 3GPP...). DSS2 in LAV Filters mode will use a local copy of LAV Filters and rely on their wits to handle the source format. And any DirectShow related source filter will rely on DirectShow ... (usually an "optimistic" solution).

[Myrsloik]

There's basically only one container where you most of the time don't need an index: AVI

This is under the assumption that the container index is correct and that dropped frames duplicate the previous frame. But with all these restrictions you can (more or less) just use the ffmpeg api directly without doing any fancy tricks.