Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
6th December 2008, 15:22 | #1 | Link |
Registered User
Join Date: Sep 2006
Posts: 4
|
Problems with DirectShowSource
I have been using AviSynth for a while and have never had problems with DirectShowSource until yesterday, when I was video editing on two of my friends computers, both of which had the same error. When I tried to load a video from DirectShowSource, I would get, in some form, a video format not supported error. This is strange, because the video worked in both GraphEdit and WMP. GraphEdit showed the source, split my Haali's, decoded by CoreAVC/AAC and sent to the video/audio devices.
I eventually solved the problem by adding: DirectShowSource("01.MOV", fps=29.97, pixel_type="RGB") I do not understand why this worked, or why the line was necessary. When I returned to my usual computer, I could load it without. I know only a small bit about colorspaces, but shouldn't AVS be able to load using DirectShow regardless? Also, don't know if it's related, but the video was vertically flipped on my friend's computers. I solved this problem with FlipVertical(). |
6th December 2008, 22:04 | #2 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Specifying the pixel_type argument to DirectShowSource() enables the DirectShow interface, IPin::EnumMediaTypes, processing. By default DirectShowSource() returns E_NOTIMPL for this method.
This is so upstream DirectShow filter are free to bid all of their supported media types in the order of their choice. A few DirectShow filters get this wrong. When the IPin::EnumMediaTypes interface is enabled and supported the upstream DirectShow filter is constrained to bid only media types it supports from the provided enumerated list and in the order of that list. Many DirectShow filters get this wrong, this is why it is not enabled by default. The option exists so you have enough control to encourage the maximum range of filters to serve your media. On your friends PC's the final upstream filter either does not handle the E_NOTIMPL case correctly, or has a bug in the code for the first Avisynth compatible media type that it bids. You can try using pixel_type="AUTO" to determine which case you have. The current Avisynth enumeration order is MEDIASUBTYPE_YV12, MEDIASUBTYPE_YUY2, MEDIASUBTYPE_ARGB32, MEDIASUBTYPE_RGB32 and MEDIASUBTYPE_RGB24. If using pixel_type="AUTO" works then there is likely a problem in the code for the E_NOTIMPL case. If it fails then there is likely a problem in the YV12 or YUY2 code paths of the filter. You can test further with pixel_type="YV12" and pixel_type="YUY2". Specifying pixel_type="RGB" enumerates the 3 rgb media types. |
7th December 2008, 01:48 | #4 | Link |
Registered User
Join Date: Sep 2006
Posts: 4
|
Thanks for this explanation. I do remember trying pixel_type="YV12" at the time, and this gave me an error as well. What would cause, as you explained it, a problem with the YV12 or YUY2 code paths? Is there a way to correct this problem?
|
7th December 2008, 08:00 | #5 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
@Gavino,
Harvest what I wrote, clean it up and give it to Wilbert or add it to the Wiki yourself. @Viett, When using pixel_type="YV12" there are 3 possible outcomes :-
|
7th December 2008, 08:15 | #6 | Link | |
Registered User
Join Date: Sep 2006
Posts: 4
|
Quote:
|
|
7th December 2008, 08:36 | #7 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
@Viett,
DirectShow is a truly complicated and unpredictable thing. Add logfile="logfile1.log", logmask=-1 to your DirectShowSource() calls, ZIP up the log files and post them, I'll take a look. |
Thread Tools | Search this Thread |
Display Modes | |
|
|