|
|
| Genasor |
 Posted: Oct 1 2002, 08:08 PM |
 |
|
Unregistered
|
Hi,
I think I found a bug in VirtualDub 1.4.10.
I've tried to decimate by 2 a video clip (recorded at 25fps but appearing to be a 12fps). Although it's said there shoudn't be a/v sync problem, there was! I tried to resync manually, and then I noticed a quite large shunk of the clip had been removed...
So I used Thomas Hargrove AddFrameNumber filter on the original clip. Here is the observation on the decimated clip:
frames kept.............frames discaded
0000-0149...............0150-0299
0300-0449...............0450-0599
0600-0749...............0750-0899
0900-1035...............1036-1065
1066-1106...............1107-1148
1149-1176...............1177-1207
1208-1231...............1232-1257
1258-1270...............1271-1284
1285-1295...............1296-1309
1310-1340...............1341-1372
1373-1490...............1491-1611
1612-1663...............1664-1717
1718-...
For a start, I thought decimate by 2 was to keep one frame and discard the next one. In this case, it keeps 'a lot of frame' and discard about the same quantity, so the clip length actually is halved but with no regularity. The only sequence I could think of for VirtualDub to tap in was the key-frame sequence.
Here is the original clip key-frame sequence:
0,300,600,900,1009,1066,1149,1208,1258,1285,1310,1373,1612,1718,...
There it is! VirtualDub keeps the first half of frames between 2 key frames and discard the second half.
This doesn't seem a normal behaviour to me... |
|
| phaeron |
| Posted: Oct 2 2002, 03:17 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
The problem is that you are attempting to do a decimate in direct stream copy mode with a stream that is mostly delta frames. VirtualDub allows you to do this operation because it is useful with streams that are 99.99999% keyframes -- for example, a one-hour Huffyuv stream with one dropped frame. The problem is that if you have a frame dependency like this, by having one key frame and seven delta frames:
A > B > C > D > E > F > G > H
Then you can't decimate by two and include only A, C, E, and H. Instead, VirtualDub includes A, B, C, and D. It will then catch up on the next key frame.
In order to do the decimation you need, you have to recompress, and that means full processing mode. There's no way around it -- pairs of frames need to be combined to produce a decodable stream, and the only way to do that is to reencode the whole thing. In full processing mode there is no shifting of frames as VirtualDub controls which frames are encoded.
|
|
|
