[FFmpeg-user] Windows 10, ffmpeg concat/demux is slow... part 2

Carlos E. R. robin.listas at telefonica.net
Tue Nov 14 01:33:07 EET 2017

Hash: SHA1

On Monday, 2017-11-13 at 22:48 -0000, Kevin Duffey wrote:

> If Kevin can share two reasonable sized sample files, I can try the
> ffmpeg operation in my computer. Using Linux, though.
> And with sufficent memory: From RAM disk to /dev/null.

> First of all.. sorry for this again.. I installed Thunderbird.. and it doesnt appear to work well if at all with yahoo mail. Then somehow it
> sent an email to one person on this thread, but now I am getting non stop error messages. Such a pain in the butt. Gmail works fine. Just
> cant seem to get yahoo configured with imap.

Dunno... I don't have any yahoo account currently, I can't say.

> Anywho...
> I am not sure what you are asking..exactly. You want me to upload a couple large files some place for you to download and test? I would
> assume.. if that is what you are asking.. any files should work yah? The files I work with are 140GB in size.. so I would need a month or so
> to upload two of those.

No, reasonable sized, LOL.
A dozen or two megabytes would be enough, I think. Even a hundred megs.

If it is output of a camera, just shoot a wall for minute or whatever 
time is needed to create a sample.

As to the site for sharing, if you have a gmail account, you get some 
space in "drive" for a share to named people. There maybe other methods.

> I am also not entirely sure about testing the copy process.  I did once try to use the Windows copy command and that too took a long while. 
> Which if that is the case, when copying two files together (using the + option) and I am doing so on an SSD.. it strikes me as a possible
> Windows OS Filesystem issue. My main SSD is NVMe.. write speed of 1500MB/s, so no way should it take very long to copy 300GB.. a few minutes
> tops.. not the hours and hours it currently seems to take.

Well, that's the key issue. Such a copy process should be very fast.

It could be that something is trying to index the new file before it is 
finished: as it grows, it tries again to index it. I have seen this 
hapening in Linux once or twice, I had to kill that indexing process.

> Even when I copy over USB 3.0 or 3.1, at 5Gb/s, the bottleneck should be the recording medium. Given that the external USB 3.1 devices are
> typically using SATA3 interface internally, and with an m.2 ssd in it, it should still handle 250MB/s or more at full SATA3 speeds..


> basically the max speed of the m.2 ssd write speed. Naturally this could vary, but my m.2 claims 450MB/s write, 550MB/s read, and SATA 3 at
> 6gp/s with parity.. is still approaching 600 MB/s theoretical speeds. So even if I allow for 1/2 that for any number of issues.. I would hope
> I could see 250MB/s or more throughput. Which on 2 x 150GB files, should still yield a copy speed of about 5 minutes or so, tops.. if not
> less.

The limit is the "continuous write speed" of the disk, not the bus.

> So..that has me questioning.. what in the OS maybe I need to change so that copies are much faster.

I imagine that some other program is interfeering.

- -- 
        Carlos E. R.
        (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)
Version: GnuPG v2


More information about the ffmpeg-user mailing list