Large files over a home network

[Tim]

I tried encoding a job using a 7GB file on a network location with the output destined for a local location. I expected it to be a 2-hour job and apparently it almost was. However, at about 2 hours 20 minutes the status progress arrived at 100.5% and stayed there another 2-1/2 hours with the CPU at full gas until I aborted the operation. I don't know why it got hung up, but I wondered if it had anything to do with the source file being over the network.

I have a vast collection of video files located in numerous places on my home network. I'm curious about the feasibility of re-encoding some of them without having to move them. Can FFB use source files from a read-only location as long as the destination location is read-write? Are all temporary files created by an encode stored on the machine FFB is operating from?

[Tim]

I started another encode of a 7.4GB source file from a local folder and have experienced the same symptoms. It got to 100.5% in just over 2 hours and it has stayed at 100.5% for the next 2-1/2 hours with the CPU at about 80%. I'm beginning to wonder if FFB is not up to the task of handling larger files like this with older equipment (Xeon W3680 @ 3.33 GHz, 24 GB Ram) that does just fine with the same file using ffmpeg from the command line with the same parameters.

Any thoughts?

[Tim]

These encodes had something special about them. They were sports videos that I was recoding to h.265 and to play back at half speed (-vf "setpts=2PTS" -af "atempo=0.5") so that MX Player could slow it down to .12x speed.

I wonder if the progress bar is related to parsing the source file and subsequently the majority of the time is then devoted to reallocating all the timestamps and stretching out the audio.

[Abel]

There are no known issues with big files across networks. It's just given the amount of parameter combinations available, sometimes progress is not displayed accurately. H265 encoding is slow, and applying filters like slowing down, makes it even slower. I would try with just one file and then check log file, enabling verbose logs.

Edit: I've confirmed that using slow down causes progress to reach 100% early, but encoding continues in the background until the end and output is fine.

[Tim]

Thanks Abel. That's exactly what I'm experiencing. It's simply a long encode when converting to h.265 with a change in speed, and I was misleading myself by not understanding what the progress bar was actually measuring. Now that I give several hours without paying attention I see these encodes DO complete - even over the network - eventually. I do believe that my

for %%i in (*.MTS *_.mp4) do ffmpeg -i "%%i" -c:v libx265 -crf 25 -preset medium -x265-params "keyint=60:min-keyint=30" -b:a 64k -vf "setpts=2*PTS" -af "atempo=0.5" "%%~ni_x265q25m64k60h.mp4"

command batch jobs were taking just as long.

You've made a fantastic program here and I can't believe it took me so long to come across it.

[Abel]

Thanks, good to know. I've generated a beta version that should display more accurate progress info when using slow down filter (atempo). You can test it replacing your current executable with this one.

[Tim]

Wow-Thanks! I'll test this out as soon as my latest encode finishes in the next couple hours.

[Tim]

Since yesterday I've run this beta version on 3 different computers with numerous files, and most of the time the Total Progress and Status bars seemed to reflect actual progress very well with high accuracy.

With one video I did experience an exception, however. This particular video was a short 1 minute clip with a 26 Mbps bitrate and 59.94 fps frame rate. I ran the above encode on it using both FFB and ffmpeg from a command line. In each case it took 7 minutes to encode, but tracking the progress was considerably different.

For this encode, FFB's Total Progress indicator jumped forward and back continuously while the status bar increased steadily but reached 100% with several minutes remaining when the Total Progress Time remaining indicated there was about an hour remaining.

Running ffmpeg from the command line on the other hand, there is no "progress bar", and the only progress indications are the frame number of the source video that's being processed and the duration of video that's been created so far ("time=xx:xx:xx.xx"). However, these numbers are quite useful as an indication for conveying the progress of the job. They progress steadily and the job always seems to complete right after all source frames have been processed and the time code reaches the total duration of the new file. I'm pretty sure this is isolated to using constant rate factor (one-pass encode).

For my half-speed h.265 encodes with a constant rate factor, I found ffmpeg from the command line to be the most accurate on a consistent basis, but FFB is now doing a great job of conveying that progress more accurately.

Thank you!