LAV Filters - DirectShow Media Splitter and Decoders

[magic144]

seems good on my 2 latest clips, hope it doesn't break things for others - thanks nev

[fastplayer]

Nev, I've noticed that LAVVideo's RGB32 produces a "colder" red compared to ffdshow's RGB32 converter with this sample: http://leak.no-ip.org/Stuff/lipsum.avi

Take a look at these screenshots:
EVR-CP + LAV Video RGB32
http://s2.postimage.org/6faa0hes/EVR_RGB32.jpg (http://postimage.org/image/6faa0hes/)

EVR-CP + ffdshow RGB32
http://s2.postimage.org/6fnib9d0/EVR_ffd_RGB32.jpg (http://postimage.org/image/6fnib9d0/)

madVR's output is similar to ffdshow's. What could be the reason for the different color tone?

PS: Just wanted to confirm that your latest test build fixes the WebM seeking issue (http://forum.doom9.org/showthread.php?p=1532015#post1532015) I reported a while ago. Thanks!

[nevcairiel]

I compared the actual color tones produced, and LAV produces a color that is exactly RGB 255,0,0, so a pure red, while ffdshow produces a 255,24,0 color, red with a small hint of green.
Which is more correct is hard to say, i did find a small inaccuracy in ffdshows YUV->RGB matrices and updated them to the reference values when i wrote my RGB converter, but its not enough to account for this big change, i would think.

The odd thing is, no matter where i look, i find slightly different coefficients for the conversion matrix.
In the end, i went with the values defined in the official standards, as defined by the the ITU-R for BT.601 and BT.709.

For the record, the coefficients used are:

BT.601: Kr: 0.299, Kg: 0.587, Kb: 0.114
BT.709: Kr: 0.2126, Kg: 0.7152, Kb: 0.0722

This file uses BT.601, because its SD and the video stream does not indicate a color space.

Personally, i would think the pure red is more accurate, but who knows what the creator of that video went with.

Edit:
I just noticed that madVR seems to use a BT.709 matrix when feeding it YV12. Wonder why that is .. it doesn't qualify for my HD rules, because i require it to either be 720 pixel high or 1280 pixel wide.
Maybe madshi reads this? :)

[fastplayer]

Thanks a lot for the thorough answer! :)
I should've asked you this earlier and save myself a lot of time trying to figure out what I did wrong... *argh*

As for your MP4 test build: No issues so far (tested on MOV trailers and MP4 samples).

[madshi]

I just noticed that madVR seems to use a BT.709 matrix when feeding it YV12. Wonder why that is .. it doesn't qualify for my HD rules, because i require it to either be 720 pixel high or 1280 pixel wide.
Maybe madshi reads this? :)
He does. NTSC is 480 pixels high. PAL is 576 pixels high. So madVR considers every source which is higher than 576 pixels as HD -> BT.709.

[nevcairiel]

I guess the resolutions between PAL/NTSC SD and 720p are somewhat rare, so you can go either way on these. I'll stick with my rules, i suppose. (And i think 255,0,0 is a nicer red. :p)

[Superb]

madshi: what about anamorphic DVDs where the width can be stretched when decoding and viewing it on a wide screen? by your rules, aren't these considered HD...?

[nevcairiel]

The stretching is done after decoding, the decoded image remains the same.

[Superb]

Is it always done by the renderer?

[madshi]

madshi: what about anamorphic DVDs where the width can be stretched when decoding and viewing it on a wide screen? by your rules, aren't these considered HD...?
As you say, the *width* is usually stretched, not the height. madVR allows SD content to go up to 1024 pixels wide. Only content which is wider than 1024 pixels (or higher than 576 pixels) is considered "HD" by madVR.

[CruNcher]

hmm it doesn't fix this strange freeze in the *.mov (H.264) i guess i have to supply a sample now but im not quiete sure how if it's a error without fixing it and the sample is very huge 1,24 GB ;)
Though if even Quicktimes own Parser doesn't freeze it must be a bug ;)

[STaRGaZeR]

As you say, the *width* is usually stretched, not the height. madVR allows SD content to go up to 1024 pixels wide. Only content which is wider than 1024 pixels (or higher than 576 pixels) is considered "HD" by madVR.

ffdshow has the same rules for the same reason. 1024x576 (encoded PAL DVDs) looks wrong with LAV.

[nevcairiel]

Only content >=720 pixels high or >=1280 pixel wide is considered HD by LAV, so a 1024x576 would still be perfectly fine SD content.

if (matrix == DXVA2_VideoTransferMatrix_Unknown) {
matrix = (swsHeight >= 720 || swsWidth >= 1280) ? DXVA2_VideoTransferMatrix_BT709 : DXVA2_VideoTransferMatrix_BT601;
}

I just read that the MSDN defines it differently as well, so i may change it.

DXVA2_VideoTransferMatrix_Unknown
Unknown. For standard-definition content, treat as DXVA2_VideoTransferMatrix_BT601. For high-definition content, treat as DXVA2_VideoTransferMatrix_BT709. (High-definition content is defined for this purpose as anything with a source height greater than 576 lines.)

[CruNcher]

@ Nev could you make a debug version :/

it seems to be a timestamp issue if i use lav video the whole thing plays strange with ministucks (though its 46 mbit 2k so it almost kills all 4 cores with Lav Video stucks could be coming from that actually)

Writing library : Apple QuickTime (The samples muxer)

[STaRGaZeR]

Yeah sorry, screw that post, your new converter doesn't have the issue. It probably was a swscaler thing. However there are more problematic resolutions like 1280x544 (2,35:1 720p without black bars).

matrix = (swsHeight > 576 || swsWidth >= 1280) ? DXVA2_VideoTransferMatrix_BT709 : DXVA2_VideoTransferMatrix_BT601;

This should address those cases.

[nevcairiel]

However there are more problematic resolutions like 1280x544 (2,35:1 720p without black bars).

matrix = (swsHeight > 576 || swsWidth >= 1280) ? DXVA2_VideoTransferMatrix_BT709 : DXVA2_VideoTransferMatrix_BT601;

This should address those cases.

The old logic was fine as well with that resolution.
As i figured it, if its 16:9, its usually always 1280 wide, and depending on AR some other height. If its 4:3, its probably 720 high, with some width like 960 or such.

Anyhow, since the 1024x576 rule seems to be common, i use it now as well, so a width > 1024 or a height > 576 will now call for HD.

[CruNcher]

jesus the ministuck issue with lav video was yv12 related again outputing boosted it to 80% cpu utilization @ NV12 its ok (23% cpu like CoreAVC and Cyberlinks Software Decoder)

still it freezes that seems 100% parser related :(

[hoborg]

@nevcairiel:
Can you please take a look on DTS in WAV? It seems to stop working.

[nevcairiel]

jesus the ministuck issue with lav video was yv12 related again outputing boosted it to 80% cpu utilization @ NV12 its ok (23% cpu like CoreAVC and Cyberlinks Software Decoder)(

Sounds like your renderer is doing weird things, YV12 is so straight forward processing in LAV Video, its just a plain memory copy from the decoder onto the output frame.

[nevcairiel]

@nevcairiel:
Can you please take a look on DTS in WAV? It seems to stop working.

Did you read my responses to your ticket comment? It still works perfectly like before.

[CruNcher]

hmm might be jans renderer acting strange with intels driver (though intels decoding performance is always the best with NV12 except if the input is natively 4:2:2 then it depends on the decoder as you saw from mainconcepts mpeg-2 vs lav video vs ffdshow test) :(

But this is a side thing the main issue is this freeze problem with this *.mov and lav splitter, where sound continues and video freezes without any warning (issue) before just rapidly instantly on 1 to the next frame it freezes (changing to MPC-HC Mp4/MOV splitter and it doesn't freeze) seeking is also not possible behind this point of freeze it just seeks the audio :)

Though im not sure how to supply this without fixing it and a 1.24 GB sample upload would take some time if i find some space to host it :P

[hoborg]

Did you read my responses to your ticket comment? It still works perfectly like before.

No, sorry, i didnt recieve any email about ticket update.
That is strange, i just tested your latest build you posted and i got only static...
I will post some samples.

[hoborg]

I think i found the problem. If i now open WAV with DTS in graphstudio, it create LAV splitter to audio renderer connection, LAV audio decoder is not added.

[nevcairiel]

I think i found the problem. If i now open WAV with DTS in graphstudio, it create LAV splitter to audio renderer connection, LAV audio decoder is not added.

Whatever player you're using, you just need to force it to load LAV Audio, even if the splitter claims its PCM. With MPC-HC, thats easy enough, just set LAV Audio to preferred, and it should always be inserted into the graph.

Sadly detecting DTS-in-WAV in the splitter is not so easy at this time.

[CruNcher]

funny trying to cut it with any ffmpeg based tools either crashes the host application or shows the same issues with seeking problems :P
VLC parses the freeze without issues though glitches for a moment encountering it that glitch is absolutely non visible with MPC-HCs splitter also seeking works with VLC (behind the problem)

nev a debug version of lav splitter would be great maybe we can see something in the output :) i also prepare a video of showing what different parser do here :)

[hoborg]

Whatever player you're using, you just need to force it to load LAV Audio, even if the splitter claims its PCM. With MPC-HC, thats easy enough, just set LAV Audio to preferred, and it should always be inserted into the graph.

Sadly detecting DTS-in-WAV in the splitter is not so easy at this time.

MY HTPC is NPVR based to play all media. There is no way to force any filter to be added in to graph - it is the same like in graphstudio, NPVR just ask DS to play the file.

[nevcairiel]

You can use some filter management tool to increase LAV Audios merit to something insanely high, maybe it helps.

[nevcairiel]

nev a debug version of lav splitter would be great maybe we can see something in the output :)

just run "ffmpeg -v 9 -loglevel 99 -i <filename>", that'll get you all the important output.

Builds available here:
http://ffmpeg.zeranoe.com/builds/

If i had to guess, that file just has multiple edit lists, which is not supported by ffmpeg.

[TheLion]

@nevcairiel:

I have a rather strange kind of issue. I am using lavfilter (splitter, audio decoder) with MC17. My setup is rather special in that I use a convolution VST plugin (Convolver to run Audiolense FIR filters). Output is per ASIO to a Prism Orpheus.

My issue is that I get (slightly) different results from outputting 32bit float (per setting this as only output format) from your decoder into the MC audio engine (64bit float) instead of the native 16bit/24bit int (flac files, bdmv's lossless tracks).

So basically the difference (using 32bit float output from Lav audio decoder results in a "brighter", more aggressive, more forward and "focused" presentation. 24 bit int output into the audio engine is "smoother"). I don't want to sound like I have found another snake oil audiophile trick but results are reproducible and confirmed by my better half. I witnessed the same thing in the old days where I was ripping anything to flac in mkv's and using madflac (24bit/16bit int) or ffdshow (with 32bit float output).

This definitely may have to do with my convolution which happens with 32 float processing.

So in the end there has to be an int->float conversion somewhere - instead of JRiver MC audio engine doing it (using 24bit int from lav decoder) doing this conversion at lav audio level gives different results.

Talking to the developer of Audiolense those time correction FIR filter are quite sensitive to any kind of jitter/distortion occurring between the decoder and the VST plugin.

Question is: Does Lavfilter/ffmpeg do a reference job with int-> float conversion (when the int decoder output is converted to float for lossless tracks, I always thought this conversion to be practically lossless?!)? Is there any chance Lavfilter introduces jitter/any kind of distortion with this conversion? Is this better handled within the JRiver MC audio engine and the output of Lavfilter kept at its native decoder format?

Any answer other than: "When your think to hear a difference use the one option you like better" is welcome ;-)

Thank you!

[hoborg]

You can use some filter management tool to increase LAV Audios merit to something insanely high, maybe it helps.

That was first thing i tried.
Too bad, it didnt help :(

[Superb]

As you say, the *width* is usually stretched, not the height. madVR allows SD content to go up to 1024 pixels wide. Only content which is wider than 1024 pixels (or higher than 576 pixels) is considered "HD" by madVR.I see. Thanks for the explanation.

I just have to say that I'm re-amazed every time when I see how responsive you and nevcairiel are w/ regarding to bug reports, development discussions/choices, and functionality explanations. That is w/o mentioning that you guys develop top notch projects for us to enjoy content watching. THANK YOU GUYS!

[nevcairiel]

Question is: Does Lavfilter/ffmpeg do a reference job with int-> float conversion (when the int decoder output is converted to float for lossless tracks, I always thought this conversion to be practically lossless?!)? Is there any chance Lavfilter introduces jitter/any kind of distortion with this conversion? Is this better handled within the JRiver MC audio engine and the output of Lavfilter kept at its native decoder format?

I would always keep it at the native output format for numerous reasons. The most important probably being that you don't know how your audio engine is converting the float back to int for output, and if those conversions do not match, it might result in different sound.

I do now know what you mean with "reference job". Its a plain and simple conversion, just convert to float, and rescale to the 1.0 - -1.0 scale. No fancy features.
The whole thing is mostly meant to disable formats that are not supported by your hardware and/or filters.


"When your think to hear a difference use the one option you like better"


In the end, thats what it comes down to, isn't it.

[CruNcher]

@nev

http://www.mediafire.com/?5d9r80vb7dis5ft

[nevcairiel]

If the problem also occurs with all ffmpeg tools, its certainly a problem in ffmpeg itself, and you should figure out how to extract a sample that shows the freeze.

[CruNcher]

im open for ideas :D
i try with vlc/vlmc first hoping it wont fix it ;)

ok tried some stuff but nothing works this is also crazy

MP4Box.exe -split-chunk 15:30 "G:\testsuite2\2k-test.mov" -out "G:\testsuite2\Split.mp4"
Adjusting chunk start time to previous random access at 14.40 sec
[iso file] Incomplete box ....
[iso file] Box "minf" has 33 extra bytes
Error cloning track 3


http://img195.imageshack.us/img195/3013/quicktimer.png

[hobbs1]

Hi,

here is a test build which, among other things, trys to fix the MP4 A/V sync problem reported.
If you people that watch MP4 files on a regular basis could test this, and report if it improved, or possibly got worse on other files, that would be great.

http://files.1f0.de/lavf/LAVFilters-0.37-50-g41ed098.zip

Nev, I just tested the new build with a MP4 file that had not been rendering video with v36 & 37.

Here is that post - http://forum.doom9.org/showthread.ph...22#post1529322

The file now plays perfectly with the new build so take that for whatever its worth and the audio sync is perfect.

FWIW, I think the MP4 file that I was trying to view is the problem because all of my other Mp4 files worked perfectly with 36 & 37.

Hope this helps and thanks for the work.

[CruNcher]

I got it it was easier then i thought the issue is propagating nicely into .mp4 as well (uploading) though some ffmpeg apps don't show issues anymore (Avidemux (or is it actually using libav parser?) ) but lavsplitter still freezes also ffplay does also videolan keept it's glitching @ that freeze frame and redos the title show (as it would seamlessly reopen the file) :)

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

PS: remuxing with Avidemux 2.5.5 fixes this freeze :)

Movie name : avidemux.mp4
Writing application : Lavf53.4.0

[rica]

Hi nev,

I've been trying to get wasapi exlusive BITEXACT over ReClock with Lav Filters.

Here is my HW, SW:

GeForce GTX 550 TI on Clarkdale (i3 540/H55)
nVidia driver version: 280.26
TMT5 5.0.1.114, MPC-HC 1.5.3.3757 with LAV Filters v. 0.37, ReClock 1.8.7.7...
Media: Chris Botti Live; the unique 96/24/5.1 PCM source i can find out yet...


Here is how to configure my MPC-HC:

Internal filters: completely disabled while lav fiters are enabled and preferred on external filters section.



Here is the chain on MPC-HC:


http://img573.imageshack.us/img573/8008/graphchain.png (http://imageshack.us/photo/my-images/573/graphchain.png/)


And if you notice ReClock only detect WASAPI Exclusive but not bitexact:

http://img213.imageshack.us/img213/8145/mpcwithlavaudio.png (http://imageshack.us/photo/my-images/213/mpcwithlavaudio.png/)


While it detects Wasapi exclusive[B] bitexact on TMT 5: (I uploaded a BDMV, please create an ISO with ImageBurn and open it on Virtual Clone Drive's fake driver. Otherwise TMT downsamples it to 48/6/16...

http://img832.imageshack.us/img832/2651/tmt5withlavaudio.png (http://imageshack.us/photo/my-images/832/tmt5withlavaudio.png/)

Here is the sample file:

http://www.mediafire.com/?26z6a1w3lkia68a


Could you have a look at?

EDIT: I've met this issue only with PCM unmolested streaming, no issues with DTS HD or THD bitsreaming.

LATEST EDIT: Fixed:

http://forum.doom9.org/showthread.php?p=1534340#post1534340


- - - - -

_ _ _ _ _

[Pat357]

TO NEV:
if use last lav Splitter to Splitter mkv .use wavpack for lavaudio or last wavpack-directshow
http://code.google.com/p/wavpack-directshow/
mediaplayer give me not good sound!
test file
http://www.mediafire.com/?62l18m72ztxbmdo
It seems the wavpack codec in ffmeg is somehow broken for files encoded in the so called "hybride" mode.
In this mode wavpack will create 2 files on encoding (.WV + WVC) if it can't encode lossless with the specified bandwidth.
The WV will then be lossy or lossless and if lossy, a WVC is created to make it possible to make the process lossless.
Suppose the WV is lossy, then WV + WVC = lossless.
A very nice concept anyway !

[Ingram]

Does LAVVideo support DXVA with Ati? I'm getting extremely high CPU usage for H264/BR playback but with FFDShow's DXVA I get barely any. I didn't realise until now that LAVVideo was chewing through my CPU until I went to play some 1080P content.

Happy to stick with FFDShow's DXVA if Lav Video is no good for Ati users anymore.

[SamuriHL]

It has never supported DXVA.

[Ingram]

Right well that explains a lot. I figured it did since why wouldn't you want DXVA...

Oh well :)

[Asmodian]

DXVA isn't known for being super easy.

[SamuriHL]

Right well that explains a lot. I figured it did since why wouldn't you want DXVA...

Oh well :)

Oh, you know, to use things like madVR? :)

[noee]

Plus, IIRC, didn't nev or someone find that with LAVCUVID, it bumps the card to full clocks, negating any real power savings? Or was that fixed?

[Keiyakusha]

What is going on lately? First someone screams that subtitles support is broken, when there was no such support ever. Now DXVA... Oo

[rica]

Still seeing subtitles while i'm getting DTS HD - MA bitexact over ReClock using lav filters and i can see the blue light on my AVR's display:

http://img824.imageshack.us/img824/9241/testcci.png (http://imageshack.us/photo/my-images/824/testcci.png/)

http://img856.imageshack.us/img856/6131/test2q.png (http://imageshack.us/photo/my-images/856/test2q.png/)

_ _ _ __

[Andy o]

It has never supported DXVA.
Wait, I get DXVA when I choose EVR and HW accel in LAV, or is MPC-HC misreporting it?

[Andy o]

Plus, IIRC, didn't nev or someone find that with LAVCUVID, it bumps the card to full clocks, negating any real power savings? Or was that fixed?

It does with my GTX460 but you can tame the clocks with Nvidia Inspector. But power savings are not really the problem, and depending on your setup, DXVA might not even make a difference with CPU decoding, or even consume more.

I have to use CUVID to get good deinterlacing, for instance. My C2Q Q9450 just can't handle it.

[SamuriHL]

Wait, I get DXVA when I choose EVR and HW accel in LAV, or is MPC-HC misreporting it?

MPC-HC is misreporting. If you're using CUVID it's not DXVA....exactly. :D Although I think the deinterlacing stuff uses the DXVA API's if I'm not mistaken. DXVA doesn't (easily) allow you to copy the decoded video frames from the videocard's memory to system memory. That's why madVR doesn't work with it (currently) and why many of us prefer either CUVID if we're running nVidia, or LAV Video software decoding if we're running AMD. MPC-HC, however, loves to misreport DVXA.