Dropped frames using WME (newbie alert)

[MantheLok]

Hi all,

I'm new to this forum - I have read a lot of useful and informative threads, so hopefully someone can point me in the right direction :) I have done a search, but could not find anything to help further.

I am a multimedia student, who will be working with video in the upcoming trimesters, so I thought I'd try to get ahead of the game in terms of compression. I am doing some practice encoding with WME, just for a feel of options etc., using a 47 second video sequence - 720x576 DV in an .avi.

Initially I was encoding using profiles and predefined sessions in the GUI, usually at mid bit rates (>600K). I eventually started using the command line, so I would have control over the encoding sessions. However, at a low bit rate encode (200K video + 96K audio) I noticed I was getting dropped frames in video.

I am encoding use 1-pass CBR. Here is the log:



cscript.exe wmcmd.vbs -input c:\vids\orig.avi -output c:\vids\converted\cliptest6.wmv -config constants.weu

constants.weu = -pixelformat YV12 -v_clip 24 48 24 48 -v_width 640 -v_height 480 -v_mode 0 -a_mode 0 -v_bitrate 200000 -a_setting 96_44_2

-----------------------------------------------------------------------------------------------------------
Microsoft (R) Windows Media Encoder Command Line Script Utility
Copyright (C) Microsoft Corporation. All rights reserved.


Encoded: 47.4s (99.4%) Elapsed: 00:05:16 Left: 00:00:02 [0.15x]

======== Encoding Completed ========

Audio :
Codec: Windows Media Audio 9.2
Expected bit rate: 96040 bps
Average bit rate: 96040 bps
Expected sample rate: 5383
Average sample rate: 5383
Dropped byte count: 0 bytes
Dropped sample rate: 0
Total bytes: 575340 bytes

Video :
Codec: Windows Media Video 9
Expected bit rate: 200000 bps
Average bit rate: 177396 bps
Expected fps: 25
Dropped frame count: 407
Total coded frames: 786
Average sample rate: 16.273
Dropped bytes: 0 bytes
Total bytes: 1058793 bytes

Overall:
Encoding time: 318 seconds
Average bit rate: 273436 bps
File size: 1683343 bytes
File duration: 47.878 seconds


I came across the -v_quality option, which to my understanding (and is documented as such) the shift between video smoothness (0 being smoothest) and image quality (100 being best quality). So I decided to test both these settings to see if it would affect the dropped frames (ignore the paths and filenames, bad organisation, but the same source was used):

-v_quality 0:

cscript.exe wmcmd.vbs -input c:\testvids\chrisd.avi -output c:\testvids\converted\cliptest4.wmv -config constants2.weu

constants2.weu = -pixelformat YV12 -v_clip 24 48 24 48 -v_width 640 -v_height 480 -v_mode 0 -a_mode 0 -v_bitrate 200000 -v_quality 0 -a_setting 96_44_2
-------------------------------------------------------------

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Microsoft (R) Windows Media Encoder Command Line Script Utility
Copyright (C) Microsoft Corporation. All rights reserved.


Encoded: 47.3s (99.1%) Elapsed: 00:04:53 Left: 00:00:03 [0.16x]

======== Encoding Completed ========

Audio :
Codec: Windows Media Audio 9.2
Expected bit rate: 96040 bps
Average bit rate: 96040 bps
Expected sample rate: 5383
Average sample rate: 5383
Dropped byte count: 0 bytes
Dropped sample rate: 0
Total bytes: 575340 bytes

Video :
Codec: Windows Media Video 9
Expected bit rate: 200000 bps
Average bit rate: 176387 bps
Expected fps: 25
Dropped frame count: 239
Total coded frames: 954
Average sample rate: 19.875
Dropped bytes: 0 bytes
Total bytes: 1052774 bytes

Overall:
Encoding time: 295 seconds
Average bit rate: 272427 bps
File size: 1678821 bytes
File duration: 47.878 seconds


The dropped frames figure was reduced with -v_quality 0, but even still, frames were being dropped?


When using -v_quality 100, the dropped frames number increased:


cscript.exe wmcmd.vbs -input c:\testvids\chrisd.avi -output c:\testvids\converted\cliptest5.wmv -config constants3.weu

constants3.weu = -pixelformat YV12 -v_clip 24 48 24 48 -v_width 640 -v_height 480 -v_mode 0 -a_mode 0 -v_bitrate 200000 -v_quality 100 -a_setting 96_44_2
--------------------------------------------------------------
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Microsoft (R) Windows Media Encoder Command Line Script Utility
Copyright (C) Microsoft Corporation. All rights reserved.


Encoded: 47.6s (99.8%) Elapsed: 00:04:48 Left: 00:00:00 [0.17x

======== Encoding Completed ========

Audio :
Codec: Windows Media Audio 9.2
Expected bit rate: 96040 bps
Average bit rate: 96040 bps
Expected sample rate: 5383
Average sample rate: 5383
Dropped byte count: 0 bytes
Dropped sample rate: 0
Total bytes: 575340 bytes

Video :
Codec: Windows Media Video 9
Expected bit rate: 200000 bps
Average bit rate: 184114 bps
Expected fps: 25
Dropped frame count: 561
Total coded frames: 632
Average sample rate: 12.971
Dropped bytes: 0 bytes
Total bytes: 1098831 bytes

Overall:
Encoding time: 289 seconds
Average bit rate: 280154 bps
File size: 1719519 bytes
File duration: 47.878 seconds


However, I have read the WMCmd.vbs Thread (http://forum.doom9.org/showthread.php?t=123812&highlight=dropped+frames) and -v_quality did not seem to have any effect on dropped frames on other posters encoding logs.

Sorry if this is a rookie error, but I am a bit confused at why the frames have been dropped especially when it is not a live encoding session? I would have thought offline encoding would not drop frames? Or does WMV9/VC-1 deliberately drop frames as part of the encoding algorithm?

Have I missed out any information? I am using an Athlon XP 2400+/1GB RAM with Windows SP2.

Any help much appreciated :)

[Inventive Software]

Try using WME with a similar PRX profile and see if you get the same results.

[MantheLok]

Hi,

I have done as suggested - the number of dropped frames seems to have increased?


Action: Convert file

Sources used: C:\Documents and Settings\L0ki\My Documents\My Videos\NVEExportshortdvtype1volumedown.avi

Output files: C:\Documents and Settings\L0ki\My Documents\My Videos\WMV Encoded\200k.wmv

Content duration: 00:00:00:47 (dd:hh:mm:ss)
Session duration: 00:00:04:06 (dd:hh:mm:ss)

Session:
Bytes encoded (total): 1600.6 KB
Bit rate (expected): 296.04 Kbps
Bit rate (average): 274.26 Kbps

Video [200.0 Kbps]:
Bytes encoded (total): 1038.75 KB
Bit rate (expected): 200 Kbps
Bit rate (average): 178.22 Kbps
Frames per second (expected): 25.00
Frames per second (average): 17.15
Frames (total): 827
Frames (dropped): 366
Profile conformance: MP@ML

Audio [96.0 Kbps]:
Bytes encoded (total): 561.86 KB
Bit rate (expected): 96.04 Kbps
Bit rate (average): 96.04 Kbps
Samples (total): 258
Samples (dropped): 0
Profile conformance: L1


I created a PRX with similar settings as used in constants.weu, and used WME's GUI to import the prx.

What effect, if any, should encoding with a profile have as opposed to everything manually typed out on a command line?

[Dark Shikari]

Try using 2-pass.

[zambelli]

Quite simply: it's very, very difficult to encode 640x480 video at 200 kbps. The encoder must raise quantization levels in order to ensure compressed frames are small enough to meet the target bitrate and buffer, but once it gets up to QP=31 - it's got nowhere else to go, so it must drop the frame or otherwise it'd create a buffer overflow.

You should try increasing your buffer size in CBR mode (default is 5000 msec) or try using v_mode 3 (doesn't require a preset buffer). If that doesn't work, you'll need to either lower your resolution or framerate, or increase your bitrate.

[MantheLok]

Thanks for the explanation Zambelli :)

I will try your suggestions, at the moment I am getting to grips with 1 pass CBR, so will leave out v_mode 3 for just now.

[benwaggoner]

Can you give us a little more context about what you're trying to do? That's not really a combination that would be used in the real world.

If your goal is to just learn how this stuff works, at least make up a scenario you want to try and address, and we can help you from there.

Also, my blog has some end-to-end scenarios of advanced Windows Media encoding, if you're interested.

[Sergey A. Sablin]

Quite simply: it's very, very difficult to encode 640x480 video at 200 kbps. The encoder must raise quantization levels in order to ensure compressed frames are small enough to meet the target bitrate and buffer, but once it gets up to QP=31 - it's got nowhere else to go, so it must drop the frame or otherwise it'd create a buffer overflow.

it is actually underflow in common video coding terminology, as vc-1 as any other mpeg-like codecs operates with decoder buffer instead of encoder one.

[MantheLok]

Can you give us a little more context about what you're trying to do? That's not really a combination that would be used in the real world.

If your goal is to just learn how this stuff works, at least make up a scenario you want to try and address, and we can help you from there.

Yes, I was planning to run some tests using the MSU VQM software. Although these tests have been run endlessly to high standards, often including WMV9/VC-1, and have been documented, I would like to grasp how to encode and see/understand for myself how quality can vary.

To conduct a fair comparison, all encoded samples should be at the same resolution and frame rate as the source video being compared, right? I agree that 200kb/s at 640x480 does not conform to many popular devices, and unlikely used scenario, but it was a case of "how low can you go". I always thought dropped frames was a computational resource issue with live encoding scenarios....obviously not!

The switches I've used in the examples above, in the command line and constants.weu's, are not definate, simply testing those functions.

I have tried out Zambelli's suggestion of increasing the -v_buffer. I went from the default (5000) to 15000 in increments of 1000, for both -v_quality 100 (image quality) and -v_quality 0 (video smoothness).

For -v_quality 100, I found that roughly the same number of frames were dropped across the set of results, however the average bit rate increased as -v_buffer was increased. The average bit rate would exceed the 200kbps expected bit rate after -v_buffer 9000.

For -v_quality 0, I found as -v_buffer was increased, the number of dropped frames decreased. At the end of the set of results, -v_buffer 15000, the number of dropped frames had decreased from 239 (beginning of set) to 112. The average bit rate also increased as v_buffer increased, however did not exceed the expected bit rate until after v_buffer 11000.

I will try again soon with increased buffer values with higher stepped increments, just to see if it is possible to lower dropped fames to 0, or as close as.

What side effects and ramifications, if any, would increasing the -v_buffer have, in the case of WME or encoding in general? Would there be any extra demand on the decoder?