ffdshow tryouts project: Discussion & Development

[Elbart_]

Originally Posted by tal.aloni

it will again with 3195+

Yes, with 3200, ffmpeg-mt works again. Thanks to devs and helpers!

[deets]

Originally Posted by CiNcH

Seems both, H.264 and VC-1 DXVA decoders, have no NALU/Access Unit parser, so they expect the source/splitter/demuxer filter to deliver exactly one NALU/Access Unit per MediaSample.

this being the same reason we cant use MPC DXVA for live streams either?

[clsid]

The normal ffdshow decoder is also lacking a full parser for access units.

[Ger]

Perhaps, but whatever haruhiko added in 2008 when he worked with CiNcH & co was enough to make the ffdshow software decoder work well with live DVB streams.

We (DVB users) have been hoping that Casimir would add this to the MPC-HC DXVA decoder for a while, like haruhiko did for the ffdshow software part. But if albain could add this to ffdshow's DXVA decoder (would be very much appreciated) then I think it would be possible to use ffdshow for most/all DVB channels/streams. At least for video.

For audio (separate issue) I don't think LATM encapsulated HE-AAC is suported in ffdshow. Not the most common format in DVB streams, but it's used in some countries like Norway and New Zealand. ffdshow doesn't show up as an option for AAC decoder in DVBViewer, and neither the Haali nor the Gabest/MPC-HC TS splitter seems to ID the audio track correctly. Monogram AAC decoder + DVBViewer works fine, as does VLC. I can provide a sample TS recording AVC + LATM/HE-AAC from Norwegian DVB-T if anyone wants to look into it, but I think the TS splitters must be worked on first.

[crlorentzen]

Originally Posted by NiFa

I tried newest revision (3200), and everything works! I have no problems with AC3 or DTS passthrough or AC3 encoder.
Thanks to everyone who works with ffdshow and got these problems solved.

agreed, 3200 works perfectly. I don't even need to use the Connect as PCM first check box and all acs/dts pass-through works perfectly. Thanks to all especially you albain.

[iron2000]

3200 works ok here too but with DXVA the picture slows down and explodes to artifacts on seek.
Happens on both 32-bit and 64-bit versions.

[Jeremy Duncan]

Originally Posted by iron2000

3200 works ok here too but with DXVA the picture slows down and explodes to artifacts on seek.
Happens on both 32-bit and 64-bit versions.

If you open ffdshow video decoder, decoder options.
Then uncheck these two boxes: Detect soft telecine, Drop frame on delay.
Then try out your test clip where the picture goes funny, is the picture still garbled?

[CiNcH]

The normal ffdshow decoder is also lacking a full parser for access units.

True for VC-1, not for H.264.

[iron2000]

Originally Posted by Jeremy Duncan

If you open ffdshow video decoder, decoder options.
Then uncheck these two boxes: Detect soft telecine, Drop frame on delay.
Then try out your test clip where the picture goes funny, is the picture still garbled?

Thanks but the problem only happens with the DXVA decoder.
Will changing the settings in the non-DXVA decoder affect it?
Even if I wanted to change the settings, the profile that calls the DXVA decoder doesn't have the decoder options.

I've set ffdshow such that it plays video with resolution equals of larger than my desktop resolution with the DXVA decoder.
Playback is very nice as always with the non-DXVA decoder.

[albain]

That's right, the decoder options are not available in DXVA decoder but I don't know if they are used or usable : the options are not accessible but the settings are present (they are set to default).

[Elbart_]

Hm, weird.
After rebooting because of the Windows-update, I tried to play an AVC-video, and ffmpeg-mt again wasn't working (libavcodec did), although it did before the reboot. After reinstalling 3200, it worked again. I wonder, why it's only ffmpeg-mt which has these problems?

[albain]

Can we remove the following option in FFDShow audio output section ?

"Don't use WAVEFORMATEXTENSIBLE header when not needed"

I don't see the interest of keeping it, this doesn't mean anything by the way

[tal.aloni]

Intel has recently posted an article about copying DXVA decoded frame from the portion of the memory that belongs to the GPU back to the system RAM.

this could mean we will be able to apply all post processing filters after utilizing DXVA decoding. (except maybe the resize filter)
we're still not sure if this could be applied for DXVA 1.0 as well, we do have some interesting ideas.

albain has volunteered (again) to try and implement it.

link:
http://software.intel.com/en-us/arti...frame-buffers/

p.s.
the memory bandwidth required to process 1080p24 that way seems easily obtainable.

[STaRGaZeR]

Yay!

[iron2000]

Originally Posted by Jeremy Duncan

If you open ffdshow video decoder, decoder options.
Then uncheck these two boxes: Detect soft telecine, Drop frame on delay.
Then try out your test clip where the picture goes funny, is the picture still garbled?

I disabled both options from the DXVA profile through the registry but the artifects on seek is still there.

[tal.aloni]

H.264 DXVA seeking artifacts happens for me too, probably the decoder does not wait for an I frame. I'll have a look.

[STaRGaZeR]

How's seeking speed compared to software decoding and MPC's DXVA, specially if you seek to B frames? My PC has been on repairs for quite some time and I haven't tested ffdshow's DXVA yet.

[tetsuo55]

Originally Posted by tal.aloni

Intel has recently posted an article about copying DXVA decoded frame from the portion of the memory that belongs to the GPU back to the system RAM.

this could mean we will be able to apply all post processing filters after utilizing DXVA decoding. (except maybe the resize filter)
we're still not sure if this could be applied for DXVA 1.0 as well, we do have some interesting ideas.

albain has volunteered (again) to try and implement it.

link:
http://software.intel.com/en-us/arti...frame-buffers/

p.s.
the memory bandwidth required to process 1080p24 that way seems easily obtainable.

keep in mind this only works for DXVA2 and thus vista and higher, so DXVA1 will not work.(although some things could be done in shaders)

[tal.aloni]

I have no reason to think it would not work on DXVA1,
according to MSDN, we can use DXVA 1.0's GetBuffer() with 0xFFFFFFFF to get the pointer to the decoded buffer, copy to RAM (using the above method), apply post processing (except resize of course) and the question remains if we can copy it back to the GPU memory.
(as alternative to the last stage, we can also use VMR9's AllocatorPresenter to override the original image completely)

[Jeremy Duncan]

Originally Posted by albain

That's right, the decoder options are not available in DXVA decoder but I don't know if they are used or usable : the options are not accessible but the settings are present (they are set to default).

It would be intersting if you made a build with both video decoders: dxva and regular video decoder, use the settings I recommended where you uncheck those options.

That way there would be no mistake that this would help or not.

I have updated the ffdshow wiki in the sw section. I showed how visual studio basic, the free version, can make ffdshow.ax. I showed how to fix the error "'atlbase.h': No such file or directory" when using the free visual studio, and I built a ffdshow installer to verify that you can.

So if somebody wants to learn how it won't cost them anything.

link