DSS bug (?) build from stable avs 2.56

[Egh]

I think i spotted a bug in DirectShowSource(). I have last stable AVS 2.56 installed.

Here's t3h problem:


I have video source in wmv9-encoded AVI
I transcode the file into XVid (with filtering)
Since timecodes for that file are pretty b0rked, the best way to deal with that file is to use fps=23.976 and convertfps=true
in 99.99% of the file it works superb
In at least three cases thru the movie (90min) it didnt


Lets' take as an example the worst affected place. In it, the timecodes from original (non-reencoded) video go like that (it's after 16:20 timestamp):


981814.000000
981856.000000
981898.000000
981939.000000
981981.000000
982023.000000
=that's the GAP!=
984192.000000
984233.000000
984275.000000
984317.000000
984358.000000
984400.000000


That's the timecodes I extract from MKV file when I mux the original AVI. i.e. all null-frames are removed. So we have a gap in timing here. This gap is BLANK. Whilst playing source in mpc and even .avs with no conversion in DSS enabled, it is the case, true. BUT! When I encode with convertfps=true and fps=23.976, I get a still frame (from the following scene) instead of blank screen! So there's like a pause several seconds long and then animation starts ... And that's quite annoying for a viewer ^^ For what reason DSS replaces blank screen with a still from next part of animation, i have no idea ^^

Any solution to correct this behaviour? If needed, i may provide a part of that original wmv-encoded avi as well.

[foxyshadis]

You may have run into a problem I've noticed when using dedup with looooong dup segments: the timecodes are all off by one. I don't know whether the bug is in mkvmerge or megui (I've verified dedup's timecodes against the source avisynth), but the first frame gets removed so all long timecode jumps are screwed. In your case, it's treating the long black frame as the short frame before it.

Solution: chop the first timecode out and remux with the new file.

Hope that helps.

[Egh]

Solution: chop the first timecode out and remux with the new file.

Hope that helps.

Nope. If i understood you correctly, you imply that mkv timecodes are wrong.

MKV timecodes above were taken only for illustration of the nature of the problem here, since mkvmerge removes null-frames upon muxing. The transcode was done from the original AVI file, hence no timecodes involved.

It just seems that on those long null-frames runs DSS() with convertfps=true somehow confuses which frame to take.

To be more clear, consider this:

A1 .. A24 [null1] .. [null100] B1 .. B24. Where A&B -- 24 frame animations, and some long sequence of nullframes is inserted between them.
All that packed in AVI. DSS() with fps=23.976 and convertfps=true is used to read the file. If i'm not stupid too much, then what is DSS() is supposed to create in this mode is A1..A24 [A24.1]...[A24.100] B1 .. B24.
Effectively replacing null-frame or whatever it's called in WMV with LAST frame of previous animation (and thus the timing is preserved and video now is CFR). That's what happening during playback of the original file on any videoplayer.

What I get here with convertfps=true, is A1..A24 ...[B1.100] B1 .. B24 i.e. DSS() inserts the [b] FIRST frame of second animation sequence. Imagine that first animation is fade to black thus A24 is completely black frame, and B1 is some begining frame of animation sequence (no fading). Then instead of several seconds darkness you get still frame which in 4 seconds suddenly starts moving ^^. That exactly what I get in the encode.

[IanB]

@Egh,

DirectShow represents multimedia data streams in a different way than AVI does, DirectShowSource() tries to bridge the 2 technologies, sometime the conversion is a compromise.

AVI represent Video as a contiguous stream of samples, each sample a fixed constant length. Audio samples are typically 1/44100 or 1/48000 of a second, video samples 1/25th or 1001/30000th of a second. These are the classic TV standard rates, 25fps and 29.97fps video with 44100Hz and 48000Hz audio.

With Microsoft DirectShow each sample has a start time and end time in 100 nanosecond units, thus DirectShow can handle variable frame rate. Thus for a standard 25fps video stream frame 0 start at time=0 and ends at time=399999, frame 1 starts at time=400000 and ends at time=799999, each frame duration is 40 milliseconds. For a Variable Frame Rate (VFR) stream frame 0 would start at time=0 and could end at time=912345, frame 1 would start at 912346 and could end at 915000, the length of each frame is not constant This is not compatible with AVI.

In order to make a usefull approximation of VFR media as an AVI stream DirectShowSource() with ConvertFPS=True reads the ending time code and continues to emit the same frame until the agregate of the fixed periods of AVI time exceeds that end time. Currently the start time is assumed to be contiguous with the previous samples end time and is effectively ignored.

I hope to add diagnostic modes to DirecShowSource() that will print parameters like the start and end time of each DirectShow sample in the future. This hopefully will allow users to better appreciate how the conversion from DirectShow to AVI is functioning, and be able to better document their requests for enhancements and bug fixes.

[foxyshadis]

I think what he's getting at is that in his case it's extending the wrong frame, the opening frame of the next scene when it should be the final (black?) frame of the last scene.

[Egh]

@Egh,

In order to make a usefull approximation of VFR media as an AVI stream DirectShowSource() with ConvertFPS=True reads the ending time code and continues to emit the same frame until the agregate of the fixed periods of AVI time exceeds that end time. Currently the start time is assumed to be contiguous with the previous samples end time and is effectively ignored.

I hope to add diagnostic modes to DirecShowSource() that will print parameters like the start and end time of each DirectShow sample in the future. This hopefully will allow users to better appreciate how the conversion from DirectShow to AVI is functioning, and be able to better document their requests for enhancements and bug fixes.

Well I understand this. Seems that in this case A24 ending time is reported ok, but since starting time of B1 is ignored, all the time interval between A24 and B1 is filled with B1, not A24. Am I right?

But is there a way to tweak that behaviour? I mean the file is played flawlessly in video player. Any need for video samples with that problem to be uploaded?

[IanB]

Seems that in this case A24 ending time is reported ok, but since starting time of B1 is ignored, all the time interval between A24 and B1 is filled with B1, not A24. Am I right?Yes, A24 will be output upto it's end time, then B1 will be output upto it's end time. If the end time of A24 and the start time of B1 are not contiguous I have no documentation about what to do. From the contents of this post I guess you would like me to output a Black frame for the duration.

When I get time to implement the logging options, submitting the log will be sufficient.

In the mean time judious use of FreezeFrame may hide your problem.

[Egh]

Yes, A24 will be output upto it's end time, then B1 will be output upto it's end time. If the end time of A24 and the start time of B1 are not contiguous I have no documentation about what to do. From the contents of this post I guess you would like me to output a Black frame for the duration.

When I get time to implement the logging options, submitting the log will be sufficient.

In the mean time judious use of FreezeFrame may hide your problem.

Not black frame. Effectively prolongation of A24 upto B1 start time. That's what's happening during casual playback (i.e. A24 is shown, then following frames upto B1 are just dropped, leaving A24 onscreen).

Freezeframing? Dont' think this would help here much... Well i solved the problem my way, but that's AWFUL lot of job. I recoded GOPs containing those pauses separately, with BlankScreen(oldclip).Trim(x,y) to manually overdraw the paused still frame with black frame. Then I patched my encode with those reencoded GOPs. Took quite a lot of time to make sure it's all frame precise (both black frame runs and GOPs themselves)

[IanB]

The following will pad the gap between the end of A24 and the start of B1 with A24FreezeFrame(avsA24, avsB1-1, avsA24)Where the numbers avsA24 & avsB1 are the avs framenumbers corresponding to the Direct show samples A24 and B1 respectively.

[IanB]

The DirectShowSource in Avisynth 2.5.7 Alpha 3 now has a logging to disk option.

[Egh]

The DirectShowSource in Avisynth 2.5.7 Alpha 3 now has a logging to disk option.

interesting. At least will be good for debugging if something goes wrong again :P

[Isochroma]

Some time ago I verified that mkvmerge loses [or doesn't display on playback or directshowsource()] frame 1 of any video stream. This applies to vfw-mode, native AVC & ASP streams.

Thus when muxing audio streams, it is correct to subtract the time for one frame from the audio delay value, in order to achieve perfect sync.

[foxyshadis]

I think that bug was fixed, because I haven't had to edit my timecode files in a while now. (That was a real mess, but I always thought it was x264 eating the frame. Guess not.) It might be only in post-1.6.5 builds though.