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

nevcairiel

20th March 2011, 20:21

Never dropped frames, except on some very weird movies i get one or two on load, but none in playback. Jitter is most of the time 0, sometimes (rarely) a value something below 10, but nothing that i ever noticed in playback (including the EVR-CP OSD graphs, perfectly smooth)

Oh, and do me a favor and shrink screenshots :P

hoborg

20th March 2011, 20:24

Sounds like something else, possibly a audio renderer thing thats just being triggered by that.

I have ATI5770->Monitor HDMI connection. I just tested play it using my Audigy4 sound card. Result is the same.

Remove DTS track from MKV = no stutter.

It happend only on DTS + custom EVR.

Again, if i use simple EVR, playback is perfect:
http://www.volny.cz/hoborg/snap1.png

jmone

20th March 2011, 20:31

ffdshow? MS DTV Decoder? Are you guys watching that much native video content? If not, I wonder how you could *not* use the DScaler5 IVTC Mod MPEG2 decoder.

PAL Land here, most playback is from progressive sources, and while Interlaced content watching is pretty limited it includes:
- Camcorder footage, DV-AVI (50i), HDV(25p in a 50i container), and AVC (50p)
- PAL DTV recordings (normally broadcast in 1080i or 576i @ 50hz) for Sort / Music Video
- Some NTSC based from US Discs etc (eg old eps of West Wing ripped by Chapters)

nevcairiel

20th March 2011, 20:35

Again, if i use simple EVR, playback is perfect:

Maybe you should bring that up with the renderer devs, then.. :d

As i said, i sometimes do see jitter with values < 10, but never dropped frames, and never any visual problems with the video.

hoborg

20th March 2011, 20:37

Maybe you should bring that up with the renderer devs, then.. :d

I already did.
For example MePo dev wrote that this is audio decoder bug. I just trying to found the source of this issue :/

Only way i found how to fix it is to use ffdshow audio decoder with disabled jitter correction.

nevcairiel

20th March 2011, 20:40

Does it happen with other splitters?

You already said it happened with ffdshow as well, but only with LAV Splitter?

hoborg

20th March 2011, 20:43

Does it happen with other splitters?

You already said it happened with ffdshow as well, but only with LAV Splitter?

I tested MPC-HC and LAVF splitter, various combination of A/V decoders with the same result.
Only one thing helped - disabling jitter corection in ffdshow audio decoder - stuttering and droped frames are gone.

SamuriHL

20th March 2011, 20:50

That's consistent with what was reported before. Search the ffdshow thread for jitter and you should find it.

hoborg

20th March 2011, 20:50

@nevcairiel:

BTW, how hard will be to create modified LAVF audio decoder with disabled jitter corection for DTS - just for simple test?

nevcairiel

20th March 2011, 20:51

I don't really have any active jitter correction in the LAV Audio Decoder .. i can produce a test build to disable on thing and see, but i don't think its relevant, but hey testing may help

nevcairiel

20th March 2011, 20:55

Try this:
http://files.1f0.de/lavf/LAVFilters-0.19-audio-jitter-test.zip

hoborg

20th March 2011, 20:58

Try this:
http://files.1f0.de/lavf/LAVFilters-0.19-audio-jitter-test.zip

Hey, you did it, no stuttering any longer! :)

nevcairiel

20th March 2011, 21:04

I'll have to run some tests if that has negative results for other files, but in theory it should not have.

Thinking about it, i'm not sure why i coded it like that.

If someone else wants, i would appreciate some tests using the version linked with various audio codecs, if you notice any problems.

Just to be sure you see it, here is the link again:
http://files.1f0.de/lavf/LAVFilters-0.19-audio-jitter-test.zip

Ger

20th March 2011, 22:54

Running the jitter test ax now. Not noticed anything different so far, but I didn't have hoborg's problem in the first place.

On a different note, am I missing something regarding the new AC3 sub stream in TrueHD option? I've been testing the Dolby TrueHD Channel Check and another TrueHD sample from here (http://www.demo-world.eu/trailers/high-definition-trailers.php), and I can hear the audio when the truehd 7.1 track is selected, and an AC3 5.1 track is exposed and tagged as [sub], but if I select that AC3 track I hear only silence. The LAV Audio status page shows constant full/maxed out bars on all 6 channels and 16-bit int under decode.

32-bit float output, channel mask looks right, 0x3f as with other AC3 5.1 tracks. Channels, sample rate, codec also looks OK in that status page.

Everything seems normal when the "normal" truehd track is selected.

nevcairiel

20th March 2011, 22:57

The substreams are not new, what is new is the option to hide them. Previously, i would just always show them.

Can you possibly try 0.18 and see if it works there? I might have an idea what could potential have broken it, but i cannot test right now.

Ger

20th March 2011, 23:06

OK. These trailers/test samples are the only truehd content I have so I didn't really try or look for them before (or I forgot).

Anyway, 0.18 works. The audio decoder also shows 32float under decode in 0.18, and not 16int like in 0.19.

nevcairiel

20th March 2011, 23:09

Thanks, i'll fix it for the next version then. Its not that important, no-one should want the AC3 stream when he can have TrueHD :P

Midzuki

21st March 2011, 06:39

Only today I found the will to (start to) test these DLLs. :)
My first impressions:

- it is a source filter and a demuxer at the same time,
why not use two separate "modules" ?

- the "volume meter" of the audio decoder is t00 sl0w :devil: ,
and supports only up to 8 channels ;

- how about including a channel mixer and a frequency resampler ?

nevcairiel

21st March 2011, 08:12

- it is a source filter and a demuxer at the same time,
why not use two separate "modules" ?

Why use two separate modules?

First off, its alot easier to get direct access to the IO then relying on some other filter, second, i didn't really see the big point of separating it yet.
That said, there is a point on the TODO to allow to use a separate source filter for streaming content and whatnot .. but all in due time.

- the "volume meter" of the audio decoder is t00 sl0w :devil: ,
and supports only up to 8 channels

Its not meant to be a real-time statistics display, its just there for debugging, seeing if the audio went to the right channel, and how the channels are flagged.

Also, i have never seen an audio file with more then 8 channels (in fact, it would probably cause funny issues with the decoder in general)

- how about including a channel mixer and a frequency resampler ?

I plan to add channel mixing, possibly. Maybe i could also put that in a dedicated audio post-processing filter. I'm not sure yet what to do, it'll also be a while until i do it.

The decoder itself will not get resampling, the post-processing filter would.

Midzuki

21st March 2011, 08:41

Thanks for answering.

jmone

21st March 2011, 10:24

nevcairiel - quick note to say that I'm really impressed with your splitter and audio decoder. Both are looking rock solid over a range of various content and suit my setup down pat.
Thanks again for your work and I look forward to the Blu-ray support in the splitter.
Nathan

mindbomb

21st March 2011, 19:03

there seems to be a problem with seeking with large matroska files with 24 bit 7.1 dts hd ma audio.
it seems to cause like a memory leak.

I'll see if i can make a sample.

edit: I can't make a sample, the problem keeps fixing itself in samples, argh.

I updated to a newer build of mpc hc, and now it refuses to seek at all.

I know this is quite vague, but perhaps you can make sense of it nev?

Virtual_ManPL

22nd March 2011, 20:47

Try to disable "Fast seek(on keyframe)" in "Tweaks" in MPC-HC options. Maybe this will helps.

mindbomb

22nd March 2011, 21:10

thanks virtual man, but that didn't fix it.

It allowed me to seek through the video again, but playback speed appeared faster than it should have been, with no sound, and it would continue to consume all of my memory. Very similiar to my experience before I updated my player.

nevcairiel

22nd March 2011, 21:13

All DTS-HD files play perfectly for me.

mindbomb

23rd March 2011, 01:54

yea, im not sure what the deal with this file is, i remuxed just the audio into an mka, and it played fine.

Is it alright if I send you a large sample file ?

nevcairiel

23rd March 2011, 08:01

If you can upload it somewhere where i can download it with a reasonable speed..

Snowknight26

24th March 2011, 05:48

The LAV Splitter (x64) causes corruption for a few frames right after seeking:
http://img59.imageshack.us/img59/8084/00002m2tssnapshot001356.png

Tested in MPC-HC; doesn't happen with the Microsoft DTV-DVD Video decoder, only MPC Video decoder.

Sample: http://stfcc.org/misc/lav.splitter.corruption.m2ts

fastplayer

24th March 2011, 10:13

With this sample (http://samples.mplayerhq.hu/A-codecs/AAC/faad2-fail.mkv) [MKV, 1.4MB], LAVSplitter starts 2 instances of ffdshow's audio decoder, one for each language track. Is this intended behavior?

nevcairiel

24th March 2011, 10:20

hoborg

24th March 2011, 10:21

fastplayer

24th March 2011, 10:28

There is no way it creates 2 pins of the same type. Its just not physically possible.
Are you sure its actually using LAV Splitter and not the MPC-HC internal splitter (which creates one pin for every stream instead of offering a stream switcher)
You're right. I've set up LAVSplitter as preferred, thinking it would override MPC's internal splitters. Apparently, it does not. Sorry for the false alarm!

Edit: Process Explorer confirms this: No LAVSplitter.ax is loaded.

Edit #2: Something similar happens with the internal AAC decoder, too. I have to explicitly disable it in order to use ffdshow's decoder.

nevcairiel

24th March 2011, 11:12

Internal filters have a higher priority then external ones, even if you set external ones to preferred.
I thought that was a widely known fact :D

fastplayer

24th March 2011, 11:18

Internal filters have a higher priority then external ones, even if you set external ones to preferred.
I thought that was a widely known fact :D
It is. I just misinterpreted your recent commit (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=revision&revision=2973). :o

Ger

24th March 2011, 15:30

Internal filters have a higher priority then external ones, even if you set external ones to preferred.
I thought that was a widely known fact :D

It's not that simple though. The behavior was always inconsistent for me, and it still is to a degree.

Examples:

a) If I set "Microsoft DTV-DVD Video Decoder" to prefer, it will be used for h264 even if both internal h264 decoders are checked. Uncheck Microsoft, and the internal ones will be used.

b) If I set "LAV Audio decoder" to prefer it will be used for AC3 even if the internal AC3 decoder is checked. Uncheck LAV Audio and internal will be used.

c) If I set "LAV Splitter" to prefer it will not be used for TS if the internal MPEG TS splitter is checked. Internal must be unchecked to be able to use LAV Splitter.

I actually like the behavior in a and b better than in the behavior in c, because in a and b prefer always means prefer, and if the connection to the preferred filter fails from some reason then it can fall back to the internal filter since it's still enabled, just not prioritized.

EDIT:
Edit #2: Something similar happens with the internal AAC decoder, too. I have to explicitly disable it in order to use ffdshow's decoder.

This makes it even more inconsistent. Not just a source vs transform filter issue. LAV Audio decoder can be set to prefer even if the internal AAC decoder is enabled. With ffdshow audio set to prefer you still have to disable internal AAC (tested with fastplayer's sample). No wonder this is confusing.

tetsuo55

24th March 2011, 15:49

That is really inconsistent behavior.
This is how it should work:

* The internal filters when enabled should always override any external filter, even when one is preferred.

* When no internal filter is enabled, a preferred external filter should be used.

* When no preference is set, the directshow merits should be used to determine the filter to be used.

IEven these behaviour is uninituitive. If we had a willing developer the whole internal/external filter selection and preferences could be changed into a unified and logical interface.

Ger

24th March 2011, 15:55

* The internal filters when enabled should always override any external filter, even when one is preferred.

I disagree, because of what I said in the previous post. Prefer should always mean prefer which also allows fallback to internal filters if the preferred filter fails.

If an external filter is not set to prefer, then I agree that an internal filter should override any merit set for the external ones.

madshi

24th March 2011, 15:57

@Ger, I think we all agree with that, it just lacks devs to make it work that way.

tetsuo55

24th March 2011, 16:04

The *'ed items are the currently intended behaviour.

As madshi also says, we would all like to see "preferred" override everything.

Ger

24th March 2011, 16:05

nevcairiel fixed the source filter preference recently, so we could always hope he gets inspired again. ;)

nevcairiel

24th March 2011, 16:06

I disable most of the internal filters anyway, it was just a PITA that preferences for source filters were not working at all.

SamuriHL

24th March 2011, 16:12

I have ALL the internal filters disabled, as well. I provide my own. :)

mindbomb

24th March 2011, 18:48

right now, it seems when a source filter is set to prefer, it can't override an internal one, but when a transform filter is set to prefer, it will override an internal one.
I don't mind it too much the way it is now, but I would rather preferred filters always override internal ones.

Also, nev, did you get my large sample?
If not, is there any other way i could send it to you?

nevcairiel

24th March 2011, 19:08

Also, nev, did you get my large sample?
If not, is there any other way i could send it to you?

I got it, well, still downloading the last parts of it.

SamuriHL

24th March 2011, 19:56

So to all that helped me get the ArcSoft video decoder up and running, I wanted to report back on my progress. That checkactivate.dll thing is definitely required whether using a fully installed TMT instance or not. I dropped that in the Codec dir and now the codec works perfectly. I just want to step back for a moment and look at what I now have set up. Just to think about this for a moment. :D MPC-HC...all internal filters are disabled. Audio switcher is disabled. Subtitles are enabled. Renderer is madVR which of course just added subtitle support for MPC-HC hence why I'm using MPC-HC's subtitle support. Video is decoded by ArcSoft or Cyberlink video decoder (depending on my mood I guess) and sent into ffdshow raw video for post processing, before being sent to madVR for rendering. Audio is handled by ffdshow for perfect bitstreaming. Splitting, obviously, being done by LAVF. What this means is that I now have *THE* perfect MKV playback environment!!! I'm actually EXTREMELY happy with this setup right now! To recap:

MPC-HC with subtitles turned on, internal filters turned off
ArcSoft and Cyberlink video decoders
ffdshow audio bitstreaming
madVR renderer
LAVF splitter

Absolutely LOVE IT!