DirectShowSource

[sh0dan]

I spent a few hours looking for a solution to the seek problems, without getting anything to work. DirectShow doesn't seem to allow ANY seeking this way, and it just hangs, if it is forced to do so.

So instead of just complaining about MS, I made it a bit more graceful. Now DirectShowSource allows skipping forward, but it will be SLOW! If the users searches backwards (which is impossible), it will continue to deliver the latest frame, but a big blinking "Video Desync!" will appear on the top of the frame, until the video is in sync again.

Hope this makes Avisynth a bit easier to use!

(And I'm not making any promises on DirectShow sound!)

[[Toff]]

Would it be possible to use the libav & libavcodec from the ffmpeg project to create a new source plugin ?
It support nearly all audio/video format.

The DirectShow filter ffdshow use it to decode mpeg1,2,4.

[Richard Berg]

In theory that should already be used if ffdshow is the default renderer for the given format.

[-h]

In theory that should already be used if ffdshow is the default renderer for the given format.

It would still be limited by the seeking/audio constraints imposed by DirectShowSource() though.

I think he meant, compile libav/libavcodec as an avisynth plugin with a function LibavSource(), that will be able to read pretty much anything you throw at it.

-h

[[Toff]]

[quote]
I think he meant, compile libav/libavcodec as an avisynth plugin with a function LibavSource(), that will be able to read pretty much anything you throw at it.
[quote]
Yes it's the idea.
Removing the DirectShow layer to have better flexibility.

[wing1]

@sh0dan

Thanks for the added lanczosresize code with the avisynth version. It is working great! :) However, I did not have any issue opening files using directshow and seeking forward or backward with the previous version of avisynth. It was working lightning fast. Audio input with directshowsource was the only issue then. The only time when I have problem with seek (back and forth) is with the various plugins that I used. Mplayer2 playback the *.avs with seek flawlessly; However, the 2.05+ version is making that impossible now especially the trim function.

I capture my clips using xvid and MS MPEG4-V3-vki codecs with high bitrate. Opening xvid clips using AviSource is not a problem, but MS MPEG4-vki clip can not be open with AviSource anymore with this version: It is now default to error. Furthermore, it crashed if i do anykind of seek. Virtualdub behaves exactly like Mplayer2 opening such *.avs.

Is there any issue reported as such from other users?

[sh0dan]

However, I did not have any issue opening files using directshow and seeking forward or backward with the previous version of avisynth.
OK - I haven't gotten any files to seek myself, put since it actually IS possible I'll put the code back in. I'll try to see if I can detect this automatically, so I can fall back to the current code, if search fails.
Sounds ok?


Whats the advantage of using vki over DivX3 or even Xvid?

[sh0dan]

OK - uploaded a new version, that has the new functionality as fallback code, if the filters report, that they are unable to seek.

[int 21h]

Originally posted by sh0dan

Whats the advantage of using vki over DivX3 or even Xvid?

Original DivX 3 codecs had a hardcoded bitrate check to enable keyframe placement at scene changes. If the bitrate was below 460 kbps, keyframes were automatically inserted on scene changes (for more efficient bitrate usage), all bitrates higher just used keyframes inserted at X interval (where user specified X seconds). VKI (Variable Keyframe Interval) in the sense of DivX 3 is a simple Hexedit that changes that value of 460 to 6000. Nandub of course used Virtualdub's internal scene change detection algorithms (along with some tweaks and suggestions made by a group called ViRA) to insert keyframes and did not rely on the DivX hexedit (which proved to be unreliable in most situations). Mpeg 4 v3 VKI is the exact same thing as DivX VKI (i.e. Low motion codec hexedited to 6000 instead of 460)

XviD of course has an automatic keyframe insertion algorithm (in a sense VKI) based on frame sizes, which seems to be pretty accurate (except in fadeins/fadeouts, but recent additions to the code may have changed that).

In short, VKI simply ensures an accurate insertion of keyframes for better bitrate usage and better appearance (since keyframes usually have a higher quant than a regular deltaframe).

[bbq@KL]

Originally posted by sh0dan
(And I'm not making any promises on DirectShow sound!) I would love to see MPEG-2 Splitter like this:
http://www.microsoft.com/Developer/PRODINFO/directx/dxm/help/ds/mpeg_2/using_splitter_filter.htm

AC3/LPCM decoding under DirectShow can be done by using free DirectShow filters. Those formats are more popular than the rest.

It would be really nice if we can split AAC from transport stream and DTS from a DVD. Is it kinda tricky to split the DTS track? Maybe we can specify the stream id ourselves. Just choose one of the following and ask AVIsynth to grab the right track:

0xBD 0x80 AC3 (5.1)
0xBD 0x81 AC3 (2.0)
0xBD 0x82 AC3 (commentary track 1)
0xBD 0x83 AC3 (commentary track 2)
0xBD 0x88 DTS (5.1)

[wing1]

@int 21

Thanks for explaining the detail. I agreed as to the quality gained over divx3.11alpha from VKI at the same bitrate upto a certain point.

@Sh0dan

I used VKI before xvid came into being, and then I switch over since. I am just now re-encode back all that I've captured :) VKI, IMHO, produces less macroblock artifacts then 3.11alpha. I'll test the new codes once I return from work. Thanks again :)

[Belgabor]

I'm still a n00b on directshow programming and don't know how the curret implementation of directshowsource works, but could it be improved by creating a native special rendering directshow filter that interacts with avisynth?

Just a (probably wacky) idea.

Cheers
Belgabor

[[Toff]]

Not that I don't like directshow, if you don't like ffmpeg/libav/libavcodec what about making an avs source plugin that use transcode plugin :
http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/html/modules.html

[wing1]

@Sh0dan

Avisource, OpenDMLsource, and Avifilesource all return with can't open frame 0 error on mpeg4-vki encoded file, while directshow took forever to open the file if there is a trim function within the *.avs. If no trim function then it will launch immediately. However, it still took a long time to seek when you jump forward in time line.

[sh0dan]

Oh - it's AviSource that's failing ;)

Does it write "AviSource: Could not decompress frame 0"? If so, the first keyframe is either a dropped frame or the decompressor returns an error. I think the current solution is probably the most graceful, but I could add a boolean, so you could indicate if you want the check enabled or not - but disabling it is at own risk.

Seeking in DirectShowSource() will be slow - there's no other way of seeking, other than descompressing all frames up to the current. Trim() IS seeking, so that's why you have to wait.

[Blight]

DirectShow does allow Frame-Specific seeking.

But ... not with all formats, and extremely slowly with some formats.

MPEG2/ASF/WMV won't seek, but AVI/MPEG1 will.

The odd thing is, MPEG1 seeking was lightning fast in DX7 and become very slow in DX8, go figure.

[wing1]

Found some of my problem with 2.05+ and mpeg4-vki encoded avi's, and now AviSource function works once again. Seeking is back to normal for both forward and backward in time line.

The problem took place when I install wmv9 encoder/player and codec. It overwrote the original mpeg4-vki dll. Hence, I am getting weird problem with opening the source using AVISource function i.e. frame 0 can't decompress error. Re-installed mpeg4-vki dll and problem resolved; However, it decompresses the source to RGB32 by default :( and avisource("e:\source.avi",false,"yuy2") can't be used without running into decompressor can't produce yuy2 error.....

[sh0dan]

@wing1:
1) So vki-clips are ok?

2) DivX 3 (and related) ALWAYS decompress to RGB32 - it cannot run YUY2-mode. Use ConvertBackToYUY2()

@Blight:
No - I made the ImediaSeeker interface request, if absolute or relative seeking is possible - if not, it will make manual forward seek (by decompressing frames) - seems like the only way.

[wing1]

@sh0dan

yes, all is well now :) thanks.

[Black Hole]

I always get "Unrecognized exception" in line 1, in all files I tried to open using DirectShowSource. I have tried DivX 3 and DivX 5 AVIs, with and without audio, using either normal DivX Decoder Filter or ffdshow (lots of versions). I tried replacing AviSynth 2.05 with 2.06 and 2.07 ... no luck! It always shows the error in the first line.

Of course, the files work perfect in GraphEdit. If I remove ffdshow codec for a certain FourCC, GraphEdit opens with DivX Decoder Filter, so they both seem to work perfect ... but not with AviSynth (?)

My system is Windows 2000 SP3, nVIDIA Riva TNT2 M64, Detonator 29.42, DirectX 8.1 ... running on a Celeron 1300 with i815EP-B chipset. I have found a lot of people in the forum complaining about this bug, most with AMD processors, but I haven't really seen a solution. Is it being investigated?

Thanks for your time and patience.

[BH]

[Black Hole]

I have read more than 30 threads searching for a solution ... and I found this one (http://forum.doom9.org/showthread.php?s=&threadid=34350) that suggests to remove VobSub 2.18 and install a newer version ... guess what! It works! :D

[onesoul]

Cool avatar. I really like Stitch :)

edit: I really make useless posts :rolleyes: , oh well :)