FFMPEG does not match version required for: MKV

MrVideo

Active member
VRD 640c

Got the error listed in the title while trying to open MKV files. Not a problem with the previous version of VRD.

Will have to go back to the previous version, unless there is a quick cure.
 

Greg

New member
Same here. I did get a message that said to download free codecs for ffmpeg from VideoReDo, but that didn't help. 638 works fine
 

Dan203

Senior Developer
Staff member
We added a couple of new FFmpeg DLLs to this release which we weren't using before and it looks like there is a small bug in the version check code that's causing it to fail. DanR is out for the day, but he'll probably release a new beta with a fix for this tomorrow.

Dan
 

Greg

New member
Hi Mr Video

Ya, I got the message to install a file codec1.exe or something similar. In fact, it came up twice. It showed a url from videoredo. Maybe I didn't have these codecs and you do??

Greg
 

Dan203

Senior Developer
Staff member
Begs the question... how did this slip through regression testing? :D
Not sure. The version check is disabled in the debug build, which is why I missed it, but I'm not sure how it slipped through testing of the release build. My only guess is that since this only effects the FFmpeg reader, and not the audio decoder or muxer, the tester didn't try opening an MP4 or MKV file. :eek:

DanR will be releasing a new beta to fix this in the morning

Dan
 

MrVideo

Active member
But that is what regression testing is all about. If you saw the regression test plans at the company I used to work for, your head would spin. Obviously we never ran the whole mess all the time, but when it came to major release time, a lot of people spent a lot of hours doing testing.

In this case, I would expect a test procedure to be in place that is run when something changes and whatever is affected by that change gets tested. In this case, FFMPEG was changed so everything affected by that gets testes, i.e., reading in of all file types that use FFMPEG.

But that is just me :D
 

IRa

New member
But that is what regression testing is all about.
You are right that there was a hole in testing prosedure which they now noticed, but we must also remember that these versions are beta versions so I can accept that this forum is also important part of voluntary testing before releasing stable official version.
 

MrVideo

Active member
but we must also remember that these versions are beta versions so I can accept that this forum is also important part of voluntary testing before releasing stable official version.
I do not disagree with what you've written, but not being able to read in video files is not a beta tester operation. :D

Beta testing finds the really weird and off-the-wall issues. an operation/feature that maybe only one or two users may ever even use.
 

phd

Super Moderator
I do not disagree with what you've written, but not being able to read in video files is not a beta tester operation. :D

Beta testing finds the really weird and off-the-wall issues. an operation/feature that maybe only one or two users may ever even use.
Since you are curious, I tested a release (not a debug) version and the error did not pop up.

Part of what I tested in this Beta release is as follows:
2) Open all file types, .mpg, .ts, .mp4, .mkv, wtv., dvr-ms
3) Save all file types.
Depending on the release, the specific fix and change items are tested as well as general finctionality.
 

MrVideo

Active member
Since you are curious, I tested a release (not a debug) version and the error did not pop up.
Which doesn't make any sense, since it is known that the needed DLLs were missing from the release. They must have been on your system because of other reasons.

If that is the case, then the testing procedure is invalid. A valid test is on a machine that has never had VRD installed, so that if a file is missing, will be caught during the testing process. Since rebuilding machines from scratch is a royal pain, that is where VMs come in handy. You build a VM master for each OS and before you test a release, the current VM is deleted and the master VM copied over. Fresh install to test with.

Now, that said, even though I install VRD on top of previous releases, any missing new files I wouldn't have, hence the error we users had.
 

Dan203

Senior Developer
Staff member
This is really my fault. I made a change to the DLLs for something I'm working on that is not part of this release, but still effected which DLLs for this release. I didn't report the change in our tracking system because the feature I'm working on isn't ready yet. I didn't consider how the change would effect the rest of the FFmpeg code and without the entry in our tracking system Pat had no idea it could even be an issue. I'll try not to do this again going forward.

Dan
 

Anole

Moderator
Thanks, Dan.
We appreciate the transparency.

Most vendors would lie and cover up a simple error like this.
But, over time, it happens to all of us.

I once designed a plug-in card for a certain computer.
It was all debugged and ready to work, and without any changes to the first PCB layout.
I drove 50 miles to present the board to the customer.
At the last minute, we discovered we'd built the board with a component that was in the way of a molded rib in the cover.
In other: the lid wouldn't fit on! :)

So, it took another turn around on the PCB layout to make a board they could sell.
And another week delay.
We still laugh about it to this day ... ;)
 
Last edited:
Top Bottom