ffdshow tryouts project: Discussion & Development

[LoRd_MuldeR]

So the note that pops up when changing the number of decoding threads that says "mpeg1/2 decoder only" does not apply?

With ffdshow-MT the "Number of decoding threads" options applies to H.264 too :)

[rack04]

With ffdshow-MT the "Number of decoding threads" options applies to H.264 too :)

So does the MT version contain all the changes that exist in the regular version?

[LoRd_MuldeR]

Probably the video renderer switch to GDI or something slower.
By the way, in which revision does the problem start? Is it the same from the start?

Sorry for late reply, I wasn't at home last night.

I can reproduce the problem with r2250 (oldest rev on my HDD), so it may be there since Yadif was added.
Think I never noticed the problem, because I usually enforce RGB32 output, for proper TV-Levels in YUV -> RGB conversion.

The reason why I think this may be a problem on the ffdshow side (not on the renderer's side) is that it won't happen with KernelBob.
As long as RGB32 output works, it's not a big problem for me though...

[STaRGaZeR]

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

Yes, it depends on samples. And yes, Microsoft's splitter is used.
This sample is full of those glitches: http://unigine.com/download/video/Unigine_Tropics_1024x576.avi .

[MatMaul]

Yes, it depends on samples. And yes, Microsoft's splitter is used.
This sample is full of those glitches: http://unigine.com/download/video/Unigine_Tropics_1024x576.avi .
there is an audible glitch at 1mn 10s which doesn't appear with mp3lib

[clsid]

So does the MT version contain all the changes that exist in the regular version?
Most changes from the trunk are applied also applied to the MT branch. There is a delay in the updates though, it can take a few days.

[clsid]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

[tal.aloni]

Guys, please check if you can pass-through DTS-Wav, or something else which have 44100 khz frequency.

I'm not sure if it's a bug, or something with my platform.
(I can pass-through 44,100khz fine using AC3filter)

Thanks,
Tal

[ash925]

I am a bit confused about the following,when an application like megui(x264) is used to encode an avisynth script with an xvid,divx etc source does changing the settings of ffdshowz(sharpen,blur etc) in software like mpc(patched builds) have an effect on the content decoded as input for the encoder.

[clsid]

Yes, the settings in ffdshow will apply to all programs that use it for decoding.

You could make a new Profile with default settings and let that autoload based on the application exe of MeGUI.

[fastplayer]

Why does the "Apply"-button change its state from disabled to enabled every time you navigate to "DirectShow control" in ffdshow's options even though you haven't changed any setting on that page at all? I find this confusing because it suggests that I have performed - possibly unwanted - changes...

[tetsuo55]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

I saw that change, been waiting for it for some time.

Your results vary? With smooth do you mean stuttering or artifacts?

[clsid]

Here is a sample file:
http://www.matroska.org/samples/matrix/Matrix.Reloaded.Trailer-RV9-Karl640x432_HE_AAC_subtitled_chapters.mkv

This file has a FPS of 25.000, but ffdshow shows values of 12.658 and 1000.000 several times.

[STaRGaZeR]

I've been using CoreAVC to see some files unplayable with ffdshow for now (predictive lossless to be precise) and I've noticed a major difference while seeking between the two. CoreAVC never shows garbage on screen. If a frame is incomplete at the point you've specified it pauses for a few miliseconds to complete it before displaying. ffdshow doesn't do this, and it can show pixelation, wrong colors, etc. that can last for more or less time depending on the source. Is this how libav is supposed to work, or this is ffdshow's custom behaviour? Not a bug, but it's really nice to see and improves visual experience.

What do you guys think?

[LoRd_MuldeR]

I've been using CoreAVC to see some files unplayable with ffdshow for now (predictive lossless to be precise) and I've noticed a major difference while seeking between the two. CoreAVC never shows garbage on screen. If a frame is incomplete at the point you've specified it pauses for a few miliseconds to complete it before displaying. ffdshow doesn't do this, and it can show pixelation, wrong colors, etc. that can last for more or less time depending on the source. Is this how libav is supposed to work, or this is ffdshow's custom behaviour? Not a bug, but it's really nice to see and improves visual experience.

What do you guys think?

I guess if you seek to a NONE-IDR frame, then CoreAVC will go back to the previous IDR frame and decode all frames up to the current frame.
Or it waits for the next IDR frame to come. Anyways, this would explain the delay (pausing) and why the frame is displayed properly.

In contrast ffdshow/libavcodec obviously will decode the frame you throw at it. Hence you may see corrupted output after seek until the next IDR frame is reached.
But I think this also depends on the container. Usually you should never seek to a NONE-IDR frame. Doesn't happen with my MP4/MKV files at least...

[Eragon4ever]

What STaRGaZeR describes is a bug with (some) older H.264 files. http://roundup.mplayerhq.hu/roundup/ffmpeg/issue669

Assuming he is talking about a seeking issue.

[cbemoore]

I've just found a bug with DTS decoding in the latest (rev 2405) ffdshow code. I guess its either the decoder at fault, or maybe its related to the recent audio restructuring code.

My ffdshow mixer is set to 5channels+LFE, and I'm trying to play a 3-channel DTS film with Left, Center and Right channels. For some reason, the center channel being sent to my rear speakers instead of the front center. Older versions of ffdshow didn't have this issue. I haven't enabled ffdshow channel swapping, so that's not the problem.

Just to confirm the problem, I tried using S/PDIF to my receiver, and the receiver outputs correctly to the front center speaker.

Is there anything I can do to help debug the problem? I can upload a sample if you let me know where to put it.

[LoRd_MuldeR]

Thank you for finding this issue.
After fixing it at rev 2397, it looks like more general problem.

I just installed the r2407 build and I still get heavy flickering with "Greedy 2 Frame". Also the slider problem remains.

Note that it still was working fine in r2342, so it must have been broken after that revision somehow...

[STaRGaZeR]

I guess if you seek to a NONE-IDR frame, then CoreAVC will go back to the previous IDR frame and decode all frames up to the current frame.
Or it waits for the next IDR frame to come. Anyways, this would explain the delay (pausing) and why the frame is displayed properly.

In contrast ffdshow/libavcodec obviously will decode the frame you throw at it. Hence you may see corrupted output after seek until the next IDR frame is reached.
But I think this also depends on the container. Usually you should never seek to a NONE-IDR frame. Doesn't happen with my MP4/MKV files at least...

This is what I'm referring to. Would it be better to go back to the previous IDR frame to display always complete frames when seeking? In my computer CoreAVC takes miliseconds, I can see it but it's miles better than having several seconds of corrupted image due to a large section without an IDR frame. Oh and it does happen with MP4/MKV too.

[LoRd_MuldeR]

Oh and it does happen with MP4/MKV too.

Can't see corrputed image when seeking in H.264 files (MKV or MP4), using MPC-HC + HaaliMediaSplitter + ffdshow-MT :confused:

Does it happen with all files or specific ones only?

[STaRGaZeR]

Can't see corrputed image when seeking in H.264 files (MKV or MP4), using MPC-HC + HaaliMediaSplitter + ffdshow-MT :confused:

Does it happen with all files or specific ones only?

All files in general, with your same configuration. In some of those files it's almost not noticeable though. And by the way the MT branch has this bloking issue even more noticeable in my experience.

Eragon4ever, we're talking about the same thing. But it is not related to only one file or stream.

[Ryokurin]

This may be a stupid question, but I'm missing where the mt versions are located, or are they not generally available yet?

[LoRd_MuldeR]

This may be a stupid question, but I'm missing where the mt versions are located, or are they not generally available yet?

Builds are available here, for example:
http://www.xvidvideo.ru/content/category/1/40/30/

[rack04]

That explains the "small" speed-up between ffdshow and ffdshow-MT. On a Quadcore you'd see a bigger difference :cool:

ffdshow-MT, svn 2407 (4 Threads)
User: 9s, kernel: 0s, total: 9s, real: 23s, fps: 384.7, dfps: 165.1

ffdshow, svn 2399 (4 Threads)
User: 51s, kernel: 0s, total: 51s, real: 55s, fps: 75.0, dfps: 68.6

ffdshow-MT, svn 2407 (2 Threads)
User: 5s, kernel: 0s, total: 6s, real: 40s, fps: 636.2, dfps: 94.7

ffdshow, svn 2399 (2 Threads)
User: 51s, kernel: 0s, total: 51s, real: 59s, fps: 74.6, dfps: 64.1

[Anima123]

Support for RealVideo4 (RV40) has been added at revision 2405. It works reasonably well with the few files I tried. Although not everything plays as smooth as it should. And no, I don't know how to fix that.

Though it's not really usable at this stage, this makes people to get more expectation on RV decoding. Thanks ffdshow devs and thanks Kostya who write the original code without specifications of RV format.

[whurlston]

Where can I find a list of the GUIDs for accepted pin connections for TrueHD and DTS-HD?

[LoRd_MuldeR]

ffdshow-MT, svn 2407 (4 Threads)
User: 9s, kernel: 0s, total: 9s, real: 23s, fps: 384.7, dfps: 165.1

ffdshow, svn 2399 (4 Threads)
User: 51s, kernel: 0s, total: 51s, real: 55s, fps: 75.0, dfps: 68.6

ffdshow-MT, svn 2407 (2 Threads)
User: 5s, kernel: 0s, total: 6s, real: 40s, fps: 636.2, dfps: 94.7

ffdshow, svn 2399 (2 Threads)
User: 51s, kernel: 0s, total: 51s, real: 59s, fps: 74.6, dfps: 64.1

The difference between 2 threads and 4 threads in ffdshow r2399 can be explained with inaccurateness of the test.
It never uses more than two threads for H.264, results should be the same.

The difference between ffdshow and ffdshow-MT is as expected:
147% speed with 2 threads and 257% speed with 4 threads (compared to ffdshow r2399).

[haruhiko_yamagata]

@developers,
when I fixed the Grab filter related Color Space conversion issue, I noticed that there were some major inconsistencies regarding the RGB colorspace. the FF_CSP_ enum is referring to how the bytes are stored in memory, which is the opposite of the writing order under x86 architecture (little endians).
we work with many libraries, some use the write order(libmplayer), and some use the "byte order" (ffmpeg).

(also, when writing to files, the write order equals to the "byte order", which makes things even more confusing)
it's hard to decide what's right to do in this case, because in any way, our enum will appear to be erroneous,

I made a patch that I think will make the code more clear,
I guess future work should be done (comments etc.),
I would like to hear what you think, and if you have a better suggestion.

http://iknowu.net/files/public/ffdshow/2401-LittleEndian.patch

Tal

to summerize, I replaced the FF_CSP_RGB?? in the enum with FF_CSP_BGR?? and vice versa, and defined the following: (I also replaced the FF_CSP_????? in the rest of the code, to match the appropriate values)

#define FF_CSP_RGB15_LITTLE_ENDIAN FF_CSP_BGR15
#define FF_CSP_RGB16_LITTLE_ENDIAN FF_CSP_BGR16
#define FF_CSP_RGB24_LITTLE_ENDIAN FF_CSP_BGR24
#define FF_CSP_RGB32_LITTLE_ENDIAN FF_CSP_BGR32
#define FF_CSP_BGR15_LITTLE_ENDIAN FF_CSP_RGB15
#define FF_CSP_BGR16_LITTLE_ENDIAN FF_CSP_RGB16
#define FF_CSP_BGR24_LITTLE_ENDIAN FF_CSP_RGB24
#define FF_CSP_BGR32_LITTLE_ENDIAN FF_CSP_RGB32

Sorry for late reply. I've been too confused to reply...
I'm still confused, but I prefer to call it after how it is ordered in memory.
I would prefer just adding comment how it should look like in memory and register.
Updating libswscale is still in mess in the ffmpeg-mt branch, so minimal change is convenient for me.

[haruhiko_yamagata]

All files in general, with your same configuration. In some of those files it's almost not noticeable though. And by the way the MT branch has this bloking issue even more noticeable in my experience.

Eragon4ever, we're talking about the same thing. But it is not related to only one file or stream.
I know seek is somewhat broken. ffmpeg-mt branch is more broken, or it's not even implemented.
ffdshow has the

@LoRd_MuldeR
premiere-paff.ts reproduce the problem.

[haruhiko_yamagata]

What STaRGaZeR describes is a bug with (some) older H.264 files. http://roundup.mplayerhq.hu/roundup/ffmpeg/issue669

Assuming he is talking about a seeking issue.
Without looking at this file, i think the solution is to implement parsing of the SEI that tells one at what point the decoded data is correct after seeking (random access).

ffdshow decode the SEI, but still show the problem. Even if I disable allowing I frame as an entry point. IDR and GDR should be OK as an entry point.
As Dark Shikari pointed, it looks like a regression bug of libavcodec.

[LoRd_MuldeR]

@LoRd_MuldeR
premiere-paff.ts reproduce the problem.

Because it's TS and hence we may seek to None-IDR frames, maybe? :confused:

[haruhiko_yamagata]

Because it's TS and hence we may seek to None-IDR frames, maybe? :confused:
TS file has IDR and GDR flags (SEI message). Seeking should work.

[haruhiko_yamagata]

Sorry for late reply, I wasn't at home last night.

I can reproduce the problem with r2250 (oldest rev on my HDD), so it may be there since Yadif was added.
Think I never noticed the problem, because I usually enforce RGB32 output, for proper TV-Levels in YUV -> RGB conversion.

The reason why I think this may be a problem on the ffdshow side (not on the renderer's side) is that it won't happen with KernelBob.
As long as RGB32 output works, it's not a big problem for me though...Does it work if Fizick's AviSynth-yadif is enabled in ffdshow?

[tal.aloni]

Sorry for late reply. I've been too confused to reply...
I'm still confused, but I prefer to call it after how it is ordered in memory.
I would prefer just adding comment how it should look like in memory and register.

I know what you mean about being confused :)

OK, I will add comments.
and OK, we'll call it after how it is ordered in memory.

how about adding a _WRITE_ORDER definitions for the PNG / BMP saving part?
(and maybe for the interaction with libmplayer as well)


#define FF_CSP_RGB24_WRITE_ORDER FF_CSP_BGR24
#define FF_CSP_BGR24_WRITE_ORDER FF_CSP_RGB24


(I would like other developers to donate their opinion too)

p.s. I'm not going to touch libswscale, this is internal representation only.

Tal

[LoRd_MuldeR]

TS file has IDR and GDR flags (SEI message). Seeking should work.

Maybe the TS parser/splitter is at fault, sending a None-IDR frame to the decoder after seeking? :confused:

Does it work if Fizick's AviSynth-yadif is enabled in ffdshow?

Yup. Just gave it a try. No "slow motion" problem with the Avisynth version of Yadif and "YV12,adj" output.
But it's back as soon as I switch to internal Yadif ...

[haruhiko_yamagata]

Maybe the TS parser/splitter is at fault, sending a None-IDR frame to the decoder after seeking? :confused:
The splitters may start sending at any random frame. Decoders has to drop frames until the first IDR or GDR arrives.
ffdshow does this correctly, though I'm not sure if I haven't bugged.

[LoRd_MuldeR]

Yup. Just gave it a try. No "slow motion" problem with the Avisynth version of Yadif and "YV12,adj" output.
But it's back as soon as I switch to internal Yadif ...

Now I'm completely confused!

All of a sudden the "slow down" also happens with RGB32 output and with both, internal Yadif -and- Avisynth Yadif. Why? It did work all the time :confused:
But I still doesn't happen with KernelBob. This all makes me believe DVBViewer is totally borked, showing random behavior...

:(

[ash925]

@clsid:thnx

[Keepitsimple]

lord_mulder, Is there an alternative to dvbviewer? Ie opensource dvb viewing.

[LoRd_MuldeR]

lord_mulder, Is there an alternative to dvbviewer? Ie opensource dvb viewing.

There are many DVB applications. But my Technisat card ships with a special edition of DVBViewer and other apps don't recognize my card (using the standard drivers).

I know there are alternative drivers (BDA) available that should make the card work with other apps, but so far DVBViewer works fairly good for me.

[Snowknight26]

In r2314, if DTS is set to libavcodec and DTS is checked under Output -> pass-through, files with DTS don't play. Works fine with libdts though.

[tal.aloni]

In r2314, if DTS is set to libavcodec and DTS is checked under Output -> pass-through, files with DTS don't play. Works fine with libdts though.

Works fine here (2407). maybe it's related to problematic file?
EDIT:
when DTS-passthrough is checked, libavcodec is not being used (if the file can be passed through),
so can I assume the file cannot be passed through? is it DTS-HD?

[KoD]

@KoD, I generally don't use ffdshow's installer, so that's why I didn't notice it. I have fixed the install script.
Thank you for doing it. Sorry for being a little rude.

[KoD]

I can't reproduce. Is it hard to hear? Does it depend on samples?
I think Microsoft's AVI splitter is used.

Yes, it depends on samples. And these glicthes sometimes don't happen if you seek in the file. But the glitches happen if you let the file play from the start without seeking in it.

Since a mp3 sample was posted, here is a mpeg1 audio layer 2 sample in a mpg. There are some glitches after 2 minutes 10 seconds or so in the video with libavcodec, but not with mp3lib. Microsoft's mpeg splitter is used.

http://www.mediafire.com/?myzzynzj2za

[haruhiko_yamagata]

Yes, it depends on samples. And these glicthes sometimes don't happen if you seek in the file. But the glitches happen if you let the file play from the start without seeking in it.

Since a mp3 sample was posted, here is a mpeg1 audio layer 2 sample in a mpg. There are some glitches after 2 minutes 10 seconds or so in the video with libavcodec, but not with mp3lib. Microsoft's mpeg splitter is used.

http://www.mediafire.com/?myzzynzj2za
Thanks, I hope the latest svn is OK.

[haruhiko_yamagata]

Subtitles still bad. (See previous post).


http://img175.imageshack.us/img175/9320/subsny9.jpg

@albain:Please respond or I will revert rev 2270.
I have tried to fix but it's hard.

[haruhiko_yamagata]

I know what you mean about being confused :)

OK, I will add comments.
and OK, we'll call it after how it is ordered in memory.

how about adding a _WRITE_ORDER definitions for the PNG / BMP saving part?
(and maybe for the interaction with libmplayer as well)


#define FF_CSP_RGB24_WRITE_ORDER FF_CSP_BGR24
#define FF_CSP_BGR24_WRITE_ORDER FF_CSP_RGB24


(I would like other developers to donate their opinion too)

p.s. I'm not going to touch libswscale, this is internal representation only.

Tal
Personally, it's more confusing for me.
Once we decided to call it after how it is ordered in memory, we can remember it. Please add some comment to PNG and BMP conversion part.

[Reimar]

Personally, it's more confusing for me.
Once we decided to call it after how it is ordered in memory, we can remember it. Please add some comment to PNG and BMP conversion part.

Just to explain why it is in FFmpeg the way it is: calling it "after how it is ordered in memory" works really badly for the 16, 15 and 8 bit RGB/BGR formats (same for the 10 bit/component formats except FFmpeg does not support them yet).

[Snowknight26]

Works fine here (2407). maybe it's related to problematic file?
EDIT:
when DTS-passthrough is checked, libavcodec is not being used (if the file can be passed through),
so can I assume the file cannot be passed through? is it DTS-HD?

No its not DTS-HD, but yes it could be passed through because as soon as I switched the decoder to libdts it would pass-through just fine.

[nlnl]

Can we do inverse telicine + deinterlace transformation in ffdshow for film source (29i (film) -> 24p) ?
Thank you.