Avidemux exits while seeking

[thany]

Using r9050 nightly, while seeking by just holding down a navigation key, Avidemux may sometimes exit. Just like that. *poof* and it's gone. No crash, no "stopped working" message, just exit and gone. Upon restarting Avidemux, there's also no "it has crashed" question that usually comes up after a proper crash.

Strangely I only ever had this happen on my virtual XP box that I use via RDP.
So this might be a bug that only happens on XP, or one that only happens in the 32-bits program, or one that only happens over an RDP connection, or some other odd combination.

RDP being RDP, the connection is still pretty alright, and it usually keeps up fairly okay-ish* with the obviously ever-updating avidemux-screen when seeking. It could be that avidemux chokes on it and can't even produce a proper crash, or it could be that Windows decides to kill it. I honestly don't know. I only know I haven't seen this behaviour in other programs - even ones that impose a high graphics demand on the RDP part.

*) I know this doesn't say anything, but let's say video still looks like video and not quite slideshow.

Any ideas?

[zakk]

your forwarding faster than your CPU can handle.

[AQUAR]

I am with zakk.

This issue has come up a few times.
Seems some users just have a hard time accepting the limitations of their computer hardware.

I would look at the video compression complexity and the consequential memory buffering.
This maybe more substantial for video editors (as opposed to video players).

[zakk]

Seems some users just have a hard time accepting the limitations of their computer hardware.

On the other hand it's the only program I know which crashes instead of slowing down.

[AQUAR]

@ zakk

Well, I suggest you use more programs to get that kind of experience!
Particularly, video editing programs, as many will lock up or crash with resource bottlenecks.
So its not an avidemux peculiarity.

In any case, the argument is mute, recoding with AVC requires a decent PC.

[mean]

Could be a bug in with a specific file / file type
Does it happen with all files ?

[Jan Gruuthuse]

Occasionally this happens with MPEG transport stream (dvb-s & dvb-s2). Upon loading the 1st time, when avidemux exits .idx or .idx2 are not created/written. Restarting avidemux and loading the video again works and video is indexed fine.

[thany]

your forwarding faster than your CPU can handle.

Absolutely not. I can go *back* frame by frame, which takes up a huge amount of CPU, and it's just going as fast as the cpu can handle. Avidemux does not exit because of it. This exiting problem seems more like a race condition of sorts to me, since it only happens while seeking, and at a random point while seeking. If seeking forward, it never goes faster than realtime, and my CPU is more than capable of handling that.

This issue has come up a few times.
Seems some users just have a hard time accepting the limitations of their computer hardware.

The difference is that I *know* the limitations of my hardware. I know what it should be capable of, and this is one of those things. You might be right though, it just doesn't count for me

Particularly, video editing programs, as many will lock up or crash with resource bottlenecks.

Resources other than CPU is not the problem either. Again, I know what my hardware can an cannot do.

Could be a bug in with a specific file / file type
Does it happen with all files ?

I don't know, to be fair. I've seen it happen with all different kinds of files, so it's not specific to a codec or container. There are files that are just downright corrupt, but that's not the case I'm talking about here. The files I've got are perfectly valid, and WILL work fine when I just restart avidemux and try the same seekings again. That is, until this bug surfaces again of course, but it would be at another spot.

Occasionally this happens with MPEG transport stream (dvb-s & dvb-s2). Upon loading the 1st time, when avidemux exits .idx or .idx2 are not created/written

I never work with those kinds of files, and as stated, it happens in all sorts of different files.

The only thing I can come up with, is that I'm using Avidemux through an RDP connection. RDP needs to forward all drawing operations through a network connection, so it might slow a draw down enough for avidemux to choke on it. This has nothing to do with decoding or rendering - just drawing. Drawing is an operation that's normally virtually instantaneous, and having it delay like that MIGHT be a problem for a fairly graphical program. But Avidemux shouldn't poof itself away like, so not using RDP is not a solution (and for me, not even a workaround).

But that's all just speculation. It could be a thing that only surfaces on Windows XP.

If you guys insist that it's a performance problem, this is what I'm using:

VMware ESXi 5.1
CPU: Core i5 3470S (3 cores assigned) shared with two other VM's that are essentially doing nothing.
Memory: 3GB (physical memory - no swapping allowed on the hypervisor)
Harddisks:
- 12GB for Windows and programs and such - 5,4GB available.
- 500GB encrypted through TrueCrypt for movies & data
- Hypervisor has a LSI RAID-5 (that's true hardware-raid) with 3x750GB harddisks. It's pretty fast.
TrueCrypt itself can decrypt & encrypt about 1.8GB/s on the algorithm used.

[Jan Gruuthuse]

remote desktop is an issue: you transporting the video on the remote system. On top of that your transporting avidemux video window on the remote desktop, and scaling this to workstation desktop.
If this the only way to operate try to:
- decrease the color depth of your workstation desktop or the used color depth settings of the remote desktop program.
- reduce the used fps settings of the remote desktop program.
- work with a scaled down window of avidemux (keyboard number 3)

If this is still not workable: The combination of windows xp (EOL), remote desktop processing, the reduced amount of memory (3 GB) available, the hard disc encryption, moving this data (video and desktop) around the hard discs locally and remote is most likely the cause of this/these issues.

I have tried remote desktop to core I5 64-bit ubuntu from core I7 64-bit ubuntu both 16 GB ram on raid 0 sata 6 WD Black over 1 GB lan and found this editing solution hardly workable. I use now KVM switch between the 2 computers. Editing core i5, start encoding core i5. Switching core i7 editing, start encoding core i7, switching core i5 and so on.

[AQUAR]

According to thany, his PC environment and data work flow, has no resource bottlenecks or hardware limitations.
Therefore his immovable conclusion continues to be that this is purely an avidemux issue.
That last epic response was intended by thany to prove that his opinion is the only logical conclusion.
BUT, actually it does the exact opposite (see Jan's response!).

On top of that, there is the continued angling that avidemux needs much better error dialogs.
Dialogs that will pin point the exact cause of issues, like this one.

I have said it before: thany has an unrealistic expectation/perspective about avidemux and it seems also his own hardware/software implementations.

Executing avidemux on a REAL platform, using a modern PC and on a current OS does not result in a vapour exit.
Not even when seeking the most complex AVC material (Others and I have tested this many times).
But, it does happen on lesser PC's, with obsolete OS's and of course "thany's" setup.

IMHO there is no point continuing to discuss the issue in this manner any longer.

Instead:
I suggest that thany provides a decent video clip that crashes his system without fail.
If the developer mean is willing to look at it, AND
If the sample proves this issue is consistent and repeatable on decent PC's, THEN
Maybe the source code can be looked at for things like "code race" and maybe tweaked a bit (avoid or warn!).

For my money, thany just needs to fix the resource bottlenecks in his PC and go about enjoying avidemux.