ffdshow or ConvertToYV12

[drob]

What would give me better speed and/or quality, using ffdshow as a directshow source, or adding the ConvertToYV12 line to my avs and letting windows decode it for me?

[IanB]

Best is not to do unnecessary format changes. Most but not all video compressions are based on YV12 internally. Many decoding codec can be asked to convert to another format as required by the application.e.g. RGB or YUY2. Some do it unconditionally.

If the Avisynth source format is not already YV12, then you should endeavour to find out why. Is there an undesired conversion being defaulted for the codec, e.g Quicktime. Is the internal format not YV12 after all, e.g DV.

Sometimes you do not have a choice, e.g. the old panasonic DV codec would always do RGB24. In these cases you will need to use ConvertToYV12() or let the encoder do the conversion internally or find a better codec.

Also for display ultimately you will have to have RGB format. So if a codec cannot be convinced to give native YV12 maybe you should leave it, the alternative is an extra pair of unwanted format conversions in the full path.

Bottom line is it is best to convince the decoder to give the require format. If you cannot and you must have YV12 then you may as well use ConvertToYV12(), it is fast and does a pretty good job.

[drob]

Thank you for your great explenation, i am actually starting to think this is a mwrong detection by Megui which led me to think my video wasnt in YV12, doing some reading i now understand that if mediainfo present my file as:

Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits

It comes together to the YV12 representation.

However avisynth (info()) detects it as YUY2, so i guess this is why Megui asked me to add the ConvertToYV12 line.
Am i worng in this understanding?

[Gavino]

However avisynth (info()) detects it as YUY2, so i guess this is why Megui asked me to add the ConvertToYV12 line.
That tells you it is the used codec that is doing the conversion from YV12 to YUY2, so you need to investigate the reason for that, as IanB suggested.

[drob]

To try and exclude codecs installed by other applications on my system, I did some testing on a clean virtual machine Windows 7 32bit and 64bit, all produce YUY2 color space, could it be that this is the default DirectShow color space for Windows 7?

[Gavino]

What format is your video?
Use the MediaInfo and GSpot utilities to get information about it.
(If you don't know about these tools, use Google to search for them).

GSpot's "Proposed codec solutions and tests" section can provide insight into which codecs are used to access the file.
Another helpful tool is GraphEdit.

[IanB]

@drob,

You have not actually stated the source filter you are using in your script.

AviSource() formally requests in order YV12, YUY2, RGB32 then RGB24. If YUY2 is being returned then the request for YV12 explicitly failed.

DirectShowSource() accepts the first bid of a compatible format from the set YV12, YUY2, ARGB32, RGB32, RGB24. No order is imposed. If YUY2 is being returned it was the first type bid by the upstream filter.

You can restrict the selection by specifying the pixel_type option, e.g. DirectShowSource("foo.avi", pixel_type="YV12")

Specifying the pixel_type option also enables the DirectShow IEnumMediaTypes interface, which allows the upstream filter to evaluate the acceptable media types. The enumeration order of the types is YV12, YUY2, ARGB32, RGB32 then RGB24. Theoretically filters are supposed to bid formats they support in that order.

You can specify "YUV" = (yv12+yuy2), "RGB" = (argb+rgb32+rgb24) or "AUTO" = (all) to enable some or all of the acceptable media types as well as a single media type.

[drob]

Sorry for giving partial information and thanks for your help,
I am using directshowsource, with the 2.588 fix, when i try the pixel_type="auto" argument, i still get YUY2, when i replace it with"YV12" i get this error: directshowsource render fie, the filter graph manager wont talk to me.

[IanB]

It's pretty obvious then, the DirectShow components you are using do not support YV12 only YUY2. This is not that uncommon.

Use Graphedit with a default render file to see what the default graph looks like and what components are being used.

[drob]

According to graphstudio it uses Microsoft DTV-DVD Video Decoder filter, which according to its properties does support YV12 as a 3rd option (NV12-YUY2-YV12).

From what i understand i am better off going with indexing the file then feeding it into avisynth. for direct full clip H264 source encoding, would i be better off using ffms2 or dgavcindex? they both give me Yv12 without any hassle.

[IanB]

The "DirectShowSource: RenderFile, the filter graph manager won't talk to me" error is the catch all when the default rendered filter graph does not connect to the get_sample input pin but returned no other error. This possibly means the YV12 support is broken in some form. If you want to follow this further submit 2 DirectShowSource logfiles, one for working pixel_type="YUY2" and one for not working pixel_type="YV12". Use the logmask=-1 and logfile="file.log" options.


DGAvcIndex has been withdrawn and is no longer supported. If the version you have works, fine.

Ffms2 is constantly under development. H.264 support is occasionally a casualty. If the version you have works, fine.

[drob]

Here are the logs attached.
Both versions of the indexers are the one with the MeGUI package so they do work, my question is if there is any priorities to using the DirectShowSource source over the indexing methods, or is one of the indexing methods better then the other.

[IanB]

The relevant part of the yv12 log.00:00:00.234 001 0x00A5FE20 0x00000698 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.234 001 0x00A5FE20 0x00000698 *** Video: format accepted: 1920x1080, pixel_type a0000008, avg_time_per_frame 333667x100ns // a0000008 = YV12
00:00:00.234 001 0x00A5FE20 0x00000698 *** Video: bFixedSizeSamples=1, bTemporalCompression=0, lSampleSize=3110400
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::ReceiveConnection(0x00a5da44, pmt)
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::QueryPinInfo() 0x00a5fe20
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::QueryFilterInfo()
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::QueryInterface({0000010c-0000-0000-c000-000000000046}, ppv)
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::GetClassID() E_NOTIMPL
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::QueryInterface({fa993888-4383-415a-a930-dd472a8cf6f7}, ppv) ** E_NOINTERFACE ** // IMFGetService
00:00:00.234 008 0x00A5FE20 0x00000698 GetSample::Disconnect()Summary :- Connects to pin as YV12
Gets Pin info, ok
Gets filter info, ok
Get IPersist interface, ok
Tries for a permanent ClassID, fails
Tries for IMFGetService interface, fail
Spits dummy and disconnectsThe IMFGetService is the entry to all the wonderful new Vista/W7 GPU based enhanced display renderer crap, including all that nice new extra DRM.

The YUY2 path also tries for the IMFGetService interface but soldiers on trying for IVMRVideoStreamControl and IVMRVideoStreamControl9 before finally just getting on with the job.

Looks like your decoder will only talk YV12 to something that supports all that wonderful DRM.



As for the other import technologies, when they work correctly they are effectively identical.

[drob]

God bless MS DRM Mess.

Thank you for all your help, so buttom line for me and others who would fine this thread, list of priorities is:
Indexing(1.FFMS2 2.DGAvcIndex)
directshowsource using FFDShow (CoreAVC & so on)
ConvertToYV12