DirectShowSource dropping last x frames without seeking/trim()

[Snowknight26]

I've written a batch file that essentially converts Fraps-recorded videos to H.264/AC3 MKVs. The only problem I've run into so far (apart from different colors) is that the resulting MKVs always seem to be 2 or so less frames than the source.

The collection that I'm working with:
http://stfcc.org/misc/epiczip.zip - you'll have to download eac3to (http://madshi.net/eac3to.zip) and put it the folder so it looks like this if you want to try it:

http://i42.tinypic.com/2j0mv74.png

One odd thing I did notice is that when I switch to DSS2, x264 reports encoding 1 less frame than when using DirectShowSource, which, again, seems to be 2 less frames than the source. The strange thing is there is no seeking being done and trim() or anything similar isn't being used.

My default graph is of Haali Media Splitter -> ffdshow for Fraps decoding so that can't be it. So it seems that everything is in order and DirectShowSource must have a bug in it.

If anyone could confirm that it is or that its an issue with the script and/or has a workaround, I would definitely appreciate it.

[J_Darnley]

FYI: You can escape with ^ in cmd.exe or in a batch file. It works fine like: echo ConvertToYV12^(^) > file.avs

[Snowknight26]

I know, I tried that before but it still said that I had an unexpected (. I solved it however when I found out that you can't have a comment line right before a closing ) like this:

for [...] DO (
:some code
)
I've updated my first post and reflected the change in the zip.

[IanB]

DirectShow is notorious for lying about the parameters of media, typically the length. Avisynth needs to know the length at startup. There is a framecount=number option to override the detected media length. Most media players using the DirectShow API just keep processing the stream until the End of Stream condition, any length value is mostly used for UI display purposes only and it doesn't matter if it is approximate, Avisynth needs an accurate length to return the correct frame count for the script to it's parent application. Setting framecount larger than the true media length results in the last frame being repeated to pad to the specified length.

[Snowknight26]

Most media players using the DirectShow API just keep processing the stream until the End of Stream condition

So I'm guessing that Avisynth's DirectShowSource doesn't do that, as if it did, it would have the proper frame count? Or is it just outputting its best guess and then using that best guess to detect where the end is, regardless if the EOS is several frames further? Or am I looking at it incorrectly?

Is there any automatic way of getting an accurate frame count so I can add it to the batch?

[Leak]

So I'm guessing that Avisynth's DirectShowSource doesn't do that, as if it did, it would have the proper frame count?
It can't - AviSynth is based on VfW, and in VfW you absolutely need to know the number of frames you'll return when a file (or AviSynth script) is opened, i.e. you can't just "keep on decoding" after the initial number of frames have been returned...

np: Dan Le Sac vs. Scroobius Pip - Thou Shalt Always Kill (Angles)

[Snowknight26]

I found a fairly accurate way to get the number of frames. Demux the PCM in the source AVI->MKV remux. Since its 2 channel, 16-bit, 44.1KHz audio, its as simple as doing:

(pcm size)/(2*16*44100/8) = seconds * fps = frames


So in this case,
(1,314,816)/(2*16*44100/8) = 7.45360544 * 30 = 223.608163, rounded up to 224.

Now the real kicker is that before I even specified framecount=224, x264 reported encoding 224 frames even though the source's end frames don't match the encode's end frames. Seems even with the right number of frames, DirectShowSource still does something wrong?

[Keiyakusha]

Snowknight26
Maybe I don't understand something here, but if this somewhat helps you...
Source file hl2 2009-06-18 14-34-56-64.avi has 224 frames. After opening it in Virtual Dub through Avisynth DirectShowSource (ffdshow as FRAPS decoder), video has 224 frames. After opening it in VirtualDub directly (ffdshow vfw as FRAPS decoder), video has 244 frames. And after running epicbat.bat, result has exact 224 frames.

[Snowknight26]

Keiyakusha, true, they all seem to have the same number of frames. But if you were to seek to the very last frame of the source and the encode, you'd see two different frames.

[Keiyakusha]

Keiyakusha, true, they all seem to have the same number of frames. But if you were to seek to the very last frame of the source and the encode, you'd see two different frames.

What should I use for preview source and encode?

So far I used this script:
a=DirectShowSource("hl2 2009-06-18 14-34-56-64.final.mkv")
b=DirectShowSource("hl2 2009-06-18 14-34-56-64.avi")
StackVertical(a,b)And last frames are the same.

UPD: yes now I see. Frames are different frome time to time! But if I seek again they can became the same again. So this is random seeking bug? I thought it is known... I can't reproduse this without random seeking.

[Snowknight26]

Bah, I found out what it is. It's an MPC-HC seeking issue. Try this:

1. Open the source with MPC-HC and note the last frame.
2. Open the encode with MPC-HC and note the last frame.
3. Open the avs below with MPC-HC and not the last frame.

1 & 3 are identical (and correct), 2 is short several frames.

The avs:
DirectShowSource("hl2 2009-06-18 14-34-56-64.final.mkv")

In that case, can a mod kindly move this to the Software Players section?


Sorry for the false alarm.




P.S.: The SET command isn't the best way to do math in batch files unless you like your intermediate values to be truncated/rounded to the nearest integer.

[Keiyakusha]

Bah, I found out what it is. It's an MPC-HC seeking issue. Try this:

1. Open the source with MPC-HC and note the last frame.
2. Open the encode with MPC-HC and note the last frame.
3. Open the avs below with MPC-HC and not the last frame.

1 & 3 are identical (and correct), 2 is short several frames.


I can confirm this, but only with MPC-HC internal decoder.