As mentioned two posts earlier, in version 1.9.4 of
Video Enhancer we added YV12 mode of super
resolution engine. Most video codecs can decode video to several different
uncompressed formats: RGB24, RGB32, YV12, UYVY, YUY2 etc. They differ in
colorspace (red-green-blue or luminosity-color tone1-color tone2)
and data layout. Versions up to 1.9.3 just asked the decoder to provide data
in RGB32 and relied on DirectShow (part of DirectX) and system components to
convert video to RGB32 in case the decoder cannot do it itself. When version
1.9.4 came out it behave differently. It asked the decoder to provide one of
YV12, YUY2, RGB24 and RGB32 formats. If YV12 was given and super resolution
feature was used (either alone or in the beginning of filters sequence)
then YV12 mode of SR was used and then if some VirtualDub filters were
present in the queue, VE relied again on system converters to transform video
from YV12 to RGB32 (in which VD filters work). The same happened when
"Always use RGB32" option was turned on: decoder provided video in one of
abovementioned formats and then a system converter was used.
However it turns out there were
two problems:
- By default there is no system filter for YV12-RGB conversion, so DirectShow
searches for a codec for this conversion. Usually it finds one of old
Video-for-Windows codecs and inserts it in AVI Decompressor wrapper but
some users didn't have a matching codec and VE failed to process a file.
I still don't know which codec exactly was used,
but it had problem number two:
- Conversion from YV12 to RGB was weird, introducing a checkerboard pattern
which was very bad for super resolution. When looking at result of such
conversion one may not notice the problem:
But if we upsize the video it's easy to see the pattern:
So we had to change how VE works with YV12 video and version 1.9.5 was born.
Now it asks the decoder for any of YV12, YUY2, UYVY, RGB24 and RGB32 formats
and if it's YV12 then SR works in fast YV12 mode but if it's anything else
then our own filter converts video to RGB32. The same filter is used for
conversion if after YV12 SR there is some VD filter. No more checkerboard
and no more problems with lack of YV12 codec!
Video quality was the
primary objective for this conversion filter, so it uses proper interpolation
for color tone components (remember that in YV12 color tone resolution is
twice lower in both width and height than in RGB, and in YUY2 and UYVY it's
twice lower in width than RGB but same in height). Bad converter with no
interpolcaion can easily create little blocking artifacts. Here's an example:
Old converter (some codec wrapped in AVI Decompressor):
The recently released version of Video Enhancer
can now speak many languages. The default one is English and translations
to other languages are provided in text files with .lng extension.
User can select a language in Options dialog of VE.
It's very easy to create and edit a translation, just open .lng file from
Video Enhancer folder in Notepad:
To create a new translation just copy an existing one to a file with
different name but same .lng extension and replace phrases to the right
of '=' sign with phrases of desired language.
Special offer
If you're a native speaker of Japanese, Chinese, Korean or other language
for which there is no translation yet, you can
get Video Enhancer license for free
by spending an hour of your time. Just create one of the following:
Video Enhancer translation (.lng file for your language)
OR translation of VE main page text to your
language.
Before starting please email us and introduce yourself. Our address:
It's been a while since last released version of
Video Enhancer.
We've accumulated a lot of feature requests from our users and also
came up with our own ideas, so it took quite a lot of time to implement
it all. Now version 1.9.4 is finally out and here's the list changes
worth mentioning:
YV12 mode for super resolution. All previous versions worked in RGB32
colorspace where each pixel is represented with three numbers: reg, green
and blue. However many modern video codecs work with video in YUV colorspace
where luminosity (lightness) and chrominance (color tone) are stored separately.
YV12 is one of YUV modes. In YV12 chrominance data has twice lower resolution
and for each 4 (2x2) pixels there are 4 distinct luminance values but just
single color tone value (made of 2 bytes), so 6 bytes encode 4 pixels, i.e.
12 bits per pixel, hence the name. Applying super resolution to YV12 video
means much less work to do. Also, RGB super resolution internally calculated
approximate luminance for all pixels - it was used for motion search. In YV12
we already have this data, so that step is just eliminated. Now when VE sees
that source video can be decoded to YV12 and super resolution is the first
(or the only) filter in the sequence, it then applies YV12 variant of SR
which works almost twice faster than RGB version. However VirtualDub filters
work in RGB32, so if SR is applied after some VD filter, RGB variant of SR is
used. In Options window you can disable this behavior and force using RGB in
all situations.
Scene change detection (less artifacts), mentioned in earlier blog post.
Higher overall SR quality and speed, thanks to new in-frame upsizing
method.
More precise control on SR quality/speed trade-off (4 modes and a slider
to choose between quality and speed).
Unicode, multilanguage support, easy to add translations (just add a text
file).
Can work with lower than normal priority - doesn't slow down other
applications even with 100% CPU load.
Fixed conflict with nVidia drivers that caused problems in Vista and
Windows 7 when Aero was turned on (only on nVidia cards).
Now you can easily save and load projects (sequences of filters with all
their settings). Just right click the filters box in Advanced mode.
Some minor changes (like drag'n'dropping files to main window) and
bugfixes (e.g. placing output files in same folder in batch mode).
Better Win7 compatibility: doesn't try to write to Program Files, uses
proper directories instead for storing its data (like list of filters).
We're very close to releasing the next version of
Video Enhancer. Today we added a scene change
detection algorithm into RGB version of super resolution engine. This feature
solves an annoying problem of all previous versions of VE: when a scene changes
in the video, first frames of the new scene contain some noise resulted from
SR fusing current image with previous hi-def frame. Now VE detects a change
and starts processing the scene from scratch, as if it was another video.
Basically this means that first frame of new scene is upsized by interpolation
and later frames are processed with SR.
Here's an example. This is a first frame of a scene:
VE 1.9.3, no scenes detection
VE 1.9.4, scenes detection on
In the left picture you can see the noise near a logo in upper-left corner
as well as around people's shoulders and heads.
In the right picture you can see this noise is gone.
We regularly receive questions how to build the C++ source code generated by
GraphEditPlus. It generates some code, but in
order to turn it into an executable one needs to create and properly set up
a Visual Studio project.
Here's a short tutorial on how to start working with DirectShow in C++ using
Microsoft Visual Studio 2005. It's also actual for VS2008 and probably VS2010.
To work with DirectShow first of all you need DirectShow headers and libs.
Currently they are included in Windows SDK which can be downloaded from
Microsoft website. If you don't have it installed yet, go install it now and
then come back.
By default it's being installed into
C:\Program Files\Microsoft SDKs\Windows\v7.0. If you install it
to some other place, make appropriate changes to the paths below.
Now, run Visual Studio and create a C++ project.
In this tutorial I'll pick a console application, for simplicity.
Give it a name and choose a path:
Although Visual Studio 6 was made in previous century it is still widely used
by C++ developers around the world. Probably because of good support of MFC
(which was screwed in later versions) or probably because later versions
weren't much better as IDE for writing C++, or because they introduced
unwanted difficulties with runtime libraries. Whatever the real reason for using
now 12-years old IDE is, we still receive questions on how to use code
generated by GraphEditPlus in VS6.
To work with DirectShow first of all you need DirectShow headers and libs.
Currently they are included in Windows SDK. A few years ago they were part of
DirectX SDK. When we're working with DirectShow in VS6 we still use the old
DirectX 9 SDK, which we have installed in C:\DXSDK folder. If you have the
headers and libs installed into other place, change your paths appropriately.
So, let's create a simplest DirectShow app. Make a new project, let it be
a Win32 Console Application. Give it a name and choose a path:
Found a nice clip on youtube, looks like whole Hollywood was making a commercial for
Video Enhancer :)
Of course, what we see in these movies is usually very unrealistic and cannot really be done,
however some degree of enhancing video resolution and quality is quite possible, as many our
existing users know.
It's been a while since we released the last version of Video Enhancer.
A lot of things happened during this time, we created new product, developed
further the Super Resolution technology, had some business-to-business contracts
which also took some time. After all this some time ago we were ready to incorporate
the new SR mode into Video Enhancer and release a new version. However there was one thing
that stopped us: several weird reports on Video Enhancer hanging in the middle of work,
sometimes after hours of processing. Later a similar problem was reported by a user
of another our product, ScreenPressor. These two products share one microlibrary
which takes care of parallelization - distributing work onto different cores and CPUs.
It became obvious that there is some subtle problem in this library, so we started
to investigate it. The problem was hard to reproduce, since it happens very rarely.
Moreover, it was a kind of a heisenbug - a bug which disappears when you try to find it,
because inserting some debugging output code required inserting synchronization between
threads and that made the bug disappear. So usual means of debugging didn't help,
but fortunately close inspection of the code and examination of functions used there
eventually revealed the problem. It turns out that we used some WinAPI synchronization
functions which are not very reliable. In some situations, that happen very rarely,
Windows kernel can borrow application's working threads and during this time
borrowed thread which was waiting for an event doesn't notice that the event it was
waiting for happens. For this reason in some very rare cases the application was signaling
its worker threads that there is some work for them to do, but not all of the threads
woke up to do the work, however the main app waited until all of them report that the work is
done, which never happened in this case because one of the threads didn't even start working.
This is a classical deadlock situation and it caused the program to stop unexpectedly
in the middle of processing.
Now we've rewritten the parallelization microlibrary so the above problem may never
rise again. Also, since the set of used synchronization primitives has changed, we hope
that the problem with nVidia cards in Vista and Win7 will probably disappear too,
because we know it was triggered by some synchronization stuff. With these good news we
can finally prepare new version of Video Enhancer for release.
I think it might come out in a few days, there are still some improvements to be made.
This site has two different domain names: thedeemon.com and infognition.com.
Both names - Dee Mon and Infognition - appear on different pages and products here,
so there may be some confusion which I hope to eliminate in this post.
"Dee Mon" is a personal nickname which I use in Internet circa 1997. It has nothing
to do with daemons, it's just originally spelled form of name Dmitry. When I started to
create software and distribute it via this site I just used this name as a trademark.
This tactic is usually called "doing business as" when someone uses a made-up name without
creating a company. In 2008 I opened a real company, and the company needed a good
name without bad associations like daemons. That's how Infognition was born.
Unlike Dee Mon, Infognition Co. Ltd. is a real company with a stamp, bank account, TaxID and
even some employees. Now when domain infognition.com is more than one year old
we're going to leave thedeemon.com in the past and stick to the new name everywhere.
Hi everyone!
My name is Dmitry Popov, I'm the founder of this company
Infognition Co. Ltd. and the main developer of Video Enhancer, GraphEditPlus,
ScreenPressor and other products presented here (except for the VirtualDub filters).
I've decided to start this blog to bring some personal touch to the site and to
cover some topics related to multimedia software development as well as some video processing
tips and tricks that are too small for an article or tutorial.
The blog engine is not complete yet, but all usual stuff like comments and RSS will
be available soon.
RSS
