More DirectShowSource woes

[manolito]

I am fully aware that DirectShowSource is not frame accurate when seeking frames, it also sometimes presents frames upside down, but this is new to me...

Source is a standard MP4 file with AVC video and AAC audio. It plays perfectly in VLC and MPC-HC, but DirectShowSource chokes on it.

http://i41.tinypic.com/2rhmloj.jpg

This happens with 4 versions of directshowsource.dll ranging from AviSynth 2.56a to the latest 2.60 version. FFMS2 and also DSS2 handle this file perfectly.

Here is a 1 minute chunk of the offending file together with the AVS script:
http://www.sendspace.com/file/sgu89u


Anything I can do about it? I can live with the fact that DirectShowSource cannot decode this file, but at least it should throw an error (which it doesn't).

I use AVStoDVD for most of my conversions, it uses a script "A2DSource" which tries source filters in the order AVISource, DirectShowSource and FFMpegSource2. It falls back on the next filter if it detects an error. But for this particular file DirectShowSource does not throw an error, so it gets used and delivers a broken result.

Any ideas?


Cheers
manolito

[turbojet]

I can't reproduce it here with lavfilters splitting\decoding encoding with x264, playing in potplayer. But have had sync and interlace issues with directshowsource in the past. What splitter, decoder and encoder is being used?

Also DSS2 does have a standalone version that has a preroll parameter that prevents many issues with interlaced sources. Might be worth mentioning it to avs2dvd dev.

[hello_hello]

Oddly enough, I discovered by accident I can duplicate the problem when I managed to open a different file by mistake.

I opened a whole bunch of MKVs via DirectShow with ffdshow decoding and using MeGUI's preview. With ffdshow's resize filter enabled and the width set to 854.... the same result. It must be some sort of Avisynth, mod2 thing. A width of 838 produces the same result, as does 870, but if Avisynth is removed from the equation and the MP4 is opened by MPC-HC/ffdshow directly, it plays fine.
If you enable ffdshow's resize (or crop) filter and change the width a little, the MP4 should open okay (assuming of course you're using ffdshow). It seems it's gotta be when it's decoded though. Adding cropping to the script rather than getting ffdshow to do it doesn't work.

Even more odder..... I can't open DirectShowSource scripts with MPC-HC if the source video contains h264 video. Everything else can, but not MPC-HC.
http://forum.videohelp.com/threads/360864-An-odd-Avisynth-DirectShowSource-MPC-HC-problem
When opening your video however, MPC-HC doesn't display gibberish, instead the error message is different to the normal error message I get as it fails to open the video. The error is:

Resize: Source image too small for this resize method. Width = 0, Support = 3.

Maybe that means something, or maybe it's just AVIsynth gibberish, because I normally can't open DirectShowSource scripts with MPC-HC if the source video contains h264 video.

I have Avisynth 2.5.8 installed and MeGUI is using Avisynth 2.6. Both produce the same result with a width of 854 and that's with each using a different version of DirectShowSource.dll

PS.... If anyone can explain why I can't open DirectShowsource scripts with MPC-HC anymore if the source video contains h264 video.... as per the thread I linked to..... I'd like to know. :)

[Sharc]

@manolito
Does your app(s) invoke ffdshow filters?
Try what happens if you disable ffdshow, i.e.

ffdshow Video Decoder configuration / DirectShow Control
=> include your application in the list 'Don't use ffdshow in:'

This helped here in similar cases, like picture upside down.

[Edit]:
I tried your sample. Putting the application (MPC-HC in my case) in ffdshow's "don't use .... " list solved the problem.

You may also disable the libavcodec as H.264/AVC decoder in ffdshow - or perhaps mess around with filter merits.... (assuming that you have other H.264 decoders available with your system).

[filler56789]

@manolito:

your AVS file plays OK here (Avisynth 2.6, 2011-May-25) in MPC-HC, VirtualDub, PotPlayer and WMP11.

To anyone who needs/wants to keep using DirectShowSource():
first, build a functional GRF file in Graphstudio, and then, apply DirectShowSource() upon it :sly:

[manolito]

Thanks guys for your answers...

@filler56789
Funny, I did install the latest AviSynth 2.6 (not the MT version) and the problem was still there.

Otherwise yes, I do use ffdshow_rev4504_20130312_clsid, this is the version jdobbs recommends for BD-Rebuilder. And the Haali version is also the one jdobbs endorses. I cannot use lavfilters instead because AVStoDVD adjusts ffdshow settings at runtime, and I need this ability for correct audio channel assignments.

And just like hello_hello I believe that the problem lies within AviSynth, not ffdshow. As a test I configured ffdshow to exclude MPC-HC. Opening the MP4 with MPC works. Then I changed the ffdshow settings to not exclude MPC-HC. This means that MPC now uses my installed ffdshow version instead of its own DirectShow filter. Now opening the offending MP4 file with MPC also works. The ffdshow decoder is the same, the only difference is that AviSynth is not used.

What bugs me is that AviSynth does not throw an error instead of outputting garbage. Then it would be easy to handle the error and fall back on a different source filter. Right now I have to preview all sources and switch to another source filter manually when necessary.



Cheers
manolito

[hello_hello]

What bugs me is that AviSynth does not throw an error instead of outputting garbage. Then it would be easy to handle the error and fall back on a different source filter. Right now I have to preview all sources and switch to another source filter manually when necessary.

It'd probably be a case of having to check the resolution of the source video first. If the width is mod2 it'll be a problem. If it's not, it should be okay. I may have found an indication of where the problem might be, even though I don't understand it. See below....

At one stage I had a similar mod2 issue.... back when I used to do a lot of re-encoding with AutoGK by creating a script and wrapping it in an AVI. For some reason if the width was mod2 I'd get a garbled image, depending on how I opened the script, although it'd look more like a black and white image with layers of single colour which weren't "lined up".

Remembering I'd posted about the problem (http://forum.videohelp.com/threads/349335-Color-format-colorspace-question) I searched for the post, which reminded me of things I tried and completely forgotten about, but I applied the same theory to your video/script.

Forcing ffdshow to output YUY2 gets the video to display using MeGUI's preview but there's a few rows of pixels on the left which look repeated, or stretched, as though somewhere, something's trying to make it mod4.
If I try to open a script with doesn't include resizing using MPC-BE though, I get an avisynth error message regarding YUY2 images needing to be mod4 width. With mod4 resizing added to the script it displays, but once again with the same couple of rows of "stretched pixels" on the left.

Force ffdshow to output RGB and everything works as it should, but I guess that's not exactly ideal.

These days, my problem seems to be identical to yours manolito, but as you can see from the post I linked to, a year ago my ability to open DirectShow scripts with a mod2 width was dependant on how I opened them. What's changed.... well at least one full re-format and re-installation of Windows, and of course I'm using different versions of everything now from the Haali splitter up.
At the time, I was experimenting with a Divx encoded video, but it's interesting to look back and realise when I disabled ffdshow and used whatever other system decoder was installed at the time, the problem went away. Maybe a different decoder method might be worth a try.

I've got a partition which contains nothing but a clean installation of Windows. Sometime in the next day or so I might install Avisynth and try a few different flavours of ffdshow or Haali and MPC-HC to see if I can discover one which breaks things.

[Sharc]

...........
Otherwise yes, I do use ffdshow_rev4504_20130312_clsid, this is the version jdobbs recommends for BD-Rebuilder. And the Haali version is also the one jdobbs endorses. I cannot use lavfilters instead because AVStoDVD adjusts ffdshow settings at runtime, and I need this ability for correct audio channel assignments.
......

I see you need ffdshow. Still you could just disable the H.264/AVC decoder in ffdshow and leave the rest. The System should pick another decoder according to the filter merits, unless your application re-enables the ffdshow decoder.
It's a proposal for a workaround, I don't blame ffdshow, it may well be an avisynth issue. I also remember earlier problems with sizing (mod2) like the ones mentioned by hello_hello.

[manolito]

@Sharc

I did as you suggested and disabled H264 decoding in ffdshow. The funny thing was that the graph still showed the ffdshow decoder being fed by CoreAVC.

http://i41.tinypic.com/idzpjm.jpg


Next I completely uninstalled ffdshow, and now the graph looks as expected:

http://i39.tinypic.com/ht74pd.jpg


But using CoreAVC also results in the same garbled output as before...:confused:

So the problem has nothing to do with ffdshow, it is AviSynth's fault. As I said before, I tried all AviSynth versions from 2.56a up to the latest 2.60 alpha, and they all behaved identically. My system is WinXP SP3 (32 bit of course).



Cheers
manolito

[Sharc]

Hmmm ... strange indeed.
I did similar tests with your test.avs as source

a) ffdshow H.264 decoder disabled / VfW H.264 enabled:
test.avs => ffdshow Video Decoder => Video Renderer
Result: ok, not garbled

b) ffdshow H.264 Decoder enabled / VfW H.264 enabled:
test.avs => ffdshow Video Decoder => Video Renderer
Result: garbled

c) ffdshow H.264 Decoder disabled / VfW H.264 disabled
test.avs => ffdshow Video Decoder => Video Renderer
Result: ok, not garbled

d) ffdshow H.265 Decoder enabled / WfW H.264 disabled
test.avs => ffdshow Video Decoder => Video Renderer
Result: garbled

So a) and c) were ok, not garbled.
Still wondering why c) still connects to ffdshow Video Decoder :confused:

I can't produce garbage with 'test.mp4' as input. The problem comes only with the 'test.avs' script.

I am on Windows 7/64bit

[manolito]

Ok, the differences between my and your systems are that I am on XP 32bit, and I do not have the VfW part of ffdshow installed. No idea if this matters...

I did a couple of more tests in the meantime:
I installed the latest AviSynth 2.60 alpha, so nobody can tell me that I am using outdated software.
I converted the "test.mp4" to XviD AVI and also to MPEG2 keeping the frame size of 854x480.

The XviD AVI turned out garbled no matter if I used DirectShowSource or AVISource.

The MPEG2 file was OK when using DirectShowSource in the AVS script and opening the script in MPC-HC. But in AVStoDVD (after unchecking the DGIndex option so DirectShowSource was used) the output was garbled again. Very strange...:confused:


As a summary I would say that with all current versions of AviSynth trying to open an YV12 source with a non-MOD4 width using DirectShowSource (and AviSource) will result in a garbled output. The decoder (ffdshow or CoreAVC in my case) does not seem to matter. If the Windows version and/or 32/64 bit has an influence is unclear so far.

Would be nice if one of the AviSynth gurus could chime in and enlighten me...:devil:


Cheers
manolito

[hello_hello]

I using XP SP3 too.

As an experiment, because I've come across a similar oddity before, I emptied out my AVIsynth plugins folder, with the exception of DirectShowSource.dll
Unfortunately it didn't fix the mod2 problem, but all of a sudden I can open DirectShowSource scripts with MPC-HC again. I'll need to go though it systematically to find the culprit, although based on past experience one of the plugins installed by ffdshow (ffavisynth.avsi or ffavisynth.dll) will be the culprit.

It might be a long shot, but given you've now got a problem similar to the one I had a year or so ago (the ability to open mod2 scripts depends on how you open them) emptying out the plugins folder might be worth a try. Especially if uninstalling ffdshow didn't remove the ffdshow plugins.

[manolito]

For my latest round of tests I had installed the latest AviSynth 2.60 alpha, and there are only the entries in the plugins folder which come with the installation (colors_rgb.avsi, DirectShowSource.dll and TCPDeliver.dll). So I think I can rule out that any plugins in my plugin folder are to blame for the garbled output.


Cheers
manolito

[Emulgator]

manolito, what happens if you right click on the source .mp4 in your Graph Editor and select properties ?
Certain Splitters and source filters (like haali and the infamous all-purpose MS quartz.dll) are not listed visibly as separate filters,
rather under "properties" of the source file.
It may well be that a certain splitter /source filter has registered for the .mp4 and introduces this pitch offset.

Here on one of my OS (a Win7U64, 32bit chain) for a .mp4 source unexpectedly quartz.dll takes the first position as source filter, followed by Cyberlink PDVD7 MPEG-4 Splitter (from PowerDVD) and DiAVC H.264Decoder.
This directshow graph does not play.
For playback I use MPC-HC with built-in LAVFilters and let NV cuvid decode. This works. For frameserving I use DGNV.

On the very same system, 64bit chain, no source filter is visible, Haali comes into play instead of PDVD7, followed by MS DTV-DVD Video Decoder. Here the directshow graph plays.

[manolito]

When I right click on the on the source in the Graph Editor and select "Properties", all I get is the property window of the Haali Splitter. No quartz.dll . And I think the Haali splitter is supposed to appear as the first entry before the decoder.

Also this error is not restricted to mp4 files, it also occurs with XviD AVI files and MPEG2 files. It is also not restricted to DirectShowSource. When using an AviSynth version greater than 2.57 the same error also happens with AVISource.


Cheers
manolito

[Emulgator]

Even with AviSource Microsofts AVIFile handler may be used: (from AviSynth help):

AVISource ... reads in the file(s) using either the Video-for-Windows "AVIFile" interface,
or AviSynth's built-in OpenDML code (taken from VirtualDub).
This filter can read any file for which there's an AVIFile handler.
This includes not only AVI files but also WAV files, AVS (AviSynth script) files, and VDR (VirtualDub frameserver) files...

The AVISource filter examines the file to determine its type and passes it to either the AVIFile handler or the OpenDML handler as appropriate.

In case you have trouble with one or the other handler, you can also use the OpenDMLSource and AVIFileSource filters,
which force the use of one or the other handler.

Either handler can read ordinary (< 2GB) AVI files, but only the OpenDML handler can read larger AVI files,
and only the AVIFile handler can read other file types like WAV, VDR and AVS.
There is built-in support for ACM (Audio Compression Manager) audio (e.g. mp3-AVIs)...

Now you may trace this bug by using either OpenDMLSource or AVIFileSource.
If this bug stays with AVIFileSource, MS might be responsible.

Downloading your sample now...
Ah, mediainfo finds a width of 854 pixels. Not mod4.

On one of my WinXP32Pro SP3 quartz.dll is in, followed by Cyberlink MPEG-4 Splitter (PDVD7), DiAVCDecoder, Video renderer.
DS Graph not playable. The same chain can play a 720x480 (mod4) .264 elementary file encoded here using x264.
MPC-HC32 with internal LAVFilters 0.59 plays your width-non-mod4 sample.

I would point to MS quartz.dll which probably not gives correct pitch with non-mod4 resolutions for a .h264 or so file?

Here OpenDMLSource refuses to decode your .mp4, "Not a RIFF file",
AviFileSource says: "Couldn't open File"
DirectShowSource shows a solid grey window with 854x480@25.000fps.

Hm. Now checking other decoders/indexers: Both DGAVCIndex and DGAVCIndexDI deliver the same pitch offset.
Are these 854 pixels a wrong signalling, DGAVC/MS follow that, but LAV/VLC ignore 854 and assume 852 ?

[hello_hello]

I didn't have any luck finding the cause. I booted to the drive with the fresh XP installation (no software installed). Windows was installed and updated last May. I tried an older version of Haali, LAV filters and ffdshow. First using MeGUI without AVISynth installed (to be certain AVIsynth 2.6 portable was being used), then again after installing AVIsynth 2.5.8
Nothing changed. Your mod2 MP4 still opened the same way. It displayed properly when using DSS2, although for some reason when the video reached the end the player kept locking up and I had to use the three finger salute to shut it down.

I thought I'd made/kept a Windows image created after installing XP SP3, but before running Windows Update and applying the hundred or so patches and updates. I'd planned to roll back to a pre Windows Update state to see if anything changed, but unfortunately it would appear I didn't keep that image last time. I'm not sure I'm keen enough to install XP from scratch. If I'm lucky, I'll still have older images burned to disc somewhere. If I can find one tomorrow, I'll give that a shot. It wouldn't surprise me if Windows Update installed something which broke something else. One or more of the hundred updates and patches it installed last time did a number on SpeedFan.

On a brighter note.... I updated the Dither plugin along with the AVIsynth plugins it requires a few days ago, and magically my ability to open DirectShowSource scripts with MPC-HC has returned. I updated Dither on two PCs, DSS scripts open in MPC-HC on both PCs again. Aside from Dither, nothing else has changed recently. Computers.....

[manolito]

@Emulgator

Since you obviously haven't read the thread from the beginning :devil: , here is a short summary of the problem as I see it:

Only files with a non-mod4 width are affected, can be any format (AVC, ASP, MPEG2)

The decoding application (ffmpeg, Core AVC) does not matter.

It only happens from an AviSynth script. If the file is played directly in MPC-HC, everything is fine.

When invoked from an AviSynth script, only DirectShowSource and AviSource are affected. DSS2 and ffms2 both work. The DG source filters were not tested, but probably work fine.

The whole thing seems to be an AviSynth issue.

Source files with a non-mod4 width may be rare, but I recently downloaded quite a few files from YouTube with a frame size of 854x480, and I really do need to convert these files.


Playing with the filter graph has no use for me. I need to decode those source files in AVStoDVD, ffdshow and Haali are required, CoreAVC is there because I need the Apple stuff, and I don't want to install more codecs.

In the meantime there is a patch for AVStoDVD which is a workaround (not a fix for AviSynth). If a non-mod4 width is detected, AviSource and DirectShowsource are discarded and ffmpegsource2 or DSS2 are used instead.

This workaround is all I need, so for me the matter is closed...:D



Cheers
manolito

[Wilbert]

Here is a 1 minute chunk of the offending file together with the AVS script:
http://www.sendspace.com/file/sgu89u
Strange. Your script loads fine for me. I used 2.60 (a build of 5/11) (will try v2.60a5 later on, although i doubt that matters anything). You also have the latest DirectShowSource (2.6.0.1) installed? There should be a link on sourceforge, but i can't find it now. Btw, only ffdshow Video Decoder is used in my graph.

Also this error is not restricted to mp4 files, it also occurs with XviD AVI files
Could you upload a sample somewhere?

[manolito]

Hi Wilbert,

thanks for looking into this issue...:thanks:

I have uploaded some test files:
http://www.sendspace.com/file/2uesbp

//EDIT//
SendSpace has become unbearably slow lately, here is a faster link:
http://www11.zippyshare.com/v/99451192/file.html

I removed the resizer from the script and added a conversion to RGB instead to give more accurate results in VirtualDub.

This time I also tried a non-mod4 file in an FLV container, and the result really surprised me. The output was not garbled, but somehow the width had increased by ten pixels. Strange...


My DirectShowSource version is 2.5.8.8 , and this is the latest version I can use because I am stuck with AviSynth 2.57. All newer AviSynth versions are causing trouble with good old DVD2SVCD, and I cannot live without this software.

But during my tests I did install the very latest AviSynth 2.6 alpha, and I also used the latest DirectShowSource version from SourceForge. Did not fix the problems on my machine (WinXP SP3).



Cheers
manolito

[Wilbert]

I have uploaded some test files:
http://www.sendspace.com/file/2uesbp

I removed the resizer from the script and added a conversion to RGB instead to give more accurate results in VirtualDub.
Strange if I use either DSS 2.5.8.8 or 2.6.0.1 (and AviSynth 2.60a5) all files load fine (except that black borders were added for the flv file). I have WinXP SP3 too. I will try it on my laptop, but i'm not sure where to go from here.

Loading the non-mod4 avi with avisource results in garbled output too (when opening as YV12). So i will add a bugreport about that.

[manolito]

I removed the resizer from the script and added a conversion to RGB instead to give more accurate results in VirtualDub.
This was just because VDub generally complains about YV12 sources which are non-mod4. RGB sources which are non-mod4 do work.

My results are the same if I skip the RGB conversion and use
crop(2,0,-0,-0)
instead. With the exception of the FLV file all files come out garbled in VDub.


Cheers
manolito

[hello_hello]

manolito,
What about this idea if you'd prefer to use DirectShow? Or if not, maybe it's a clue as to the cause of the DirectShowSource/mod2 problem.

Enable ffdshow's Avisynth filter and add this to the script area:
Crop(0, 0, -Width % 4, -0)
Then every video you open via DirectShow will have a mod4 width, assuming ffdshow does the decoding.

Why it works, I'm not really sure, given it seemed the mod2 problem was an Avisynth one. It doesn't quite make sense that using Avisynth to crop mod2 video it's not able to handle correctly allows Avisynth to handle mod2 video correctly.....
Maybe it's an indication the problem's not actually Avisynth as such, but it's over my head. The above definitely works though.... I tested it on your mod2 MP4 sample.

PS I did find one little annoyance while playing around. When opening a video with MeGUI's script creator, it seems to pick up the aspect ratio directly from the source file which means if ffdshow crops a couple of pixels to make the video mod4, MeGUI's resize calculations are off by a tiny amount. Using a DirectShowSource script as the source video for MeGUI to open in order to create a DirectShowScript script for encoding fixed that one. :)

[manolito]

Thanks hello_hello, your workaround does work very well on my computer.

Why it works is a mystery to me, too. The non-mod4 problem looks like it is a combination of AviSynth and DirectShowSource. Each one does work by itself, but not in combination with the other.


In AVStoDVD I also get the slight aspect ratio error because the clip properties are taken from MediaInfo, but this does not worry me too much. I am more concerned with the fact that your workaround only works if ffdshow is used as the decoder.

While most AVStoDVD users probably use ffdshow, it is not required by the software if other usable DirectShow decoders are installed.

The other drawback of your method is that the crop command has a noticeable influence on speed. On my (old and slow) machine I get 8.3fps using the crop command with DirectShowSource while ffmpegsource2 gives me 9.4fps. (Source is my test.mp4, using Spline36Resize for resizing to DVD, no other filters used).

BTW there is a small typo in your crop command. The last parameter has to be "-0".


Thanks again, Happy New Year...

Cheers
manolito

[hello_hello]

BTW there is a small typo in your crop command. The last parameter has to be "-0".

Cheers, I fixed it.

Happy New Year.

[Wilbert]

The non-mod4 problem looks like it is a combination of AviSynth and DirectShowSource.
I'm not convinced of that, because it works for me fine. What version of ffdshow are you using? Try adding pixel_type = "YUY2" as a workaround.

[manolito]

Hi Wilbert,

this is getting more and more interesting. Your suggestion to add pixel_type = "YUY2" does indeed work, but it does slow down encoding, and frankly I don't understand why it works. The source is YV12, and the resulting clip is also YV12. So forcing the pixel type to YUY2 invokes two unnessecary color conversions which probably are not lossless...:confused:


My system specs again:

AviSynth 2.57 (cannot use any newer version due to compatibility reasons). DirectShowSource 2.5.8.8

ffdshow_rev4504_20130312_clsid.exe
Haali Splitter v. 1.9.42.1
These two versions are also not negotiable for me. They are the versions endorsed by jdobbs for BD-RB, and in my experience using other versions means asking for trouble.

WinXP SP3 with all current updates.


The reason why I believe that the problem lies in a combination of AviSynth and DirectShowSource is simple. When I open the offending non-mod4 file in MPC-HC, everything is fine. In this case the source file is decoded using ffdshow, but AviSynth is not used. If I open the same source in MPC-HC using an AVS script, I get garbled output. The only difference to the first case is that now AviSynth is used.

And if I open the same file through an AVS script using DSS2 or ffmpegsource2 as the source filter, everything works fine, too. So AviSynth by itself is fine, it is just the combination of AviSynth and DirectShowSource which causes trouble.


Cheers
manolito

[hello_hello]

Now I've got MPC-HC working again, the way DirectShowSource scripts open mod2 video is fairly predictable for me. With one exception, every program I've used to preview the script displays this message:

"YV12 images for output must have a width divisible by 4 (use crop)!"

If I open the same script, except one also containing mod4 resizing, there's no longer any error message and the video is garbled.

DSS2 produces the same Avisynth error in every program, unless the script itself includes mod4 resizing. If it does, the video displays as it should.

So I googled the error and after reading the comments from the Avisynth developer in this thread (http://forum.doom9.org/showthread.php?t=143991) I'm starting to think this mod2 problem is expected behaviour. Because of the restriction mentioned, Avisynth simply can't output mod2 YV12 video, so instead I assume it outputs the above error message. In RGB according to MPC-HC.
(PS Could someone please explain post #10 to me?)

So if the problem is AVIFile, I tried to find out a little more about it. According to GraphStudio, the filters AVI/WAV File Source and AVI Splitter are quartz.dll. Looking to see if we all have the same version might be somewhere to start. Mine's version 6.5.2600.6333.

At the moment VirtualDub, VirtualDubMod, MPC-HC and MPC-BE all produce the "YV12 images for output must have a width divisible by 4" error. So far the only program I've tried which doesn't is MeGUI. Instead it produces garbled video when the script is DSS and displays it properly when it's DSS2. What would it be doing differently? I'm not actually sure how it previews scripts. Anyone know what the files AvisynthWrapper.dll and devil.dll do exactly?

The million dollar question seems to be why sometimes Avisynth apparently knows it can't output mod2 and offers up the "YV12 images for output must have a width divisible by 4" error message, why other times it doesn't seem to know which results in garbled video, and why for some people (ie Wilbert) mod2 video displays fine.

[hello_hello]

PS One other thing I noticed, which may mean more to someone else than it does to me, is in the thread I linked to someone suggested trying nothing but this in a script:

ColorBars(702,576,"YV12")

Once again, all the usual programs resulted in "YV12 images for output must have a width divisible by 4 (use crop)!". Except for MeGUI. It displays the script perfectly.

[manolito]

I am very familiar with this error message from MPC-HC:
"YV12 images for output must have a width divisible by 4 (use crop)!"

But when I did what the error message requested (cropped off two pixels horizontally in the script), I did not get an error message again, but garbled output. Unless I used your method to crop off these pixels in ffdshow, then the output was fine.


Cheers
manolito

[hello_hello]

Maybe I got confused. I thought some people were successfully opening mod2 video, but maybe it's more that adding the required mod4 cropping to a script allows them to do so, while for us that's not working as it should.

The same thing happens for me when using ffmpegsource2 if the source is mod2. That surprised me, although maybe it's always been that way and I don't remember. Unlike DirectShowSource though, when mod4 cropping is added to the script it displays correctly. I do recall you being right.... at some stage mod4 cropping would fix it. I was playing around with resizing earlier, but either way it results in garbled video now.

[Guest]

Anything I can do about it? If you are not fixated on DirectShowSource() I can advise that DGDecNV seems to work fine with your sample. If you are fixated on DirectShowSource() please ignore this post.

[manolito]

Hi Don,

from one of my earlier posts:
When invoked from an AviSynth script, only DirectShowSource and AviSource are affected. DSS2 and ffms2 both work. The DG source filters were not tested, but probably work fine.

I am quite sure that all of your source filters will work on these non-mod4 sources. The problem is that AVStoDVD by MrC uses its own method to determine the most suitable source filter, and DGDecNV is not included because it is not free and because not everyone owns an NVidia graphics card.

AVStoDVD uses a routine (a2dsource.avsi) which tests source filters in the order of AVISource, DirectShowSource and ffmpegsource2. It uses the "Try...Catch" structure to jump to the next source filter if the current one issues an error message,

For this case of non-mod4 sources DirectShowSource will not throw an error, so it will be used and deliver garbage.

So nobody here is fixated on DirectShowSource(), but the author of AVStoDVD only wants to use free tools for his software.


Cheers
manolito

[Guest]

Got it. Thanks for the clarification. And have a great 2014!

[Gavino]

The million dollar question seems to be why sometimes Avisynth apparently knows it can't output mod2 and offers up the "YV12 images for output must have a width divisible by 4" error message, why other times it doesn't seem to know which results in garbled video, and why for some people (ie Wilbert) mod2 video displays fine.
There are two different ways that an application can use Avisynth to open a script and obtain video from it.

The 'normal' way is via the AVIFile interface provided by Windows. An application using this interface (eg WMP) need not even be aware that it is using Avisynth - it just sees the input as an AVI file. The AVIFile interface is limited to mod4 widths for YUV, so Avisynth reports an error if the output from the script is YUV and not mod4 when this interface is used.

The second way, used by some 'Avisynth-aware' applications, is to interface directly to Avisynth using the same API that plugins use. Using this method, there is no mod4 restriction, only the mod2 limitation that is inherent in the pixel format itself.

Most (all?) players, and VDub, use the AVIFile interface, but MeGUI and x264 use the direct method, so no error message is produced in their case.

This is independent of the garbling on input, which is a separate issue that has not yet been explained.

[Wilbert]

the "YV12 images for output must have a width divisible by 4" error
This error is unrelated to manolito's issue.

With respect to the non mod 4 avi: AviSource (i guess it should have given the same error instead of garbled output) and editors like VirtualDub use the AviFile API to open them. Ianb said the following about it:

The restriction (ie width = mod4) is in the AviFile API for YV12 that Avisynth uses to output video to the parent application. It applies equally no matter what input source you use. link (http://forum.doom9.org/archive/index.php/t-143991.html)

DSS and the like don't use the AviFile API, so it should work there (and it does for me).

Nb the intrinsic data restriction of YV12 in AviSynth is width - mod2 and height - mod4.

edit: too late ;)

[raffriff42]

This seems to work for me (using XP SP 3)
* LAV config = default
* ffdshow Video Decoder config = default except Output tab, Primary output color space = RGB32
* Avisynth, Crop(0, 0, -Width % 8, -0)

EDIT ...viewing with MPC-HC, recently updated to latest version with LAV Filters. Suspected LAV at first and disabled its h264 and mp4 handling - no change. After much trial and error, found success with the above settings.

[manolito]

Sorry to bring this up again - I thought this matter could be put to rest - but I made some new discoveries today...:rolleyes:

As a summary I would say that with all current versions of AviSynth trying to open an YV12 source with a non-MOD4 width using DirectShowSource (and AviSource) will result in a garbled output. The decoder (ffdshow or CoreAVC in my case) does not seem to matter.

I have to correct this statement. The decoder does matter. ffdshow and CoreAVC do not work for these non-mod4 sources, but the LAV video filters do work.


I was in an experimental mood today, so I uninstalled ffdshow and Haali completely. Installed the current LAV filters 0.59.1 with the default settings, and voilá, all the non-mod4 sources which previously resulted in a garbled output suddenly worked.

Great, really. But I still have some doubts if the LAV filters can completely replace ffdshow and Haali. Maybe some of the specialists can enlighten me...:devil:

First of all in AVStoDVD the LAV audio decoders did not work for mpeg2 sources with mpeg audio (MP2). The mp2 format was enabled, but I did not get any audio. Maybe an AVStoDVD issue.
//EDIT// Please disregard this. It was an AVStoDVD issue

And then there are several applications who insist that ffdshow and Haali should be used. BD-RB by jdobbs is an example, MultiAVCHD is another one. And most imporantly the ffms2 documentation states that for decoding Ogg and MPEG streams the Haali splitter must be installed.

Is this still true today, or can the LAV splitter replace Haali completely?


Cheers
manolito

[Emulgator]

Since Haali Matroska splitter forces itself too much into the driver seat (long discussions on LAV threads)
and ffdshow is not maintained too much anymore I have moved to LAV some weeks ago.
Since then no related problems came up. After all LAV derives from libav, and this derives from ffmpeg, as ffdshow did.

I guess we can safely encourage jdobbs and others to include LAV
(LAV Decoders are already in BD-RB coming from fully-patched x264)
into upcoming versions of their software.
I guess jdobbs is just about to do this, maybe only waiting for tsMuxeR to reach full maturity before making a new BD-RB 3D build.
P.S. Ah, just read it. You did suggest this to jdobbs yesterday.

And lets encourage deank for LAVSplitter too, if he ever comes back, boo-hoo....;-}
tsMuxeR has developed beautifully and is almost ready to go there for AVCHD 50p/60p / 3D as well

[manolito]

Thanks for your info...

I have been using LAV Filters only for a couple of days, but so far everything works fine (I had to enable 32-bit floating point output for audio to make the AVStoDVD preview work). The LAV splitter works better in combination with ffmpegsource2 than Haali, even if the ffms2 documentation says that Haali is needed to seek in OGG and MPEG streams.



Cheers
manolito

[hello_hello]

manolito,
I don't know if you're still around, or if you ever got to the bottom of this problem, but I discovered something today I thought I'd share. I was testing an unrelated problem I thought might be a mod2 issue, and I discovered I still had your mod2 "test.mp4" sitting in my folder of sample videos, so I gave it a try. Long story short, one thing led to another, and now I'm pretty sure the mod2 problem is caused by DirectShowSource.dll in some way.

At first I thought it was AVIsynth's fault, because when I opened your test.mp4 in MeGUI's preview, the video was garbled. So I switched MeGUI to the "installed" AviSynth, and the video looked fine. A little more experimenting showed it doesn't seem to be the flavour of AVIsynth causing the problem though, but the version of DirectShowSource.dll.

DirectShowSource.dll (unknown version). It's dated 03 Jan 2014, 83.5kb in size. It's the version included with MeGUI. Garbled mod2.
DirectShowSource.dll 2.6.0.1. It's dated 16 Jan 2013, 27kb in size. I'm pretty sure it's the version installed by AviSynth 2.6 alpha5. Garbled mod2.
DirectShowSource.dll 2.6.0.2. It's dated 13 Jan 2015, 28.5kb in size. It's the version installed by AviSynth 2.6.0.5 (RC1). Mod2 displays properly.

I get exactly the same result when opening the video via a DirectShowSource script either using MPC-HC or MeGUI's preview.

Looking back through the thread, it appears when you originally posted regarding this problem I had AviSynth 2.5.8 installed and I was experiencing the same mod2 problem opening DirectShowSource scripts using MPC-HC, which would indicate the accompanying DirectshowSource.dll is mod2 broken also.

I recall you said you're using AviSynth 2.57 and DirectShowSource 2.5.8.8. Is there an earlier version of DirectShowSource you could try, because it seems maybe every version is mod2 broken from 2.5.8.8 until the current version 2.6.0.2. Or it's some odd DirectShow/AVISynth/XP problem, or something else.....

Anyway for me, DirectShowShource.dll 2.6.0.2 with AVISynth 2.6.0.5 or AVISynth+ 2.6.0.5 and ffdshow 4533 lets me open your test file using every program I've tried without needing to crop or resize it to mod2 dimensions, except for VirtualDubMod (VirtualDub is fine). VirtualDubMod shows "VideoSourceAVI error, the image size is not acceptable" unless I crop to mod2.

As a side note, I converted the MP4 to Xvid/AVI (still 854x480) and tried AVISource without any issue with both flavours of AVISynth, except for VirtualDubMod offering the same "VideoSourceAVI error" and forcing me to crop a couple of pixels.

I'm still confused a little as to where the mod2 limitation kicks in. A year ago when I was testing (http://forum.doom9.org/showthread.php?p=1659800#post1659800) it seemed every mod2 video I tried resulted in AVISynth offering the "YV12 images for output must have a width divisible by 4 (use crop)!" error. Today I'm happily opening mod2 video with the same programs and it's displaying correctly, no error, no cropping required.

Edit: Okay so now I'm wondering if ffdshow is up to some resizing shenanigans when decoding, because looking at the original video and a version opened via an AVISynth script, the MPC-HC window looks exactly the same size, but the video opened via the script looks just a tad narrower (there's definitely no ffdshow filters enable). Either that, or none of the tested programs use the AVIFile interface any more (as per this post (http://forum.doom9.org/showthread.php?p=1659843#post1659843)). I mean, I'm not supposed to be able to open mod2 video via AVISource without cropping it to mod4 am I? I'm confused......
I might come back to this later, but enough messing around for today.

[Wilbert]

With respect to AviSource and DirectShowSource and the width mod-2 issue:

Adding a '+' to the start of the pixel_type for planar formats assumes the lines are padded DWORD aligned in memory instead of packed. This can correct skew or tearing of the decoded video. E.g AviSource("...", pixel_type="+YV12"). This problem shows up when the width of the picture is not divisible by 4.

See docs for more.

[manolito]

Thanks hello_hello for your investigation... :cool:

I have put this problem to rest in several ways. For AVStoDVD a workaround was implemented which simply checks the source width, and if it is not divisible by 4, FFMpegSource is forced instead of DirectShowSource.

For myself I solved it by using LAVFilters instead of ffdshow/Haali and replacing DirectShowSource.dll with DSS2Mod by forclip. With this configuration the problem with garbled output for sources with a non-mod4 width has completely disappeared.


Cheers
manolito

[hello_hello]

With respect to AviSource and DirectShowSource and the width mod-2 issue:

Adding a '+' to the start of the pixel_type for planar formats assumes the lines are padded DWORD aligned in memory instead of packed. This can correct skew or tearing of the decoded video. E.g AviSource("...", pixel_type="+YV12"). This problem shows up when the width of the picture is not divisible by 4.

I tried it using the DirectShowsource.dll version that comes with MeGUI (the unknown version) and it resulted in an error stating "DirecShowSource pixel type must be (insert large list of pixels formats here)" but none of them included anything with a + preceding it (AVISynth+ 2.6.0.5)

DirectShowSource.dll 2.6.0.1 caused the same error (AVISynth 2.6.0.5).
DirectShowSource.dll 2.6.0.2 didn't cause any error but the picture became garbled when previously it wasn't (AVISynth 2.6.0.5).

For some reason when I remux the original sample as an AVI it won't decode via AVISource. I just get green frames. I think that must be an ffdshow issue but rather then mess around I converted it to Xvid/Avi and used AVISource to open the new AVI.

AVISynth+ 2.6.0.5 portable opens it fine in MeGUI's preview. If I add pixel_type="+YV12" to the script I get an error instead. "AviSource requested format must be (inset long list of formats again)"

The Avisource script opens fine with MPC-HC and AviSynth 2.6.0.5, until I add pixel_type="+YV12". No error, but the picture becomes garbled when it wasn't before.


I don't know what to make of any of that, but someone else might.....

Garbled video aside, I'd still like to know why when I tried to open mod2 video a year ago via DirectShowSource, I'd pretty much always get the "YV12 images for output must have a width divisible by 4" error, but now I don't. It applied to opening scripts with VirtualDub, VirtualDubMod, MPC-HC and MPC-BE, according to my old post. At the time I was using AVISynth 2.5.8. I'm tempted to go back to it, just to see what happens.
Not that it really matters, but I'd like to understand what's going on just once every couple of years. That'd keep me happy. :)

Ah...... so if I open a mod2 AVI directly with either VirtualDub or VirtualDubmod, I get garbled (B&W) video. Okay, that's familiar. It probably makes sense.
But it seems if I open a mod2 script with VirtualDubMod it shows the "VideoSourceAVI image size error" in the status bar for any mod2 script, even one using FFVideoSource. So that's possibly something new.......
Surely I couldn't have used VirtualDubMod for years without ever having realised it won't open mod2 scripts.... surely....... surely..... but installing AVISynth 2.6.0.5 is very recent. Could they not play well together? Computers.....

[foxyshadis]

Avisynth+ hasn't been updated with the recent 2.6 changes (and may not be; they've diverged quite a bit). Regarding garbled output: You must use this ONLY when required for a specific video. Without the plus, Avisynth will open it assuming no padding; with the plus, it will open it assuming padding. No checking's done, in fact none can be done, so it just goes by whatever you tell it to do.

[hello_hello]

Some of the options above do apply to video that was garbled, but adding pixel_type="+YV12" resulted in an error.

"DirecShowSource pixel type must be (list of pixels formats here)"

I'm pretty sure the combination of DirectShowSource.dll 2.6.0.1 and AVISynth 2.6.0.5 (RC1) is an example of that.
The whole thing's a bit over my head.

[manolito]

Different topic, but still DirectShowSource related:

Is it OK to always specify the parameter "ConvertFPS = true" even if the source file is CFR? Or are there situations where this could ruin my decoding?

The reason I ask is that I recently came across an MKV with these specs:
Frame rate mode : CFR
Frame rate mode : Constant
FrameRate_Mode_Original : VFR
Frame rate : 23.976
Frame rate : 23.976 fps

Decoding this file with "ConvertFPS = false" works fine with ffdshow. But when decoding it using LAVFilters I get out-of-sync audio. Setting "ConvertFPS = true" fixes it under LAVFilters.

I have no idea if the value for FrameRate_Mode_Original is of any significance here. But since DSS2 and DSS2Mod both use "ConvertFPS = true" by default (and it cannot be disabled) I figured that I can just as well use it all the time with DirectShowSource.dll. Or is this a false assumption?


Cheers
manolito

[hello_hello]

I don't think it should do any harm. If the video is variable frame rate, it'll drop and/or duplicate frames to make it constant, otherwise it shouldn't make any difference.

MeGUI adds ConvertFPS=true to the DirectShowSource scripts it creates. Along with fps=x. Are you adding that too? Maybe it's not always required. MeGUI also adds FFMS2's frame rate conversion when creating FFVideoSource scripts.

I think it's mostly a good idea. The only time I've heard of a problem is when the source is AVI and FFVideoSource is used with it's frame rate conversion. It can sometimes cause stuttering for reasons unknown (I've duplicated that myself). FFVideoSource is fine for MKVs and I've not heard of any problems caused by DirectShow's frame rate conversion myself.

Short rant to follow ----->

AVIs with null frames seem to be handled oddly, in my opinion.
AVISource gets it right. Frames are duplicated to replace null frames and the output frame rate is what you'd expect.
I think maybe DirectShowSource doesn't do so without "ConvertFPS=true" and "fps=x", but with them the result is the same as for AVISource. I can't remember exactly.
FFMS treats it as variable frame rate but adding the appropriate fpsnum & fpsden values will produce the same result as AVISource.
L-Smash treats it as variable frame rate.
I don't know what DSS2 does.

An example of the above might be a 25fps AVI containing 500 frames including 3 null frames.
AVISource will output 25fps and 500 frames.
Without frame rate conversion the other methods would output 497 frames and something like 24.993fps.

Decoding this file with "ConvertFPS = false" works fine with ffdshow. But when decoding it using LAVFilters I get out-of-sync audio. Setting "ConvertFPS = true" fixes it under LAVFilters.

That's interesting because it means if the situation is anything like I described above, and I suspect it might be, it means ffdshow and LAV are decoding differently. Same splitter each time?
The way I understand it, if MediaInfo shows more than one aspect ratio or frame rate etc, "original" is what's written to the video stream and the other one is what's written to the container, and maybe that's causing the LAV/FFDSHOW difference, but it seems odd they behave differently. Probably LAV is outputting less frames in total without ConvertFPS=true, and chances are the frame rate is a bit off.

[manolito]

Oh my, I am embarrassed, because it's usually me who tells others to use the search button... :search:

This topic has been discussed before, here is the link:
http://forum.doom9.org/showthread.php?p=1369564#post1369564

So I will leave the option ON as my default...


Cheers
manolito

[Wilbert]

@hello_hello,

What foxyshadis said. Also the '+' is available in RC1, so you need to update AviSynth.