Non-const result when encoding wmv

[huang_ch]

I've meet a strange issue today, when I encoded one WMV file using X264 several times with same options, I found that the results are not the same, the lowest is ~421Kbps and the highest is ~427Kbps. And I just tried another WMV file, it also gives several different results. But some AVI file with XVID/DIVX codec don't have this problem.
Has anyone meet this kind of issue before? Anyone know the reason? Thanks.

[Manao]

DirectShowSource may not give identical results when used on WMV files.

[check]

try converting to a lossless format first. If this fixes it, the problem lies in the wmv decoder.

[huang_ch]

DirectShowSource may not give identical results when used on WMV files.

Is this the problem of MS's WMV decoder or the problem of DirectShowSource itself in AVISynth?

[Inventive Software]

DirectShowSource has had problems with ASF files for yonks. :search: and you'll find out why. ;)

[huang_ch]

DirectShowSource has had problems with ASF files for yonks. :search: and you'll find out why. ;)

Thanks, I got it. Will it be improved in future 2.5.7 or 2.6 version?

[foxyshadis]

You'll have to ask IanB about that, if he even knows. The 2.57 beta DSS is much improved over the 2.56 in my experience already.

[IanB]

I've met a problem with WMV, here is the post:
http://forum.doom9.org/showthread.php?t=119276
And as those guys suggested, I've searched the forum and found that by adding convertfps=true, it seems to work. But I think convertfps=true is just like a patch/workaround for this issue, so I just want to ask, is the new DSS in 2.5.7 improved to have a better support on WMV/ASF and even other VFR sources? Or I still need the convertfps=true patch?Yes, WMV/ASF is a real pain.

The convertfps=true option is designed to insert duplicate frames into the stream where WMV has used temporal compression due to very low motion.

Unfortunatly Microsoft have recently changed to behaviour of the ASF spliter to no longer provide correct end times for the frames delivered :( (They now deliver start time + 1ms as the end time). The net effect is the convertfps function duplicates the wrong frame and you get visual judder. :(

As for variable results, this is caused by seeking in ASF being inexact, which mean you may not get the expected frame if you seek and the avisynth cache has a miss. As already suggested, the best solution is to strip the ASF stream to a more seek friendly format using a single pass without any seeking and use the seek=false option as protection.

[huang_ch]

Unfortunatly Microsoft have recently changed to behaviour of the ASF spliter to no longer provide correct end times for the frames delivered :( (They now deliver start time + 1ms as the end time). The net effect is the convertfps function duplicates the wrong frame and you get visual judder. :(

Do you mean that with latest ASF splitter, even convertfps=true could give a bad result? Which version does this new splitter comes with? I've just updated my machine to WMP11, and have encoded several WMV file, don't see any audio/video sync problem. But seems to really have some kind of visual judder. Do you have any suggestion how to avoid this? Go back to WMP10 or even WMP9?


As for variable results, this is caused by seeking in ASF being inexact, which mean you may not get the expected frame if you seek and the avisynth cache has a miss. As already suggested, the best solution is to strip the ASF stream to a more seek friendly format using a single pass without any seeking and use the seek=false option as protection.
I've just tried adding seek=false to the DSS loader, but I still get variable results. And also try to mux video/audio stream into an AVI using VirtualDub-MPEG2 with direct stream copy, and encode that AVI, also get variable results.

[Trahald]

And also try to mux video/audio stream into an AVI using VirtualDub-MPEG2 with direct stream copy, and encode that AVI, also get variable results.Do you mean that you do
A.) source.asf->avi using seek=false->wmv#1
\
>wmv#2

or are you doing

B.) source.asf->avi using seek=false#1->wmv#1
\
>avi using seek=false#2->wmv#2

[huang_ch]

Trahald, sorry, I'm quite confused about your A) & B).
Let me try to explain more clearer, I've tried below tasks, all gave variable results: (all using X264 encoding)
1. DSS( "file.wmv" ) -> X264
2. DSS( "file.wmv", seek=false ) -> X264
3. DSS( "file.wmv", seek=false, seekzero=true ) -> X264
4. file.wmv -> VirtualDub-MPEG2 direct stream copy -> file.avi, DSS( "file.avi" ) -> X264
5. file.wmv -> VirtualDub-MPEG2 direct stream copy -> file.avi, DSS( "file.avi", seek=false ) -> X264
6. file.wmv -> VirtualDub-MPEG2 direct stream copy -> file.avi, DSS( "file.avi", seek=false, seekzero=true ) -> X264

[IanB]

@huang_ch,

Perhaps you had better define "variable results" with explicit examples at the frame level of how one pass is different to the next.

Also I think a DSS Logfile might be very instructive.

Please encode the following script twice in sucession.DirectShowSource("file.wmv", seek=false, audio=false, convertFPS=True, logfile="Huang.log", logmask=-1)
Trim(0, 1000)I am assuming there is no problem with the Audio and 1000 frames is enough to show the problem. If this is not the case extend the Trim and/or enable the Audio.

Zip the Huang.log and post it here. Along with a description of how the 2 supposedly identical encodes are different.

[huang_ch]

IanB, I did three tests, each one is a one pass encode with X264 with the command line:
x264.exe --progress --threads 1 --crf 26 -o out.mp4 wmv.avs
Test 1:
Huang1.log
Bitrate: 666.45 kb/s
PSNR: Avg: 42.903

Test 2:
Huang2.log
Bitrate: 666.49 kb/s
PSNR: Avg: 42.905

Test 3:
Huang3.log
Bitrate: 666.51 kb/s
PSNR: Avg: 42.906

So as you can see, none of these result are exactly the same bitrate, I have got some bigger difference than these samples before. The log is attached. Another strange thing is that two logs are about twice as large as the rest one.