Log in

View Full Version : Why does an WME9 .avi file playback more smoothly than an WME9 .wmv file?


SeeMoreDigital
24th June 2003, 22:37
I wonder if a few of you guys might be able help out and provide some information regarding an observation I made the other day!

Take one short (10min or so) source file and encode it twice, at the same 1000kbps bitrate. Once as an 'video only' .avi file and then again as an 'video only' .wmv file. Both at full frame size 720w x 480/576h (anamorphic).

Then burn the two files onto a CD-R. Find a fairly slow PC, say a 350MHz P2 or similar and then playback the files.

I did this the other day and was surprised to find that the .avi file played back almost perfectly but its .wmv conterpart did not!

After mentioning this observation to Pamel and SystemLoc. SystemLoc suggested that I turn off post-processing, which helped .wmv playback slightly but did not solve the problem.

So does anybody have any ideas why this is so?

On a separate note, when the same source file was encoded to DivX and XviD, at the same bitrate. These files did not play back as well as WME9 .avi either!

SeeMoreDigital
27th June 2003, 09:22
It's a shame there's nobody out there that can answer this!

I would have thought some of the Microsoft guys might know why the .avi (VCM) version of their WME9 codec plays back video, more smoothly, and uses less system resorce, than every other available video codec!

midiguy
1st July 2003, 19:51
maybe the wmv container is heavy, but the codec itself is fast?

Atamido
2nd July 2003, 05:19
I don't remember hearing, but did you try to transmux the AVI to MKV and see if the playback is any different? What about ASF to AVI/MKV? Because of the WM9 vfw codec, you should be able to do a direct copy of the WMV file with an older version of VirtualDub.

midiguy
2nd July 2003, 06:05
Originally posted by Pamel
I don't remember hearing, but did you try to transmux the AVI to MKV and see if the playback is any different? What about ASF to AVI/MKV? Because of the WM9 vfw codec, you should be able to do a direct copy of the WMV file with an older version of VirtualDub.

I believe the older version of virtualdub only supports the older ASF container (although I have never tested it with the newer wmv container).

Atamido
2nd July 2003, 07:56
I thought I remembered someone saying that the WMV files were the same format as the old ASF files. I just tried it out, and I cannot get VD to open WMV files. I will look into it more later.

midiguy
2nd July 2003, 08:00
Originally posted by Pamel
I thought I remembered someone saying that the WMV files were the same format as the old ASF files. I just tried it out, and I cannot get VD to open WMV files. I will look into it more later.
hmmm, that could be, but I am pretty sure they are different.. try renaming the extention from .wmv to .asf :confused:

Atamido
2nd July 2003, 08:45
What are you using to encode the video to WMV?

Here is what happenned for me. I have a simple 24fps Video-only test video that I made. Its CGI, so it is easy to see any jerkiness.

The WMV version was jerky, but the AVI version was fine. I openned the WMV in VDMod using the AVISynth DirectShowSource feature. What it showed was that my video had been converted to 30fps, and every 5th frame had been duplicated to increase the framerate. The reason that my video in the WMV version seems so jerky is that the video basically stalls 5 times per second.

This is the default behaviour when encoding using the Windows Movie Maker and the Windows Media Encoder. After playing around with WME for awhile, I figured out how to get it so that it wouldn't try to change the video to 30fps. I had to go to the Properties, Compression, Destination, File archive, Quality-based, and then Frame rate. In the box I had to change the framerate manually to 24fps.

It seems pretty idiotic that WME would not default to whatever framerate the source video was, but whatever. Check this and tell me if you still have any problems.

SeeMoreDigital
3rd July 2003, 22:35
Hi Pamel,

To confirm. In my tests I use the same 'video only' source file, which is approx 5mins long, PAL, 720w x 576h pixel size, 25fps.

When I create a WMV9 file (with a .wmv extension) I use M$ very own WME9 encoder. And very nice it is too.... when it's working correctly!

When I create a WMV9 file (with a .avi extension) I use a little known application called MPEGmediator 1.5.

Both applications are configured to produce the same 720w x 576h 'output' pixel size, at 25fps. Even the file size is only 10KB different!

This is an odd one, which could have more significance than you would first think. After all if this version of the WME9 codec runs better on lower spec PC's then it's fair to assume it takes up less of a PC's resource and would be easier to stream!

mingcl
8th July 2003, 02:29
Sorry for the late reply. No, we are not ignoring this at all:)

I think this is more likely caused by the different presentation-time control mechanisms in these two pipelines (WMV/ASF and AVI).

In the WMV/ASF pipeline, WMP is pretty aggressive in adjusting the presentation time when the video playback is running behind. The result is that some of the P frames won't be rendered (if it is not too behind) or not even decoded until the next I frame (when it is truly behind).

It is less aggressive when decoding/playing back AVI files. But I assume there are still some frames not being decoded/played in your AVI case.

It would be interesting to see how the CPU usage compares when playing back easier files (that is, no frame dropped during playback).

Ming
Microsoft

SeeMoreDigital
8th July 2003, 14:46
Hi Ming. Thanks for the reply.

As it happens I created some WMV9 .avi encodes with a frame size of 720w x 480h at 23.9762fps.

I was expecting a slight difference in playback performance. However the encodes suffered from virtually no frame lag at all.

So I can only assume that the 20% less definition (pixels) available between PAL and NTSC makes quite a lot of difference after all.

I have not tried creating encodes at say, 352w x 288h or 352w x 240h. But if the above findings run true, then playback of these files on a slow PC should be perfect!