|
|
| levicki |
| Posted: May 9 2012, 09:52 AM |
 |
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
I do not understand why output video file is locked for reading while it is being written?
From my point of view, this is not necessary and it is harmfull because you cannot preview the video using an external player such as VLC or MPC-HC.
Reasons why you might want to do that is because you are using Remote Desktop and you turned built-in preview off (preview through Remote Desktop is slow, it faster to copy the partial file and play on local computer) or you might want to see if there are any problems with aspect ratio, audio interleaving, audio sync, etc.
By the way, all download managers, p2p applications, and even browsers do not keep read lock on the file being downloaded and written so you can preview them before download is complete.
I suggest removing the reading lock in a future version of VirtualDub. |
|
| phaeron |
| Posted: May 12 2012, 05:20 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
There are a couple of reasons for this behavior.
First, note that adding the read sharing flag on VirtualDub's side doesn't do anything if the write sharing flag isn't set on the reader, which a lot of programs do require. The programs you have listed, though, do usually allow for write sharing.
The second problem is nastier. Some programs which scan for changes in directories have a bad habit of reading the entire file, leaving the file opened, or hanging if they read an AVI file that is partially written. Windows XP Explorer's shell media extension is particularly prone to this. For this reason, VirtualDub needs to keep the file locked in order to prevent these programs from barfing on the file.
There are two approaches I could see working here, both of which I would only consider as optional. One would just be to make write sharing an option. The other is to do what Firefox does, which is to reserve the original filename with a 0-byte locked file and then write the new file as a .part file, swapping that into place at the end. |
|
| levicki |
 Posted: May 14 2012, 08:45 AM |
|
|
Advanced Member
Group: Members
Posts: 167
Member No.: 22605
Joined: 13-December 07
|
| QUOTE (phaeron @ May 12 2012, 06:20 PM) | There are a couple of reasons for this behavior.
First, note that adding the read sharing flag on VirtualDub's side doesn't do anything if the write sharing flag isn't set on the reader, which a lot of programs do require. The programs you have listed, though, do usually allow for write sharing.
The second problem is nastier. Some programs which scan for changes in directories have a bad habit of reading the entire file, leaving the file opened, or hanging if they read an AVI file that is partially written. Windows XP Explorer's shell media extension is particularly prone to this. For this reason, VirtualDub needs to keep the file locked in order to prevent these programs from barfing on the file.
There are two approaches I could see working here, both of which I would only consider as optional. One would just be to make write sharing an option. The other is to do what Firefox does, which is to reserve the original filename with a 0-byte locked file and then write the new file as a .part file, swapping that into place at the end. |
I am aware of those problems -- it is just that I am of the opinion that people should not modify their own working programs to work around other people's broken programs. If they crash or hang on an incomplete AVI file so be it. People will stop using them and find other programs that work.
One other program I can mention that doesn't lock the output file is x264.exe.
As far as I am concerned it could be either an option to not lock the files (like x264.exe) or "Firefox" approach that you suggested.
Whatever you pick to implement I hope it comes in next release ;-)
|
|
| phaeron |
| Posted: May 19 2012, 10:18 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE | | I am aware of those problems -- it is just that I am of the opinion that people should not modify their own working programs to work around other people's broken programs. If they crash or hang on an incomplete AVI file so be it. People will stop using them and find other programs that work. |
This line of thinking doesn't work in practice -- if your program is what triggers the problem it is you that will be blamed. This especially doesn't work if the program that is hanging is Windows Explorer.
|
|
