|
|
| vit123 |
| Posted: Jul 5 2010, 05:13 PM |
 |
|
Newbie
Group: Members
Posts: 3
Member No.: 27941
Joined: 5-July 10
|
Kind Friends and VirtualDub Developers,
I wish explain you my recent (bad) discovery about "Appending" function in VD:
First, using my usual & old version of VD, to join 2x 730MB AVIs (XviD+AC3) (each other totally compatible) I began noticing that the resulting AVI happened to get random bugs in the codec (occasionally visible when playing video); then I checked the original AVIs (fortunately not yet deleted) and they were perfect.
So I tried to repeat the appending procedure (just the same, usual, procedure) on a different system, using the same 2x AVI sources files and I "direct streamed" a new resulting AVI: then I used an HexEditor to compare byte-to-byte this new AVI with the previous, and... they showed to to have VARIOUS 32 bytes blocks DIFFERENT, not inside the AVI header, but deep inside the AVI codec data! (AVI Headers were identical)
At this point, I downloaded the newest VirtualDub 1.9.9 b32817, I repeated the tests, and..
Two IDENTICAL Appending operations ALWAYS LEAD TO DIFFERENT RESULTS!
Precisely, the resulting AVI files will have VARIOUS DIFFERENT 32-bytes-blocks inside the codec stream, likely bringing to Video Bugs on the resulting Video.
Just use any Hash Calculator or HexEditor to prove this.
Now my simple Question: Using just the same (newest) VD, just the same AVI sources, just the same procedure, why doing the SAME N appending procedures will lead to N different AVIs?
I guessed VD would record any timestamp into the resulting AVI (honestly strange!), but if so, shouldn't it stay into the AVI hearder leaving the codec stream untouched?
PLEASE, let me know what's going on, Thanks a lot,
Vittorio (Italy) |
|
| vit123 |
| Posted: Jul 5 2010, 06:30 PM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 27941
Joined: 5-July 10
|
I'm very sorry: I need to suspend this thread since -after further analysis- I have founded suspicion such bug results from my hardware (serious) bug.
I did intensive memtest86+ testing with no evidence, HDD seems no responsible too, still looking for the guilty of such problem: may be simply 1GB prone to overflow when appending 2x 730MB AVIs?
So unbelievable my AthlonXP 2600+ or cache or what? may have got crazy. |
|
| vit123 |
| Posted: Jul 5 2010, 08:50 PM |
|
|
Newbie
Group: Members
Posts: 3
Member No.: 27941
Joined: 5-July 10
|
Thread solved!
memtest86+ fully passed BUT 1 memory bank (PC2700,512MB) showed silently faulty!
Pulling it out of the MB, the bug in VD Appending procedure completely solved!
Happy to have clear ideas now: NEVER BUY V-DATA RAMs.. |
|
| rjisinspired |
| Posted: Jul 6 2010, 06:06 AM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
I don't understand how ram would cause anything extraordinary to occur in processed video? My thought would be that other programs or even system-wide functions would be affected by the same if it was an issue of ram. |
|
| phaeron |
| Posted: Jul 7 2010, 05:45 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Glad you figured it out.
| QUOTE |
I don't understand how ram would cause anything extraordinary to occur in processed video? My thought would be that other programs or even system-wide functions would be affected by the same if it was an issue of ram.
|
No, you can get very subtle corruption from bad RAM, particularly since it can be pattern sensitive. I had a bad stick of memory in my old laptop for six months and didn't realize that the rare crashes I was getting was from the RAM rather than Windows sucking. I didn't figure it out until one of the files I hadn't modified for a long time showed reproducible corruption until I flushed the disk cache. The disk cache exacerbates the problem because it's not unusual nowadays to have a lot more RAM than you need most of the time and that allows the OS to devote a sector of memory to the same data for a long time. The problem is serious enough that Windows Vista and up now ship with a memory tester.
10^-9 error rate seems pretty good, until you realize that machines now commonly have 24*10^9 bits of memory.
Another source of subtle corruption, btw, is the network cards.
|
|
| rjisinspired |
| Posted: Jul 7 2010, 11:19 AM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Interesting. Thanks for detailing this.
Would something like memtest or other program be able to find out if anything is presently wrong with ram? |
|
| phaeron |
| Posted: Jul 8 2010, 03:23 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
It can, but sometimes it can be tough to detect. I've heard of cases where most of Memtest's tests didn't detect anything wrong and the fault wasn't detected until the bit fade test was run... which found a bit that only decayed after about 45 minutes.
|
|
