Quality issue wmv-encoding

[d_wei]

Hello,

I have a question about the quality of wmv-encoded content.

I have written an application with the Windows Media Encoder SDK to transcode mxf-files to wmv.

Here is some information about the material I use:
The format of the mxf-videostream is D10 Video IMX (interlaced mpeg2, I-frame-only) at 50 MBit/s.
Resoulution of the source file is 810x608 and the framerate is 25 fps.
For mpeg2 decoding I use Main Concept DShow filter from OpenCube.
I'll have to encode the WMV with a bitrate of 600kBit/s.

The encoded content has a good quality for sourcefiles that have a low bitrate, i.e. 25 MBit/s or 15 MBit/s.
But surprisingly the results for mxf-files with higher bitrates (about 50MBit/s) are worse quality with visible artifacts.
Can you explain why this is so?

I have tested this with different profile-settings, deinterlacing and different encoding-codecs. I tried the "Windows Media Video 9 Advanced Profile" (VC-1 codec) with different registry settings that may improve quality, without any usable results. I also tried different settings for the mpeg2-decoder, so as a completely other decoder. The results were still bad in quality.

Maybe there is a problem with the compressibility of my sourcefiles.
When you take a closer look at the videoimage you can see that it contains "stipes" that might result from the interlacing.
Do these affect the encoded videocontent in a way that artifacts are produced?

Do you know any way to improve my output?

Maybe it could help you to take a look at my encoding-settings, from which I expect a better quality:

My actual profilesettings (an extract out of the .prx-file) are the following:
...
<streamconfig majortype="{73646976-0000-0010-8000-00AA00389B71}"
streamnumber="2"
streamname="Video Stream"
inputname="Video409"
bitrate="600000"
bufferwindow="-1"
reliabletransport="0"
decodercomplexity="AU"
rfc1766langid="en-us">
<videomediaprops maxkeyframespacing="40000000"
quality="100"/>
<wmmediatype subtype="{31435657-0000-0010-8000-00AA00389B71}"
bfixedsizesamples="0"
btemporalcompression="1"
lsamplesize="0">
<videoinfoheader dwbitrate="600000"
dwbiterrorrate="0"
avgtimeperframe="400000">
<rcsource left="0"
top="0"
right="0"
bottom="0"/>
<rctarget left="0"
top="0"
right="0"
bottom="0"/>
<bitmapinfoheader biwidth="0"
biheight="0"
biplanes="1"
bibitcount="24"
bicompression="WVC1"
bisizeimage="0"
bixpelspermeter="0"
biypelspermeter="0"
biclrused="0"
biclrimportant="0"/>
</videoinfoheader>
</wmmediatype>
<dataunitextension extensionsystemid="{1B1EE554-F9EA-4BC8-821A-376B74E4C4B8}"
extensiondatasize="2"
extensionsysteminfo=""/>
</streamconfig>
...

My actual registry settings of the VC-1 are as follows:
(I experimented with the values as well)
DenoiseOption = 1
Force Median = 0
Force Overlap = 1
Video Type = 1
NumBFrames = 1
Force LoopFilter = 1
Dquant Option = 3
Dquant Strngth = 3
Motion Search Level = 1
Motion Search Range = -1
Motion Match Method = -1
Motion Vector Cost Method = 1

Maybe someone can help or has an idea ..
Many thanks in advance!

[diogen]

The encoded content has a good quality for sourcefiles that have a low bitrate, i.e. 25 MBit/s or 15 MBit/s.Are those sources of the same nature as the high bitrate ones?
When you take a closer look at the videoimage you can see that it contains "stipes" that might result from the interlacing.This was happening to me when trying to deinterlace while encoding (combing on horizontal movement).
Have you tried leaving it interlaced (what was claimed to be one of the advantages of the latest VC-1 update of the WME)?

Diogen.

[d_wei]

Are those sources of the same nature as the high bitrate ones?
The sources with the lower bitrate are also mpeg2 interlaced I-frame only, whereas they are not wrapped in mxf.

Have you tried leaving it interlaced (what was claimed to be one of the advantages of the latest VC-1 update of the WME)?

I also tried leaving it interlaced, without any mentionable quality improvement.

[diogen]

I think zambelli would be able to shed some light on your problem.

What is your video card? Codecs?
Can it be that the "bad" encodes tax your system too much?

Diogen.

[d_wei]

Hello, first of all thanks for your replies and your efforts!

Does the wmv-encoding really depend on my GPU? I thought encoding only stresses the CPU? (maybe I am totally wrong .. I am relatively new concerning video-transcoding and windows media) Or can I somehow tell my encoder that he only may use GPU for processing? And do I achieve better results then?

Apart from that I am testing on two different systems.

CPU: Pentium M at 1.8GHz
1GB RAM
GPU: RADEON 9600

CPU: Centrino Duo with 1.7GHz
1 GB RAM
GPU: GeForce Go 7400

For mpeg2 codecs I am using Main Concept DShow Filter v. 1.5.3
I also tried the Elecard Mpeg Player v 4.5.70111

My system is running at 100% CPU usage the whole time during encoding. But I heared from someone other, that the CPU-performance doesnt affect the quality of the output that much, it only affects the time that encoding takes.
The bad encodes don't take longer in time than normal encodes.

[diogen]

Does the wmv-encoding really depend on my GPU? No. Just the time it takes.
Some filters can offer GPU assistance to the CPU in encoding (IIRC Elecard has a checkbox in filter properties to do that). But it will make less than a 5% difference.
My system is running at 100% CPU usage the whole time during encoding.That's normal.

Your PC's specs are on the low end for WMV playback.
Although the first configuration should be good enough for anything up to ~6Mbps (unless you'd have used a lot of B-frames and filters).

I think somebody more experienced should chime in.
I believe only a failed attempt to deinterlace while encoding can produce the type of combing you were talking about.

Diogen.

[d_wei]

okay,

i'll wait for another suggestions.

nevertheless, thank you very much diogen!

[zambelli]

The MPEG compression is acting as a spatial filter on the image. That's why the lower bitrate MPEG sources also re-compress better - they don't have much variety of information to start with. Higher MPEG bitrates preserve more detail and thus the WMV9 codec has more detail to deal with too, requiring more bitrate as well.

Compressing interlaced video as progressive is inefficient because the encoder has to perform motion estimation on what's essentially two different time instances within the same frame.

Generally, 600 kbps is not enough to compress 810x608x25 video well with any codec - H.264, VC-1, VP6, etc. You'd need at least 3x that to get good quality out of it.

[d_wei]

thanks for your advice zambelli.
That helped me understanding this phenomenon a bit better!

Unfortunately I have to encode with 600kbps, but now I know that there cant be great quality improvements with such a bitrate. And you are right: for bitrates ~2Mbits I get a real good quality.

I will also try not to deinterlace the content.

Thanks a lot!

[zambelli]

I will also try not to deinterlace the content.
Only if you plan on encoding it as interlaced - but at 600 kbps, that's going to look even worse. No, you should continue deinterlacing - but maybe find a better deinterlacer if you're seeing combed lines in your output.

OK, so you've got only 600 kbps, but do you have to encode at that resolution? Couldn't you scale to a lower resolution?