Saving files

[Anema]

Hello,

I have been using avidemux for a while now, and have not encountered many problems, but recently, some of the videos which I am saving are stopping at -- what seemed to be -- random points. This resulted in videos which, in some cases were originally 7 mins long, saving as 4 mins long, just as an example. It still says the video has saved, as usual, but it just outputs a video in which the last 3 minutes, for example, is cut off.

After looking at it a bit, I realised that they would stop saving when there was a stoppage in the frames in the original video. What I mean is, if there was lag in the video -- which is a game recording -- then the screen may have stopped for 1 second, and this results in my videos not saving past that point. It is as if the b-point is set at the stopping of the frames.

I have tried a mixture of different video output settings, output formats and some audio output settings. To list them here would be spammy, but, the main ones were: Mpeg4 ASP (xvid4), Mpeg4 ACV (x264) video outputs, and AVI, MP4 and mkv muxer output formats. I mainly keep audio as copy, unless it says to me otherwise.

I am not sure which information to include; I am a bit uneducated in this stuff, however, I will give some information which I think may be useful:

I am using avidemux 2.7.0, 64-bit.
The files I have were recorded in fraps, and are .avi files.
I am using a windows 7, 64-bit operating system.
And this is what my program set-up currently looks like:
https://i.imgur.com/60Zdb3P.jpg

This particular video is 8:42 minutes long, however, it stops saving at 2:33 minutes because of a slight screen freeze for about 1 second in the game footage.

I will provide any more information that I must, which I assume I definitely will, provided that I know how.

Thanks very much.

[eumagga0x2a]

Please provide a sample video (you might use a service like WeTransfer for that).

BTW, avoid using AVI as output container whenever possible

[Anema]

BTW, avoid using AVI as output container whenever possible

Hey, thanks for the advice.

I have uploaded the file to wetransfer, it is just processing. It may take about 1 hrs 40 mins though unfortunately.
It is 8.5 gb because fraps.

I can post it here when done.

[Anema]

Hello

Thanks for waiting.

These are the links to the files which I have uploaded:

The original game, fraps, file: https://we.tl/V1OJsgib3B.

And I have uploaded some cut footage from different fragments of the footage: https://we.tl/pmJEkKJRaZ

The attempt at saving the video (full): "SwgClient_r 2017-10-02 03-43-26-10" (00:02:33).
You will notice that it stops at about 2:33 minutes.
The attempt at resuming a save of the file after 2:33 frozen frames: "SwgClient_r 2017-10-02 03-43-26-10a" (00:00:09).

Issues:
It, the game file footage, freezes for approximately 1 second or less, at 2:33 minutes.
It also freezes at 2:43, which is the 9 (2:33 - 2:43) second clip included in one of the downloads, again.

You can see both of these in the original video. I think it freezes again at around 2:47.

In the game, you can see, on the left hand side, the networking status. This tells you the fps and bandwidth etc.

Whenever the freezes happen, the fps jumps to 2-3 fps.

Thank you very much.

I will apply anything else which is needed.

[Jan Gruuthuse]

I'm not downloading 9 GB, that's to much.
What you can try to do: look up your freezes.

- mark the section before the 1st freeze: [ B]
- save as part01
- press [Del], the saved section is now out of your video
- go pass the freeze (slider), mark [ B]
- press  [Del], the freeze is now out of your video

Goto next freeze, repeat above action, don't forget to increment part## by 1 (part02,03,04,..)

where you freezes are there is faulty/no video content, your computer hit a hardware bottleneck, the recording has errors.

What you can try is not recording in raw, record h264, if you CPU has enough calculation power surplus, you probably get away with this. If the bottleneck is hard disk i/o related.

[eumagga0x2a]

Thank you, I'll have a look later.

[eumagga0x2a]

The playback and saving stops at 00:02:33.350 because the internal FFmpeg in Avidemux fails to decode 24 frames (probably containing garbage) in a row at this point of video. Avidemux currently gives up after 20 attempts.

[Anema]

Interesting

A lot of useful advice here for me.

Is Jan's solution the current resolution for this then?

When I record a lot, I do find that my cpu gets more intensive. :I
This is, until I shrink the fraps files.
Perhaps I will try another recorder and see how that works with avidemux.

[Jan Gruuthuse]

>8>8
Is Jan's solution the current resolution for this then?

When I record a lot, I do find that my cpu gets more intensive. :I

Not if your CPU is maxed out. If the game pulls 100% CPU at certain moments in the game, there is nothing left to do anything else. Cores/threads could also come into play? Perhaps testing, recording could give you pointers. Play cpu demanding game, and see what recording does. I believe there is some game benchmarking software around, running these and recording could possible give a clue.

I'm not into gaming, what is the used CPU?

[AQUAR]

Seems probable that your PC is running out of steam somewhere during the processing.

Just for tinkering:
You might try to assign a high processing priority to the capture program and a low processing priority to the game.
Set affinity to CPU cores spread between the programs involved in your work flow.
Maybe capture to a HDD that isn't being polled by the game.
Reduce the write intensity to the HDD by using a lossless codec like huffyuf to capture video (rather than raw).




 

[eumagga0x2a]

Perhaps I will try another recorder and see how that works with avidemux.

Or you just build your own Avidemux build with the number of loops at avidemux/common/ADM_editor/src/ADM_edRenderInternal.cpp:143 bumped to e.g. 30. You will need Linux for that though.

[eumagga0x2a]

Fraps records at 60fps, but most frames are empty (if you look into the Avidemux log, you will see a ton of "[lavc] Probably pseudo black frame..." messages). 20 attempts at 60fps = 1/3 s maximum gap, 30 attempts = 1/2 s. If you really have spots where the video stops for a whole second, you'd have to bump the number of loops beyond 60. This is not really scalable.

[eumagga0x2a]

Mean has just fixed the issue as a special case for fraps codec in AVI by skipping empty frames: [avi/demux] Remove fraps empty frames (hack). Try the latest nightly (I haven't verified that it includes the fix, but it is very likely; if not, the following nightly will do).