LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 413

LigH

13th March 2016, 19:08

Well, I guess it is not impossible to store TFF in DV, ignoring that BFF is the default. The AVI container does not store a field order, IIRC. Video streams may store a field order, depending on the format. Therefore, decoders usually have to assume a default if there is no explicit flag.

P.J

13th March 2016, 19:24

MediaInfo: http://pastebin.com/eRxF4Nmp
Something is wrong in LAV while de-interlacing :confused:

huhn

14th March 2016, 11:49

what deinterlancer are you using?

nevcairiel

14th March 2016, 12:26

The chroma in that file is 4:1:1, which is not a format LAV natively supports, so it converts the chroma before deinterlacing would see it, which might result in interlacing artifacts. It gets converted to 4:2:2, which should be mostly safe as it only expands it horizontally, but you never know. On the other hand, 4:2:2 deinterlacing may not be well supported by whatever is deinterlacing for you.

4:1:1 is extremely uncommon, so I wouldn't expect improvements, really.

P.J

14th March 2016, 18:26

what deinterlancer are you using?
Using the hardware de-interlancer makes problem but software de-interlancers work fine, lower quality though without pull-down detection.

The chroma in that file is 4:1:1, which is not a format LAV natively supports, so it converts the chroma before deinterlacing would see it, which might result in interlacing artifacts. It gets converted to 4:2:2, which should be mostly safe as it only expands it horizontally, but you never know. On the other hand, 4:2:2 deinterlacing may not be well supported by whatever is deinterlacing for you.

4:1:1 is extremely uncommon, so I wouldn't expect improvements, really.
I think all LAV needs is to detect the Field Order flag well.
I have many sd musicvideos in 4:1:1 format :(

nevcairiel

14th March 2016, 19:07

I think all LAV needs is to detect the Field Order flag well.

MediaInfo also says BFF, so maybe your file is just bad.

P.J

14th March 2016, 21:00

MediaInfo also says BFF, so maybe your file is just bad.

Just tried PotPlayer only to detect the issue, same problem happens as soon as I select GTX960's hardware deinterlacer :confused:
The only working way is to set TFF. I think HW has better quality (it has pulldown detection too)

nevcairiel

14th March 2016, 22:44

Just tried PotPlayer only to detect the issue, same problem happens as soon as I select GTX960's hardware deinterlacer :confused:
The only working way is to set TFF. I think HW has better quality (it has pulldown detection too)

Sounds like your hardware deinterlacing gets confused when it has to process 4:2:2, you could always use software deint.

P.J

14th March 2016, 23:03

Sounds like your hardware deinterlacing gets confused when it has to process 4:2:2, you could always use software deint.

But it deinterlaces other 4:2:2 videos correctly:

H.264 10-bit 4:2:2 TFF
MPEG2 8-bit 4:2:2 TFF
DV dvc 8-bit 4:1:1 BFF: http://pastebin.com/p709gXVN

Maybe something is wrong with Sony DVsd :confused:

kiwijunglist

14th March 2016, 23:06

@huhn - i thought i might be missing out on some important sounds from the object based channel.

LigH

15th March 2016, 00:25

@ P.J.:

Again ... decoders may assume BFF just because it's "DV in AVI". There may be no flag at all, neither in the AVI container, nor in the DV video stream, reporting whether TFF or BFF is present. Even MediaInfo may assume only due to the format.

Unfortunately, I am not sure if there is a flag. And if there is any, it may even be wrong. All I know is: The video should not have been saved as NTSC DV in AVI. In addition to the uncertain field order, it also lost chrominance precision.

P.J

15th March 2016, 09:06

Unfortunately, I am not sure if there is a flag. And if there is any, it may even be wrong. All I know is: The video should not have been saved as NTSC DV in AVI. In addition to the uncertain field order, it also lost chrominance precision.

How can I ensure if the video is really BFF or TFF?
If not in avi then what? :confused:

LigH

15th March 2016, 09:18

P.J

15th March 2016, 10:08

I think this helps to find the correct information, detects the right field order and pulldown after I press "Guess 3:2 Pulldown":

http://phota.me/3etN.png

LigH

15th March 2016, 10:32

Automatic detections may help when they work reliably. But I bet there is footage where this automatic detection fails. The human brain is able to recognize image content and motion better than most current software solutions with reasonable complexity. You should not miss at least a brief glance after an automatic detection, just to confirm.

P.J

15th March 2016, 12:20

Never rely on flags. Always check the content: Compare the results of

AviSource(...)
AssumeTFF()
Bob()

and

AviSource(...)
AssumeBFF()
Bob()

The field order which does not judder is the correct one. If neither is worse, it may not be interlaced at all... For more complex issues (Telecine, blending), watch the result slowly and try to discover the temporal progress attentively.

Well, I saved that script in an avs file and played it with MPC-HC x86.
AssumeTFF() fixes the problem, a bit stretched/blurry and lower quality though maybe due to Bob.

And with AssumeBFF(), the problem happens again, skippy frames.

LigH

15th March 2016, 12:52

Of course it is a bit blurry, because fields are interpolated to frames; but these scripts are for testing only, not for processing!

So you discovered that some moron stored TFF video as DV, ignoring that DV is usually expected to contain BFF by default. Blame him (also for losing chrominance precision due to 4:1:1 subsampling). Or better: Teach him which other video formats would have been appropriate, instead of NTSC DV.

NikosD

15th March 2016, 18:22

I return for a little to my XP-DXVA2-EVR issue to report an interesting test I did.

According to DXVA Checker, ATI installs DXVA1/2 device decoder for VC1_VLD, but only DXVA1 for H.264.

So, there is no luck to HW accelerate H.264 using DXVA2.

Using GraphStudioNext 0.7.0, I tried a VC-1 clip with LAV Video and MPC Video decoder (MPC-BE standalone) using EVR renderer.

Well, both decoders connected to EVR and managed to decode the file, but LAV Video felt back to SW decoding while MPC Video used HW acceleration for VC-1 clip!

How could you explain that besides thinking that LAV Video lacks DXVA2 acceleration while MPC Video seems to have ?

nevcairiel

15th March 2016, 20:43

As I have stated before, I have no interest in HWAccel on XP (or in functionality on XP in general). It works as it works. I don't remember when I last tested on XP, its been years, and I certainly do not have any plans to resume doing so (especially for hwaccel, which I would even need to run on real hardware, not just a VM)
Note that MPC video decoder supports DXVA1, so maybe thats in use.

NikosD

15th March 2016, 21:00

OK...Maybe you have disabled DXVA2 for Win XP, but years ago.

WinXP is a very old system, I was just doing some tests.

But are the DXVA1 and EVR compatible ?

foxyshadis

16th March 2016, 07:22

OK...Maybe you have disabled DXVA2 for Win XP, but years ago.

WinXP is a very old system, I was just doing some tests.

But are the DXVA1 and EVR compatible ?

Microsoft has never supported DXVA2 under XP in any way, there was nothing to disable. The only way it ever worked in some software was with ugly hacks.

Along the same lines, EVR has never been supported on XP. It's DXVA2 (and WDDM) only.

NikosD

16th March 2016, 08:31

If you read previous replies only a few posts earlier, a few people here don't seem to agree with you, including nevcairiel I'm afraid.

Sharc

16th March 2016, 08:54

Well, I saved that script in an avs file and played it with MPC-HC x86.
AssumeTFF() fixes the problem, a bit stretched/blurry and lower quality though maybe due to Bob.

And with AssumeBFF(), the problem happens again, skippy frames.
You may find this script convenient for testing. It displays the fields (half height) stacked vertically as TFF and BFF.

AviSource("........")
bottom = AssumeBFF().SeparateFields()
top = AssumeTFF().SeparateFields()
bottom = subtitle(bottom, "BFF - bottom field first")
top = subtitle(top, "TFF - top field first")
StackVertical(top, bottom)

madshi

16th March 2016, 09:06

Officially XP doesn't support DXVA2, but .Net 3.5 (IIRC) retrofitted XP with DXVA2 API functionality and EVR. Microsoft just lay the groundwork, though. How much of that is actually supported by the GPU drivers is up to NVidia/AMD/Intel. From what I remember, DXVA2 deinterlacing usually works in XP, while hardware decoding is a hit-and-miss, with only some codecs being supported by some GPU drivers. There are no ugly hacks needed, IIRC, deinterlacing just worked out of the box for me, once I had .Net 3.5 installed.

In any case, as nevcairiel has already stated, all of this is rather unofficial, and what works that works, and what doesn't work doesn't. So there's no use even complaining about anything not working. Just consider everything that works as an unexpected bonus. Anyone still using XP shouldn't expect a lot of support these days. It's just too much hassle for us devs to still test on XP, especially since usually using a VM won't work because we need hardware acceleration to work for doing useful tests.

My recommendation for the best media playback OS atm would be Windows 8.1. Windows XP is *REALLY* outdated. Windows 8.1 has several important improvements over Windows 7 (native 3D support, much improved desktop composition). Windows 10 is still too buggy and unstable, which may change in the future, though.

NikosD

16th March 2016, 09:18

khanmein

16th March 2016, 09:30

720p .mkv h.265 is working on CUVID + enable smooth motion

i tried to drag the seek bar, it won't freeze or cause any shuttering or even unresponsive issue on mpc-hc.

DVXA-CB & native still got issue while playing .mkv h.265

madshi

16th March 2016, 10:12

The whole discussion is more academic and technical for me, than anything else.

It's not that I actually use WinXP in an every day process.

My first post was questioning WinXP HW acceleration usability of LAV Video since its support is explicitly to DXVA2.

But there were posts supporting WinXP's use of DXVA2 and usability of LAV Video HW acceleration on XP.

That's it more or less.
From what I remember, when I still ran XP, my AMD GPU supported h264 DXVA2 decoding, but neither MPEG2 nor VC-1. Or was it MPEG2, but not h264 and VC-1? I'm not sure. In any case, one codec was supported, the others were not. It all depends on the GPU drivers. The OS support for DXVA2 decoding is there, once .NET 3.5 is installed. It's up to the GPU drivers to support hardware decoding for specific codecs.

So if you're interested in knowing which GPU and which GPU drivers support which codecs for DXVA2 hardware decoding in XP then I suggest you open a new thread with a poll. But I don't think you'll get a lot of response because I think most users have moved on from XP in the meanwhile.

NikosD

16th March 2016, 11:19

If you read a previous post, I describe in detail that VC1 is only supported by drivers using DXVA2, but unfortunately only MPC-BE decoder worked with EVR and DXVA2.

LAV Video fell back to SW.

MPEG2 was always hardware assisted by ATI, till HD 6000 series that added VLD and LAV (like most decoders) doesn't support hardware assisted acceleration.

It is probably VC-1 what you remember.

P.J

16th March 2016, 20:52

You may find this script convenient for testing. It displays the fields (half height) stacked vertically as TFF and BFF.

AviSource("........")
bottom = AssumeBFF().SeparateFields()
top = AssumeTFF().SeparateFields()
bottom = subtitle(bottom, "BFF - bottom field first")
top = subtitle(top, "TFF - top field first")
StackVertical(top, bottom)

Yes, BFF has problem but TFF is ok.
Don't know why the problem happens with hardware deinterlacer but software deinterlacers :confused:
Maybe because hardware deinterlacer uses inverse telecine since only 2 of 5 frames are interlaced.

LigH

16th March 2016, 20:57

What? Did you just say it is telecined? And why did you conceal this fact from us until now?

P.J

16th March 2016, 22:39

What? Did you just say it is telecined? And why did you conceal this fact from us until now?

Ain't most of ntsc music videos telecined? :confused:

I was shown it here too: http://forum.doom9.org/showpost.php?p=1760831&postcount=20665

LigH

17th March 2016, 00:11

But, well, to deal with telecine, you never use a "deinterlacer". This is a job for IVTC.

huhn

17th March 2016, 02:03

try madVR IVTC and life a happy life. (control+shift+alt+t until you see "film" mode.)

Vincent Vega

17th March 2016, 22:39

how can i control conversion coefficient with this filter for RGB output?

i have an old dvd that looks better with 709, but any h/w decoding applies 601 apparently.

because of lack of 601/709 toggle in LAV settings i even had to install ffdshow to watch this movie.

PS: i actually wish there was a separate settings sections in LAV for old/problematic SD content where user can define s/w deinterlacer, desired output colorspace and coefficients for full software decode/processing, unchecking h/w SD decoding in main config.

P.J

17th March 2016, 23:11

But, well, to deal with telecine, you never use a "deinterlacer". This is a job for IVTC.

But seems the field order flag affects on it :confused:
Any software IVTC?

try madVR IVTC and life a happy life. (control+shift+alt+t until you see "film" mode.)

Thanks, will try it.

LigH

17th March 2016, 23:25

"Offline", in AviSynth: Try tritical's TIVTC (http://avisynth.nl/index.php/TIVTC) package = TFM (http://avisynth.nl/index.php/TIVTC/TFM)(...).TDecimate (http://avisynth.nl/index.php/TIVTC/TDecimate)(...) to revert video material from telecined to the original progressive content.

nevcairiel

18th March 2016, 16:19

how can i control conversion coefficient with this filter for RGB output?

You can't.

Or more specifically, by not letting LAV do this conversion. LAV intentionally does not provide such options, and will likely never get them either.
You could use post-processing filters, or use a renderer that lets you choose (madVR would be one, or possibly any renderer that accepts custom pixel shader to convert the video)

In general, LAV Video aims to be a decoder first and foremost, some conversions are only provided for convenience and/or interoperability with other components, but anything thats not native output is not a priority for LAV, and as such options for conversions are intentionally limited.
For RGB conversion this means that it either uses the information from the file, if it contains any, or guesses based on the resolution - but it does not allow you to override.

balkerman

20th March 2016, 03:26

Get someone else with your amplifier to test.. also try another HDMI cable.
Alter the refresh rate to as close as possible to the Media frame rate. If close enough it may work. Worked for me! [emoji14]

macycat

20th March 2016, 04:44

I had already done what you suggest, and when I was doing my testing, the madVR OSD indicated that I got only 1 frame repeat every 1.5 hr. So I don't think that my problem is due to frame drops/repeats/glitches (see my original post below).

It is interesting to note that I don't get any audio glitches when decoding with LAV and sending the same audio to my receiver via PCM.

The audio track plays as Dolby TrueHD. I should do some more testing to see if the problem occurs with other audio formats. It might have something to do with the fact that the audio track is (or perhaps was) Dolby Atmos (not sure what MakeMKV does for those tracks).

Thanks for the reply. :)

Alter the refresh rate to as close as possible to the Media frame rate. If close enough it may work. Worked for me! [emoji14]

nevcairiel,

I have been having an audio glitch every minute or so when bitstreaming TrueHD audio streams. I tried the new version, and I still get the occasional audio glitch, so it doesn't look like the above fix addresses this problem. I don't observe the problem when decoding to PCM.

I am using madVR, and I don't see and dropped, repeated, or delayed frames, nor do I see any presentation glitches ... just the audio problem.

Let me know if you need me to test anything for you ...

wanezhiling

20th March 2016, 05:00

http://forum.doom9.org/showpost.php?p=1761323&postcount=3687
LAV doesn't work too.

balkerman

20th March 2016, 05:35

I had already done what you suggest, and when I was doing my testing, the madVR OSD indicated that I got only 1 frame repeat every 1.5 hr. So I don't think that my problem is due to frame drops/repeats/glitches (see my original post below).

It is interesting to note that I don't get any audio glitches when decoding with LAV and sending the same audio to my receiver via PCM.

The audio track plays as Dolby TrueHD. I should do some more testing to see if the problem occurs with other audio formats. It might have something to do with the fact that the audio track is (or perhaps was) Dolby Atmos (not sure what MakeMKV does for those tracks).

Thanks for the reply. :)
Every 1.5 hours is 1-2 glitches per movie. That was never good enough for Dolby hd for me, after adjusting the refresh rate I now have about 1 per day in mad vr. Dts hd never glitched, only Dolby hd. I used a program called CRU I think... Can't remeber, am away from my pc.

Also depends on what your gpu and TV can do!!

macycat

20th March 2016, 06:51

How often did you get Dolby TrueHD glitches before you fine-tuned your timing? I get them every minute or so ...

Every 1.5 hours is 1-2 glitches per movie. That was never good enough for Dolby hd for me, after adjusting the refresh rate I now have about 1 per day in mad vr. Dts hd never glitched, only Dolby hd. I used a program called CRU I think... Can't remeber, am away from my pc.

Also depends on what your gpu and TV can do!!

mzso

20th March 2016, 14:28

Hi!

What's the reason for HW deinterlacing being restricted to HWA decoding?

huhn

20th March 2016, 17:38

Hi!

What's the reason for HW deinterlacing being restricted to HWA decoding?

adding hardware deinterlancing for software decoding is possible too.

and if i'm not mistaken it is a planned feature with no ETA at all.

chros

20th March 2016, 20:25

How often did you get Dolby TrueHD glitches before you fine-tuned your timing? I get them every minute or so ...
That's interesting. I've never had any glitches with any kind of audio (TrueHD, Atmos, DTS, DTS-HDMA, PCM) with my system (see my signature), and the timings are way off: 24.000xx , 30.000xxx , 50.000xx , 60.000xx Hz (since I can't create custom refresh rates with intel driver).