LAV Filters - DirectShow Media Splitter and Decoders

[CruNcher]

@nevcariel

i and Clsid a like was wrong the DXVA Power Saving Frequency fluctuations seem to have nothing todo with the Playback stability issues for DXVA Native on VP7 GTX 970 (GM204) it must be something else but it makes no sense,what is happening here ? :(

Lav Video DXVA Native

http://i2.sendpic.org/t/ur/urZXHZRUfqCBDuh6iP8Y7WqZvY4.jpg (http://sendpic.org/view/2/i/o5NmFsOU8aEiG714hE5ZlgTJcR4.png)


Disabled Adaptive Power Management now Memory and Core Frequency are stable with DXVA Native but still these Frametime explosions that final result are unbelievable heavy Playback Stutter/Jitter with peaks upto 12x ms.

Lav Video Cuda (NVCuvid)

http://i2.sendpic.org/t/gt/gtNChHJEkbIsGczcrkGRLbz8vkd.jpg (http://sendpic.org/view/2/i/s9ncJNuhjnp4nlYIlhmrAbroVAd.png)

The NVCuvid Decoder has no issues but it's to heavy (overkill) for most not so complex H.264 4K Streams for example @ the 1126 Mhz core clock it triggers constantly without going lower.

GPU Power of 50% is way to High for not as complex H.264 4K Streams 20% seems totally enough for the VP7 4K H.264 (DXVA Native) Decoder part.

But most probably not an option as Nvidia won't give anyone access to the CUDA Frequencies and they don't Adaptively change here.

Though i most probably give up with Nvidias H.265 Decoder in GM204 and go with CPU (OpenHevc) for any Stream complexity (Bitrate,Tools) for now the High complexity 4K 10 bit ones won't play even on the CPU (i5-2400) Fluid (not even in the slightest way) and even most of the complex 8 bit ones crush the VP7 and the CPU to the Ground.

And all of them are even not the highest complexity Samsungs NX1 Stream really brakes it down to the ultimate of 4 FPS for just a camera pan @ what 80 mbits :D

[rock]

video ts doesn't look good when play with dxva-native

I can't upload my own file (because limited of internet) but I hope its same to be a sample
http://pan.baidu.com/wap/link?uk=2937249676&shareid=448183&third=0

my specs:
Intel HD 3000
Win 8.1 64bit
MPC-HC Nightly 1.7.9.190

[wanezhiling]

You should upload to sendspace, nevcairiel can't download files from pan.baidu.com because of extremely slow speed.
And what do you mean 'doesn't look good', at least a screenshot like this (seems to work fine here) (http://i.imgur.com/di4gQmj.png), please.

Well, SNB HD3000 is known as a bad hw decoding gpu, check other player (mpc-be etc.)

[rock]

You should upload to sendspace, nevcairiel can't download files from pan.baidu.com because of extremely slow speed.
And what do you mean 'doesn't look good', at least a screenshot like this (seems to work fine here) (http://i.imgur.com/di4gQmj.png), please.

Well, SNB HD3000 is known as a bad hw decoding gpu, check other player (mpc-be etc.)
link deleted

thats another same file with my files that affected (different than first one though)
I can't upload since my internet really slow, it could take hour(s) maybe just to upload that.

same result with mpc-be.
it looks fine with potplayer dxva-native

I don't what words to explain that, but you could see the details look on the lip and fingers, also on the second video, you could see that.

added screenshot as suggested
http://imgur.com/a/abo2q

[wanezhiling]

Don't share torrent here, it's not allowed!
No difference here, mpc-hc(lav dxva), mpc-be dxva, potplayer dxva, all same.
While Im using hd4600.

And again, offer two screenshots (pot fine v.s mpc not good), otherwise nobody can help you, that's all.

[romulous]

Hi nev,

Sample file with two subtitles streams (Telextext and DVB), yet it appears only one is exposed (DVB). Sample:
https://mega.nz/#!4t41nRgA!JOC4KHpQH88upPj9iwI75KZp8rcz-rKiLjLwRBM3LTg (71MB)

MediaInfo:
Text #1
ID : 5303 (0x14B7)-888
Menu ID : 8931 (0x22E3)
Format : Teletext
Language : English

Text #2
ID : 5304 (0x14B8)
Menu ID : 8931 (0x22E3)
Format : DVB Subtitle
Codec ID : 6
Duration : 1mn 56s
Delay relative to video : -300ms
Language : English

Would appreciate if you could take a quick look and give some advice.

romulous

[nevcairiel]

There is no DirectShow type for teletext, thats why it ignore them.
I'm also not aware of anything in DirectShow that can decode them.

[wanezhiling]

There is no DirectShow type for teletext, thats why it ignore them.
I'm also not aware of anything in DirectShow that can decode them.
http://i.imgur.com/cqoTuj6.png

[LigH]

So maybe Potplayer (only) can do that on its own? This screenshot is no proof that a "DirectShow filter" is responsible.

[Konrad Klar]

Why teletext could not be transformed into subtitle stream (inside DS infrastructure)? Is that source radically different from text files, or subtitles embedded in MKV, or MP4?

[jkauff]

It's been a long time, but IIRC teletext is part of the video stream. I don't think it's accessible as text.

[LigH]

Depends on the video system.

For NTSC, there used to be a "line 21 decoder" for analogue video signals containing such information in the pre-video gap (during the vertical blanking). When the video is already digital, it won't contain pre-gap data in its usual form anymore and will have added "Closed Captions" packets in the video stream (they can be extracted e.g. with CCExtractor). Keep in mind: SD NTSC composite video only. HD video formats won't be able to emulate this system via DVI/HDMI digital connections.

Analog PAL TV uses a different kind of "Videotext" in the vertical blanking gap which is not respected in DVD specs in a similar way. DVB-TXT is in separate substreams.

[nevcairiel]

Teletext is not related to "Closed Captions" (which line 21 would be).

In any case, teletext is not plain text data, its binary image data. Its transmitted as separate streams in a MPEG-TS container, and not as part of the video.

[amayra]

long time no see stable ver ?

[LigH]

Regarding DVB, the ETSI appears to be responsible with documents like EN 300 472 (DBV TS multiplexing), EN 300 743 (DVB-SUB format), "DVB BlueBooks" in general. The primarily responsible filter in a DirectShow chain would be the splitter, to demultiplex it for a decoder creating a video overlay. But if the DirectShow system has no "media type" defined for DVB teletext, there won't be any filter feeling responsible for connecting. And indeed - the MSDN lists no DVB text related media type (https://msdn.microsoft.com/en-us/library/ee495731.aspx) (only Line 21 CC).

[jkauff]

Teletext is not related to "Closed Captions" (which line 21 would be).

In any case, teletext is not plain text data, its binary image data. Its transmitted as separate streams in a MPEG-TS container, and not as part of the video.
Thanks for the clarification. The last time I encountered teletext was in the analog video days when it was one of the non-picture elements of the NTSC signal.

[Nullack]

Hi, I'm fiddling around with some interlaced content in both TFF and BFF on lav filters 6.0.33 GIT using MPC-HC. I'm running a 4K display and Ive configured the video decoder to use DXVA2 native. When set to native none of the de-interlacing options for hardware can be enabled - its all greyed out with the notice CUVID/Qs only. So that leaves the software deinterlacing YADIF. If I untick this, I still get deinterlaced video for some reason. So where is it coming from? I'm on an NVIDIA GTX 960 and have inverse telecine disabled in the control panel. Im trying for testing reasons to see the interlaced frames.

[pie]

In any case, teletext is not plain text data, its binary image data.

It's not image data - it's text encoded in a specific format - most of the subtitle text is encoded with odd parity IIRC (see ETS 300 706)

I know that if you use the standard Windows demuxer for WTV/DVR-MS files, the teletext stream is exposed with media type MEDIATYPE_MSTVCaption

[huhn]

Hi, I'm fiddling around with some interlaced content in both TFF and BFF on lav filters 6.0.33 GIT using MPC-HC. I'm running a 4K display and Ive configured the video decoder to use DXVA2 native. When set to native none of the de-interlacing options for hardware can be enabled - its all greyed out with the notice CUVID/Qs only. So that leaves the software deinterlacing YADIF. If I untick this, I still get deinterlaced video for some reason. So where is it coming from? I'm on an NVIDIA GTX 960 and have inverse telecine disabled in the control panel. Im trying for testing reasons to see the interlaced frames.

you are using DXVA native so lavfilter can't touch the stream after uploading anymore. so the renderer has to take care of the interlaced stream in this case.

[Nullack]

Thanks. EDIT: I found it in the deinterlacing mode section to the left of the video config tool. As Im curious, when you have say auto or force or aggressive for the mode with interlaced content, and you have the other two deinterlacing types disabled, what actual deinterlacing type is used by the renderer? Is there a reason someone would elect to enable the software yadif over the un-named type? Thanks

[Vasilich]

In any case, teletext is not plain text data, its binary image data.
as pie already said, teletext is not image data, it is text (binary) data. romulous asked about DVB teletext, and it is described in ETSI EN 300 472. What you meant is probably DVB subtitles, that are image data.
Here (https://github.com/petrkutalek/telxcc) is the example implementation of DVB teletext parser - it can process TS files with the speed up to 1GB/s, that you will never achieve when processing image data :) , and the guessing of selection of proper teletext page for subtitles always worked for me (at least for german broadcasters).

[mzso]

Hello!
I'm quite sure I used to be able to play fullHD videos with hadrware acceleration (cuvid) with my GTS450. But now I can't. Cuvid is by far the worst. It's as if watching a slideshow. DXVA modes at least play kind of fluidly with many framedrops/ repeated frames (according to madVR). Copy back seems to perform best with the repeated frames stagnating only the dropped frames increasing.

[LigH]

Do you rely on Microsoft's drivers from Windows Online Update? Or do you update with drivers from Nvidia's website?

[nevcairiel]

Also, I generally do not recommend using CUVID at all, anymore. Its somewhat limited in comparison to DXVA2 modes, and especially on Windows 10 its quite a bit broken, since NVIDIA discontinued part of the functionality it uses.
It'll probably get blacklisted on Windows 10 in an upcoming LAV version, because it doesn't even deinterlace properly anymore on 10, which is the main reason people seemed to use it.

[vanden]

Does LAV H264 Decoder With more than 16 threads is possible ?

[LigH]

Do you have at all AVC video with more than 16 slices per frame, so that you need more than 16 threads per frame to decode at all?

[vanden]

I dont't know how slices per frame ...

It's a x264 encode 2160p 50fps 45mbs (http://infonetservices02.chez.com/NoiseRed-50fps-45mbs.mkv)

it worked perfectly with my old system (Mac Pro 2008 / Win7x64 / 2xXeon E5462 2.8GHz / 8 Cores).
But with my new (HP DL580 G5 / Win2012R2 / 4xXeon E7450 / 24 Cores) it's limit, and the processor does not exceed 40% ....


Or another H265 sample (http://www.elecard.com/assets/files/other/clips/140626_4k_hm130_4s_sao_dbf_qp27.265) (remuxed with MKVToolnix @ 50fps) : same problem.
On MacPro env 45fps CPU @ 98%
On DL580 env 45 fps CPU @ 30-40% ...

Or another (worst) H264 2160p 60fps 35mbs : BigBunny2160p-60fps (http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_2160p_60fps_normal.mp4)
On MacPro 60fps (perfect) CPU @ 58% :
On DL580 env 55 fps (complet loss of synchronization) CPU @ 30-40% ... :

[chros]

Also, I generally do not recommend using CUVID at all, anymore. Its somewhat limited in comparison to DXVA2 modes, and especially on Windows 10 its quite a bit broken, since NVIDIA discontinued part of the functionality it uses.
It'll probably get blacklisted on Windows 10 in an upcoming LAV version, because it doesn't even deinterlace properly anymore on 10, which is the main reason people seemed to use it.
But please, don't disable it on Win8, on my system I can watch high bitrate (~100Mbps) 4k x264 30fps samples reliably with it but not with copyback (when bitrate goes high then stuttering begins).
If you need a sample I can upload one if you want to take a look at it.
Thanks!

[yonta]

LAVSplitter doesn't seem to handle a file with a big audio delay very well.
This sample (https://drive.google.com/file/d/0B1mCVSSmbT2LN0E2MGlkdkd4aTQ/view?usp=sharing)(793Mbytes) has 112 seconds audio delay so the video should be played without sound for 112 seconds.
But using LAVSplitter mpc-hc shows blackscreen and just hangs there. If I skip to any point before 1:52 it shows a still picture and hangs there. If I skip to any point after 1:52 it plays fine with audio in sync.
I tried mplayer, mpv, vlc, ffplay and they all play it just fine.

[nevcairiel]

Thats a DirectShow limitation, if an audio stream is present it also expects audio to start playing, otherwise the reference clock doesn't move properly and everything gets stuck.

[yonta]

Thats a DirectShow limitation, if an audio stream is present it also expects audio to start playing, otherwise the reference clock doesn't move properly and everything gets stuck.

I also tried KODI and potplayer32 (both latest dev.) and they played it just fine. Don't they use DirectShow?

[nevcairiel]

Kodi does not, and it really depends on the audio renderer in question. If it moves the reference clock without audio, its going to work fine. If it doesn't, it gets stuck.
From what I remember, ReClock used to run its reference clock based on the hardware clock, independent of received audio. Could try that.

I don't know of a way to trick the audio renderer to start playing anyway.

[kasper93]

Seems to work fine for me with MPC-HC though.

[yonta]

Seems to work fine for me with MPC-HC though.

filters list?

[nevcairiel]

LAV Filters 0.67

LAV Splitter
- NEW: Support for HTTPS URLs
- NEW: Automatic selection of the highest quality variant in HLS streams
- Changed: Reverted back to the old ASF demuxer
- Changed: Backported ASF seeking improvements to the old ASF demuxer
- Fixed: ASS in AVI did not work in recent versions
- Fixed: RTP/RTSP did not work properly in 0.66

LAV Video
- NEW: Improved DVD subtitle and menu drawing with madVR (support for madVRs subtitle repositioning and lower latency)
- Changed: HEVC and 4K HWAccel is enabled by default
- Changed: Enabled DXVA2-CB Direct Mode with YV12 output on 8-bit sources
- Fixed: DVD menus could show a black screen instead of the menu in some situations

LAV Audio
- Fixed: Improved clipping behavior in badly mastered DTS-HD tracks

Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.67.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.67.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.67-x64.zip)

I'm going on vacation soon and wanted to release this before, so that I can focus on a bunch of new things after getting back.
This release contains mostly maintenance, and a few new features like HTTPS support, which was asked for a couple times.

Otherwise new is support for drawing DVD menus and subtitles directly through madVR, which lowers the latency of interactive menus, and allows madVRs subtitle moving logic to be used.
A recent version of madVR is required, 0.89.10 or newer.

For the next version after this one, I have a few changes planned for hardware acceleration, mostly involving a new settings UI for them and a bit more flexibility like allowing fallback to DXVA2-CB if Native doesn't work.
On top of that, I have been working on VP9 DXVA2 support, and it will also be part of the next release, but its not quite done yet. VP8 is also in the pipeline, but I need a Intel drivers first that support VP8 DXVA2, which should appear sometime in the future.

As always, if you encounter a problem, especially if its a regression, please report the problem in as great detail as possible, with a test-case to reproduce it if applicable, so it can be fixed more easily.

Have fun and take care!

[NikosD]

LAV Filters 0.67
On top of that, I have been working on VP9 DXVA2 support, and it will also be part of the next release, but its not quite done yet. VP8 is also in the pipeline, but I need a Intel drivers first that support VP8 DXVA2, which should appear sometime in the future.


It is a pity to wait for Nvidia to fix their broken drivers in order to release your VP9 DXVA decoder, since it already works for Intel.
VP8 DXVA is a different decoder and nobody supports it right now.

You released your HEVC DXVA decoder when only Nvidia had already available the suitable driver, without waiting for Intel.

It's not fair and it looks like a biased decision.

[nevcairiel]

You are free to draw your own conclusions, but thats not the reason, and I never stated that.
There is a big gap between it kind-of working so I can start testing it, and it being release-worthy.

Its just not done yet, and my time is rather limited these days.

[NikosD]

I draw my conclusions based on your words in my thread, that you have finished VP9 DXVA decoder and it's working for Intel but not for Nvidia.

You said that the code has finished and it works, not me.

It's your app and your call, but it is clear the close connection with Nvidia only.

[huhn]

LAV Audio
- Fixed: Improved clipping behavior in badly mastered DTS-HD tracks

what does this fix do? does it lower the general volume output in general, is it doing it when clipping is detected that can be avoid by lowing volume or something totally different?

[nevcairiel]

If you want to be nit-picky, this is what I specifically said

VP9 DXVA works on Braswell/Skylake with my code now.

That however does not mean its "finished". It works on a few test samples, however it still lacks quite a bunch of things that would make it release worthy, like checking if the stream is hardware compatible, fallback to software, integrating it into LAV (since the hwaccel was developed in ffmpeg, not LAV), and so on.
Like I said, draw your own conclusions if you want, but it has nothing to do with hardware support. Its just a product of time and priorities.

On top of all that, it currently requires a pre-release Windows SDK to build, so until the final Windows SDK is released that includes the necessary information about the VP9 DXVA2 support, its rather wonky anyway.

I should probably stop talking about any in-development things in the future, they could upset someone.

[nevcairiel]

what does this fix do? does it lower the general volume output in general, is it doing it when clipping is detected that can be avoid by lowing volume or something totally different?

It just flatlines clips instead of overflowing the audio and causing even more audio artifacts. There is no attempt made to "fix" clipping, since that would be rather inconsistent during playback.

[huhn]

would a general -3 DB help for these situations?

if i'm not mistaken the audio renderer can't fix such issues.

and i'm totally aware that this isn't lossless anymore.

i'm talking about this post from you and the idea behind it: http://forum.doom9.org/showpost.php?p=1746496&postcount=13646

i would trade lossless decoding anytime for "error/bad mastering resilience". same for the down mix LFE issue.

[nevcairiel]

In theory it could, but reducing the volume of every single DTS encode just for the chance of one in hundred clipping once? Doesn't seem very appealing to me.
If you do a 2-pass process like eac3to, thats a different topic, but during playback..

[huhn]

In theory it could, but reducing the volume of every single DTS encode just for the chance of one in hundred clipping once? Doesn't seem very appealing to me.
If you do a 2-pass process like eac3to, thats a different topic, but during playback..

i know and that's why it can't be a default option and must be on extra option. some people will not accept this and this totally fine with me.

but i will never be able to notice the volume difference as long as it is the same over the whole track. but clipping can be a huge issue.

in the end most people doesn't use 100% volume output to get "lossless" and this tweak doesn't touch bitstreaming.

[aufkrawall]

Really looking forward to VP9 hardware decoding.
Is there a chance that Google will some day make use of 10 bit with it? Or will it rather be called "VP10"?

[huhn]

VP10 is allready in the work as a new codec.

[nevcairiel]

Really looking forward to VP9 hardware decoding.
Is there a chance that Google will some day make use of 10 bit with it? Or will it rather be called "VP10"?

VP9 supports 10-bit, however the DXVA2 specification only allows for Profile 0, which is 8-bit 4:2:0.
Profile 1 adds 4:2:2 and 4:4:4, Profile 2 is 10/12-bits in 4:2:0, and Profile 3 is all the features at the same time (10/12 bit and 4:2:2 or 4:4:4)

[Superb]

I should probably stop talking about any in-development things in the future, they could upset someone.Please don't. Some of us appreciate your hard work and are happy you share these status updates.

[aufkrawall]

VP9 supports 10-bit, however the DXVA2 specification only allows for Profile 0, which is 8-bit 4:2:0.
Profile 1 adds 4:2:2 and 4:4:4, Profile 2 is 10/12-bits in 4:2:0, and Profile 3 is all the features at the same time (10/12 bit and 4:2:2 or 4:4:4)
Thank you for these information. :)

[DarkSpace]

Another idea (though you probably considered that already): Can you just switch to floating-point audio output when you encounter such clipped passages, and output the out-of-range values as they are? The audio renderer could then decide whether to lower the volume (e.g. when the output volume is less than 100% anyway), and in the end, it could still flatline...
Or, if you can't just switch the audio format mid-stream, how about an option to output DTS-HD files as floating-point in general? That still seems nicer to me than just "hard-clipping" the audio.

I'm aware that I'm worrying about an issue that I'll probably never encounter. However, on the off-chance that they turn out useful, I wanted to have mentioned those ideas...