choagland
commented
5 years ago Should we add an integration test for this type of source file? (I don't know if that would be in this repo or in the luma repo)
Closed KMojek closed 5 years ago
choagland
commented
5 years ago Should we add an integration test for this type of source file? (I don't know if that would be in this repo or in the luma repo)
KMojek
commented
5 years ago @choagland I added two integration tests but TeamCity isn't set up to run unit tests for this repo. Probably the best thing would be to move those to Luma.
KMojek
commented
5 years ago Alright, I moved the "type one AVI" test to DecoderLibTests... but apparently those tests are currently disabled because the build servers won't have TSCC or TSC2 installed. So we should probably either
qunliu
commented
5 years ago It looks good to me 👍 (I noticed Tom had some comments, so probably you still want to get thumbs from him?)
KMojek
commented
5 years ago I talked to Tom offline on this and he is 👍 with the current state; merging.
Addresses https://github.com/TechSmith/CamtasiaWin/issues/10688 There was a second case that came in to tech support during the IP sprint that turned out to be the same bug. I tested this change against both of those camrecs and also tested that the change does not seem to break anything with newer camrecs that have AVI 2.0 streams.
It turns out that older camrecs actually used AVI 1.0 streams (I think this may have changed with CS 6 but I'm not 100% sure). It probably doesn't happen a lot but so far there have been at least two instances reported to tech support where a user was working with a really-old (I think both appeared to have been recorded in 2007) camrec and our current decoding code wouldn't know how to handle it, resulting in a crash. This change allows those AVI 1.0 files to be read; there's probably no reason we would want to write anything other than 2.0 format, so changes are just on the reading side.