[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
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the ffmpeg-user