ffdshow tryouts project: Discussion & Development

[clsid]

Can't you also add detection of the "AVI splitter" filter so no filename check is needed at all?

[haruhiko_yamagata]

Originally Posted by clsid

Can't you also add detection of the "AVI splitter" filter so no filename check is needed at all?

There are several AVI splitters that are familiar to us and there may be some other AVI splitters.

[ipanema]

If it is a file, please set file name in FILTER_INFO::achName. But if it is a live stream, it does not have file name and extension.

Now ffdshow parses access units if the file name extension is NULL.

I'm a little confused by your explanation. If ffdshow parses access units if the file extension is NULL, then this seems to be what I need because the stream I deliver does have 00 00 00 01 09 sequences, and they MAY occur in the middle of a directshow sample.

Does that mean I can just hard code FILTER_INFO::achName to be something like

"dummy"

This has no file extension, and it sounds like ffdshow does not need to know the actual filename - it is just looking for the absence or presence of a filename extension.

This would seem to be safer than specifying the full pathname of the file with its extension because I don't know what specific filename extensions ffdshow might be checking for - it might do different things depending on the filename extension.

Also do you mean that "Now ffdshow parses access units if the file name extension is NULL" has already been implemented or that it will be implemented in a future revision?

How are you reading the FILTER_INFO::achName ? Are you just getting the upstream filter and calling QueryFilterInfo() on it? I ask because you said a a while back that you would need the filter GUID, but I think you can get the upstream filter without having to know its GUID in advance via IPin::QueryPinInfo() on the upstream connected pin.

[haruhiko_yamagata]

Originally Posted by ipanema

I'm a little confused by your explanation. If ffdshow parses access units if the file extension is NULL, then this seems to be what I need because the stream I deliver does have 00 00 00 01 09 sequences, and they MAY occur in the middle of a directshow sample.

Does that mean I can just hard code FILTER_INFO::achName to be something like

"dummy"

This has no file extension, and it sounds like ffdshow does not need to know the actual filename - it is just looking for the absence or presence of a filename extension.

If you want to support current and older (say, beta 6) ffdshow, please use "dummy.ts".

This would seem to be safer than specifying the full pathname of the file with its extension because I don't know what specific filename extensions ffdshow might be checking for - it might do different things depending on the filename extension.

Current ffdshow (not my local working copy) compare extension with
ts, m2ts, m2t, mts, mpg, mpeg.
So it's safe to specify Drive:\path\filename\extension.

The new version will compare extension with avi.

Also do you mean that "Now ffdshow parses access units if the file name extension is NULL" has already been implemented or that it will be implemented in a future revision?

In the near future, this week probably.

How are you reading the FILTER_INFO::achName ? Are you just getting the upstream filter and calling QueryFilterInfo() on it?

Yes.

I ask because you said a a while back that you would need the filter GUID, but I think you can get the upstream filter without having to know its GUID in advance.

I don't seem to require your filter's GUID for now, but I required NeuviewSource's GUID for the workaround.

[ipanema]

The upstream filter from the ffdshow filter is the MPEG-2 demux, so I set the FILTER_INFO::achName of the demux and also of my source filter by calling AddFilter specifying a filter name ending in ".ts" - for example:

m_pGraph->AddFilter(pDemux, L"Demux.ts");

Unfortunately this makes no difference. The Source File is still shown as blank and the decoded frames are still corrupted.

I'm setting up the media type WITH the dwSequenceHeader (SPS and PPS) and the main media type structure set as posted earlier.

P.S. I'v just tried to query the achName of the Demux from my source filter (the opposite direction to which you'll be looking from the ffdshow filter) using the following code:

CComPtr <IPin> nDemuxInPin;
pSourceOutPin->ConnectedTo(&nDemuxInPin);
PIN_INFO pininfo;
nDemuxInPin->QueryPinInfo(&pininfo);
CComPtr <IBaseFilter> pDemuxFilter = pininfo.pFilter;
FILTER_INFO filterinfo;
pDemuxFilter->QueryFilterInfo(&filterinfo);

and the filterinfo.achName does indeed read "Demux.ts"

[haruhiko_yamagata]

Originally Posted by ipanema

The upstream filter from the ffdshow filter is the MPEG-2 demux, so I set the FILTER_INFO::achName of the demux and also of my source filter by calling AddFilter specifying a filter name ending in ".ts" - for example:

m_pGraph->AddFilter(pDemux, L"Demux.ts");

Unfortunately this makes no difference. The Source File is still shown as blank and the decoded frames are still corrupted.

I'm setting up the media type WITH the dwSequenceHeader (SPS and PPS) and the main media type structure set as posted earlier.

P.S. I'v just tried to query the achName of the Demux from my source filter (the opposite direction to which you'll be looking from the ffdshow filter) using the following code:

CComPtr <IPin> nDemuxInPin;
pSourceOutPin->ConnectedTo(&nDemuxInPin);
PIN_INFO pininfo;
nDemuxInPin->QueryPinInfo(&pininfo);
CComPtr <IBaseFilter> pDemuxFilter = pininfo.pFilter;
FILTER_INFO filterinfo;
pDemuxFilter->QueryFilterInfo(&filterinfo);

and the filterinfo.achName does indeed read "Demux.ts"

Sorry, I found ffdshow is using IFileSourceFilter::GetCurfile.
ffdshow searches to the upper stream and find the source filter.

const char_t* TinputPin::getFileSourceName(void)
{
 IFilterGraph *graph=m_pFilter->GetFilterGraph();
 if (!graph || wasGetSourceName || !filesourceFlnm.empty())
  return filesourceFlnm.c_str();
 wasGetSourceName=true;
 comptr<IBaseFilter> filter;
 if (searchPrevNextFilter(PINDIR_INPUT,this,this,&filter,TpinFileSourceComp()) && filter)
  {
   comptr<IFileSourceFilter> ifsf;filter->QueryInterface(IID_IFileSourceFilter,(void**)&ifsf);
   LPOLESTR aviNameL=NULL;
   ifsf->GetCurFile(&aviNameL,NULL);
   if (aviNameL)
    {
     filesourceFlnm = text<char_t>(aviNameL);
     CoTaskMemFree(aviNameL);
    }
   else
    filesourceFlnm=_l("");
  }
 return filesourceFlnm.c_str();
}

struct TpinFileSourceComp
{
 bool operator ()(IBaseFilter *bff,IPin*) const
  {
   comptr<IFileSourceFilter> ifsf=NULL;
   return SUCCEEDED(bff->QueryInterface(IID_IFileSourceFilter,(void**)&ifsf)) && ifsf!=NULL;
  }
};

Please implement IFileSourceFilter.
Thank you for your consideration of this matter.

[ipanema]

Haruhiko, that works fine now.

Thankyou for looking into this.

"Now ffdshow parses access units if the file name extension is NULL"

By NULL do you just mean a filename without an extension - e.g. "myfile" or "myfile." ?

[haruhiko_yamagata]

Originally Posted by ipanema

Haruhiko, that works fine now.

Thankyou for looking into this.



By NULL do you just mean a filename without an extension - e.g. "myfile" or "myfile." ?

Yes, ffdshow parses access units if the file name does not have extension or IFileSourceFilter is not implemented.

[ipanema]

Now that this seems to be working, here's an observation.

Most of the time ffdshow does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It does seem to do this most of the time at the start of a file but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are not decoded (as if it was an open GOP). But Mainconcept always seems to decode the 2 preceeding B frames no matter which I-frame in the file you start streaming from (as if all GOPs were closed).

Do you know what flags in the stream the ffdshow's H.264 decoder is using to decide not to decode the 2 leading B frames? And is it making a mistake? If Mainconcept can perfectly decode these B frames OK then surely ffdshow should be able to aswell.

[therealjoeblow]

Originally Posted by clsid

Improving AutoCrop before releasing beta 7 would be nice. But since it was broken before, not a requirement.

I'm not sure if it's even possible so please forgive me if not, but if anyone's going to be working on AutoCrop, what I've been longing for is for AutoCrop to be able to determine the actual image's height (I believe in the same standard way it currently does), and then crop the sides off to as close to a true 16:9 image as it can (a modification to the code would be necessary for this variation).

The reason is that I have a plasma display used exclusively for movies, and to avoid uneven screen wear and potential burn-in, I don't want the black-bars displayed on 2.35:1 or anything wider than 16:9. Right now I use ZoomPlayer to manually zoom the image for extra-widescreen movies, but it's not automatic. Having a variation of AutoCrop that could do it automatically would be great if possible!

[Komano]

Hello Guys, I have been having problems with S/PDIF and if you need me to test the S/PDIF Fixes, i can help. PM me or something?

[Snowknight26]

There appears to be a bug in libavcodec where FRAPS videos have the right-most 16 pixels a different level, or so it appears. Doesn't happen when using decoder that comes with FRAPS but does with libavcodec.

Sample source: http://stfcc.org/misc/epiczip.zip (disregard the other files)
Sample encode from source using libavcodec: http://stfcc.org/misc/fraps.libavcodec.mkv

[Casshern]

Hi,

the Dolby Tru HD decoder works well with the latest releases. Also nice is that when you turn it off, ffdshow extracts the ac3 core and sends that over sp-dif. So far, so good. But some Dolby Tru HD tracks lack an ac3 core. In this case the preferred behaviour would be:
1) If ac3 core of a dolby tru hd track is available send that over sp-dif
2) if ac3 core is not available use the dolby tru had decoder

All that would be required would be an option on the dolby tru hd decoder like "Only use if no ac3 core is detected"

The reason for all this is, that many people got receivers only supporting ac3 and dts. Here it is nicer to have the ac3 core, than to decode and reencode or even than to use the analog outs.

[Gleb Egorych]

Originally Posted by Gleb Egorych

There is a problem with ffdshow and DVBViewer. Looks like a bug in DVBViewer source filter that confuses ffdshow (from beta6 to r3004).

On mono channels (MPEG2 video + MP2 audio) with DVBViewer I had no sound, so I made a discovery and supposed that DVBViewer sent wrong channel number to decoder.
I tested all available options for MP2 decoding, here are the results:

libmad: detects input as stereo and gives no output, info page is blank.
mp3lib: detects input as stereo and outputs as stereo.
libavcodec: detects input as mono and outputs as mono.

Looks like libavcodec is the most foolproof, but by default libmad is used for MP2. So I believe libmad has higher quality (?).

It can be fixed within DVBViewer, the option is called "TV/Radio Pre-Format Detection".

[Gleb Egorych]

Question about presets:
I tried to setup ffdshow specially for ReClock, made a preset with autoloading condition "on a DirectShow filter presence"="ReClock Audio Renderer", but ffdshow all the same uses default preset. Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?

Using rev2940

[Leak]

Originally Posted by Gleb Egorych

Question about presets:
I tried to setup ffdshow specially for ReClock, made a preset with autoloading condition "on a DirectShow filter presence"="ReClock Audio Renderer", but ffdshow all the same uses default preset. Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?

Yes, as autoloading conditions are only checked when ffdshow is inserted into the graph, which usually happens before audio and renderer filters are added.

[leeperry]

Originally Posted by Gleb Egorych

Also tried "*ReClock*" with no luck. Does the condition work only for filters before ffdshow?

you'd be better off using one specific player for Reclock and make a ffdshow preset depending on its .exe name

[Gleb Egorych]

Originally Posted by Leak

Yes, as autoloading conditions are only checked when ffdshow is inserted into the graph, which usually happens before audio and renderer filters are added.

Maybe this behaviour should be changed (if possible). Strange situation: filter exists, name is correct, rule does not work.

Originally Posted by leeperry

you'd be better one using one specific player for Reclock and make a ffdshow preset depending on its .exe name

Already done, it was the only option. Now I have mplayerc_rc.exe with mplayerc_rc.ini for ReClock.

[haruhiko_yamagata]

Originally Posted by Snowknight26

There appears to be a bug in libavcodec where FRAPS videos have the right-most 16 pixels a different level, or so it appears. Doesn't happen when using decoder that comes with FRAPS but does with libavcodec.

Sample source: http://stfcc.org/misc/epiczip.zip (disregard the other files)
Sample encode from source using libavcodec: http://stfcc.org/misc/fraps.libavcodec.mkv

ffplay has the same issue. Please report it directly to FFmpeg.

[haruhiko_yamagata]

Originally Posted by ipanema

Now that this seems to be working, here's an observation.

Most of the time ffdshow does not seem to decode the 2 B frames that preceed the first I frame (in presentation order) in the stream. It does seem to do this most of the time at the start of a file but if you start streaming data from an I-frame located elsewhere in a file then the 2 preceding B frames are not decoded (as if it was an open GOP). But Mainconcept always seems to decode the 2 preceeding B frames no matter which I-frame in the file you start streaming from (as if all GOPs were closed).

Do you know what flags in the stream the ffdshow's H.264 decoder is using to decide not to decode the 2 leading B frames? And is it making a mistake? If Mainconcept can perfectly decode these B frames OK then surely ffdshow should be able to aswell.

They are simply dropped without any flags. It's a bug then. I'll re-read the spec and think about the fix.