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

clsid

1st February 2015, 16:58

This post details a buffer/queue hack to improve stability during network streaming.
http://forum.doom9.org/showthread.php?p=1707887#post1707887

Perhaps you can think of a more proper way to improve on existing behavior? Does a larger default queue size have any disadvantages other than higher memory usage and startup delay? Maybe the min queue size could be made dependent on the max size and total free memory. Something like at most half the max queue size and at most a quarter/eight of total free mem.

nevcairiel

1st February 2015, 17:02

Startup delay is a significant disadvantage. The current buffers are for about 1 - 1.5 minutes of video, if your WiFi is that terrible, you should invest in a new one.
I suppose I could make it configurable, but people tend to shot themselves into the foot when giving the option to do so...

clsid

1st February 2015, 18:00

It is not a problem that I have personally, but an option would be useful considering that apparently there are people who do have issues. The tooltip could of course warn about the increased delay.

bilditup1

1st February 2015, 19:15

What happens if you feed the original timecode file into mp4fpsmod, instead of x264's output? They should be the same, since x264 doesn't add or drop frames, but the TDecimate version is definitely correct -- or the cause of the other problems. Make sure you use tcfv1=False in TDecimate though, to generate v2 timecodes.

I have since generated the timecode v2 file using TDec. When I inputted it into x264, automatic timebase generation failed again. After manually entering the numerator for the timebase, 1001, timebase generation succeeded and the encode proceeded. The resulting timecodes_v2 file from x264 appears to be the same except for every third frame in the 20000-30000 range being rounded up by .00001, and the use of UNIX instead of CRLF line endings (which resulted in a smaller file).

After muxing with either timecodes file, however, the audio progressively slipped further and further behind the video on MPC-HC 1.7.8 (have not tested them on the iPad).

I also did an encode without inputting a timecodes file, and then muxed the resulting .264 with the TDec-generated timecodes. Exactly the same result.

Should I post the timecodes here? Or the first few minutes of muxed files that keep going out of sync?

kasper93

1st February 2015, 19:30

It is not a problem that I have personally, but an option would be useful considering that apparently there are people who do have issues. The tooltip could of course warn about the increased delay.

I agree with that. I've heard about issues with insufficient buffering a lot. Especially with live streams where data flow can be unstable.

SeeMoreDigital

1st February 2015, 20:17

Oh wow...

I've just discovered I can play DSD.dsf audio files using LAV 0.63.0.41-git and MPC-BE 1.4.4 (build 66) beta - Amazing work :)

nautilus7

2nd February 2015, 01:17

@Nev

Hi, I have a video file (https://mega.co.nz/#!ixhkBaTb!h15OTDcw90FaE0d1ThORuopxO9xHCve9PQWYg9-4BUY) that doesn't playback using mpc-hc with internal LAV filters. It is a satellite capture (DVB-S2) and VLC can playback it fine. Could you please have a look what is wrong? Thanks.Any update? :)

Nintendo Maniac 64

2nd February 2015, 02:28

My CPU (Pentium G3220) does not support HEVC decoding but I tested H.264/720p file. DXVA Copy-back in 0.67 nightly LAV works much better compared to intel QuickSync decoding.

Half the CPU usage with pure decoding and higher speed with lower CPU usage with rendering! Very nice. Thank you nev!
Do you have more specific details on what kind of video you are using? On a 1080p 60fps 8bit h.264 video my CPU usage on my Pentium G3258 is still the highest with Copy-back followed by QuickSync in the middle and then Native with the least CPU utilization.

EDIT: I tried again with a 720p 30fps 8bit video but this time underclocked my CPU to 800MHz so that it would definitely stay in the lowest pstate, and even then my CPU usage followed the same as I described above. And yes I'm using the 0.67 nightly.

For reference I used the following as my guinea pig for both test cases (ftm299 for 1080p60, fmt22 for 720p30):
https://www.youtube.com/watch?v=5I-nQtsJuhE

EDIT 2: You know the bug where 10bit h.264 videos don't playback in MPH-HC on the newest Intel GPU drivers unless you set the LAVfilters to "none"? Well I figured out a "fix" outside of disabling LAV's 10bit decoding - just add and enable the "ffdshow raw video decoder" to MPC-HC external filters and suddenly you'll have a working video.

SeeMoreDigital

2nd February 2015, 10:38

Any update? :)Interesting...

The MPEG-2 video stream has been encoded using 4:2:2. Its use is usually reserved for up-linking outside broadcast content to a studio. It's not intended to be viewed by the public :eek:

nevcairiel

2nd February 2015, 10:53

Any update? :)

Your stream does not have any key frames, and because of that its not supported.

Do you have more specific details on what kind of video you are using? On a 1080p 60fps 8bit h.264 video my CPU usage on my Pentium G3258 is still the highest with Copy-back followed by QuickSync in the middle and then Native with the least CPU utilization.

The new mode is only active in a clean "direct" output scenario (decoding -> nv12 output, no yadif, no nothing). And when its active, it will definitely reduce CPU usage, and more than likely below the level of QuickSync.

You can check if its on by checking the config page, it should say "dxva2cb direct" instead of just "dxva2cb"

EDIT 2: You know the bug where 10bit h.264 videos don't playback in MPH-HC on the newest Intel GPU drivers unless you set the LAVfilters to "none"? Well I figured out a "fix" outside of disabling LAV's 10bit decoding - just add and enable the "ffdshow raw video decoder" to MPC-HC external filters and suddenly you'll have a working video.

The "fix" required is to convert the 10-bit video to 8-bit, if you do that in LAV by disabling P010 and P016 output, or add a ffdshow processor doesn't change whats happening. The only difference is that I know that LAVs 10->8 conversion is high quality and dithered properly, and fast at the same time, which are things I cannot guarantee for ffdshow.

nautilus7

2nd February 2015, 14:03

Interesting...

The MPEG-2 video stream has been encoded using 4:2:2. Its use is usually reserved for up-linking outside broadcast content to a studio. It's not intended to be viewed by the public :eek: Yes, indeed.

Your stream does not have any key frames, and because of that its not supported.But, since libavcodec can decode it, why not support it in lav filters?

-TiLT-

2nd February 2015, 14:27

LAV just outputs the audio/video as they are in the file. I could explain more, but thats what it comes down to, and thats where it already ends. You cannot have two audio streams with different timings in the same file and magically expect it to work, it just won't, and it never will.
"stretch by" doesn't work with audio, it'll result in endless glitching. stretching only works with video or subtitles, however if you have two different audio timings, you can of course not sync to both at the same time, so what you are trying to do is just not going to work.

The only way to solve it is to timestretch one of the audio tracks and reencode it. There are high-quality time stretchers around that do not alter the pitch of the audio, so the quality loss is minimal.

Did you actually read what I wrote?

I exactly said what you repeated, I even worked out what is missing for a perfect solution.
Secondly, high-quality time-stretchers only exist for specific, mostly academic scenarios. There is no good general purpose stretcher on the market. Most aren't even acceptable. Without sophisticated tuning the results are horrible.
Timestretching is not an option.

Anyway, it is a rare szenario, if LAV is not meant to deal with it, it is obviously better to keep it general purpose.

:sly:

nevcairiel

2nd February 2015, 16:09

But, since libavcodec can decode it, why not support it in lav filters?

Because I require key frames in mpeg 2 streams for now, and there is no way to change that without causing regressions for other streams.

detmek

2nd February 2015, 16:16

Do you have more specific details on what kind of video you are using? On a 1080p 60fps 8bit h.264 video my CPU usage on my Pentium G3258 is still the highest with Copy-back followed by QuickSync in the middle and then Native with the least CPU utilization.

EDIT: I tried again with a 720p 30fps 8bit video but this time underclocked my CPU to 800MHz so that it would definitely stay in the lowest pstate, and even then my CPU usage followed the same as I described above. And yes I'm using the 0.67 nightly.

For reference I used the following as my guinea pig for both test cases (ftm299 for 1080p60, fmt22 for 720p30):
https://www.youtube.com/watch?v=5I-nQtsJuhE

EDIT 2: You know the bug where 10bit h.264 videos don't playback in MPH-HC on the newest Intel GPU drivers unless you set the LAVfilters to "none"? Well I figured out a "fix" outside of disabling LAV's 10bit decoding - just add and enable the "ffdshow raw video decoder" to MPC-HC external filters and suddenly you'll have a working video.

Nothing special. I just tried with the clip you linked:
720pCB:
http://www.dodaj.rs/t/3h/Cf/1ZFhxik/720pcb.jpg (http://www.dodaj.rs/?3h/Cf/1ZFhxik/720pcb.png)
720pQS:
http://www.dodaj.rs/t/Y/aV/TbQcaFh/720pqs.jpg (http://www.dodaj.rs/?Y/aV/TbQcaFh/720pqs.png)
1080pCB:
http://www.dodaj.rs/t/1W/sS/MgBu89L/1080pcb.jpg (http://www.dodaj.rs/?1W/sS/MgBu89L/1080pcb.png)
1080pQS:
http://www.dodaj.rs/t/2M/84/3r4nDcE1/1080pqs.jpg (http://www.dodaj.rs/?2M/84/3r4nDcE1/1080pqs.png)
Driver version - 10.18.10.3960.
LAV nightly 0.67
DXVA Checker 3.3.2 x64

clsid

2nd February 2015, 18:41

Would it be possible to also have a YV12 direct output mode? Filters such as vanilla VSFilter and ffdshow raw video filter don't support NV12 input.

STaRGaZeR

2nd February 2015, 18:51

Nev, what is this new direct mode all about? It's just using SSE4 instead of SSE2 or is there something more to it?

nevcairiel

2nd February 2015, 19:53

It uses an optimized 1-step (direct) operation to get the video frame from the GPU to the renderer, instead of the generic 2-step process it used before. The advantage is obviously speed, the disadvantage is that it doesn't work when you need to do any processing like YADIF, or pixel format conversions, which is why it has to be specifically implemented for every single case (because reading from the GPU has certain restrictions as well, if you want full speed anyway).

madshi

2nd February 2015, 20:08

Have you done a benchmark? How much faster is it? :)

nevcairiel

2nd February 2015, 20:09

Speed is limited by the hardware decoder before and after mostly, maybe with a 10% increase (bringing it closer to the speed of DXVA2-Native), but CPU usage is halfed in many cases.

A huge advantage can be seen when dealing with 10-bit 4K HEVC on the GTX 960, not only half CPU usage there, but also 80-100% more speed because it became a real bottleneck due to the extra large frames.

madshi

2nd February 2015, 20:22

Sounds good. Btw, does HEVC DXVA (native) already support 10bit output? If so, which format are the surfaces to be expected in? I think madVR currently only supports DXVA NV12 surfaces...

nevcairiel

2nd February 2015, 20:25

The surfaces out of the decoder are P010, but EVR also doesn't like them, so I disabled it in native mode. Somehow I doubt Microsoft is going to change that for DirectShow EVR anytime soon, so it'll probably remain disabled.

madshi

2nd February 2015, 21:09

So basically you're enforcing copyback for 10bit HEVC? What if I add support for P010 DXVA surfaces? That said, I don't know how DXVA deinterlacing would deal with them. What kind of hardware would I need to test that?

nevcairiel

2nd February 2015, 21:11

The NVIDIA GTX 960 is the only card which supports 10-bit decoding so far.
The DXVA2 Processor Devices support P010 input on NVIDIA mostly, but not output, so you can deinterlace it .. but only to NV12.

madshi

2nd February 2015, 21:16

Have you actually tried DXVA P010 output? The processor devices have a quite limited number of "reported" capabilities, but they often support more than advertized. E.g. at least AMD and NVidia can output to 16bit int/float RGB, even 32bit float RGB, although this capability is not reported. So there's a chance P010 could be supported, too. But of course it's just a wild guess, and chances are it won't be supported (yet?).

Edit: Oh, I just remembered: All the new format specifications don't support interlaced, anymore, anyway. So we probably won't ever need to deinterlace 10bit HEVC.

nevcairiel

2nd February 2015, 21:19

HEVC has interlaced in the spec, I'm afraid.
They didn't include fancy coding modes, but you can still code fields individually, and there is metadata in the HEVC headers that tell you how to put it back together.

LAV/ffmpeg does not support that yet, though.

madshi

2nd February 2015, 21:25

Yeah, but neither UHD broadcasts nor UHD Blu-Ray are supporting interlaced in any way. And usually custom encodes are progressive, too. So I don't see where interlaced HEVC content could be coming from. Well, maybe DVB-T HD could do that, but then it will most likely be 8bit, so we'd be at NV12 again. I don't see any likely 10bit interlaced HEVC sources. Just from what I've seen so far, of course. I could be wrong.

kasper93

2nd February 2015, 21:38

Let's hope interlaced 10-bit content will not appear anyway. This would be step back.

Vasilich

2nd February 2015, 22:41

according to Wikipedia https://en.wikipedia.org/wiki/Ultra-high-definition_television#Resolution there is no interlaced content defined for UHD, so even if codec itself can support it, any UHD-compatible source won't have interlace.

e-t172

3rd February 2015, 00:02

And that's awesome. Good riddance! We can finally see the day when we'll be able to forget all about this deinterlace, even/odd fields and other IVTC bullsh*t.

DragonQ

3rd February 2015, 00:23

I agree but it might end up being a poisoned chalice. With HD channels, the broadcasters have to upscale any SD sources, which if done in real-time is invariably done badly (looks worse than simple bilinear). With UHD channels, the broadcasters have to continue this practice but also deinterlace existing 480i/576i/1080i footage. I am not confident most would do this well either.

I'm just disappointed that DVB-UHDTV Phase 1 doesn't include frame rates higher than 60 Hz. Phase 2 likely will but I bet we'll be stuck with hardware and infrastructure only supporting phase 1.

Stereodude

3rd February 2015, 18:58

I tried playing an older DVD (from 1998) over the weekend with MPC-HC 1.7.7 (built in LAV filters). The MPEG-2 video stream is 23.976Hz progressive with a soft 3:2 pulldown applied to it. Long story short, LAV is set to use avcodec for MPEG-2 DVD. It decodes the video but it doesn't report the output video stream as interlaced. Other DVDs I've tried that are similarly encoded with a soft pulldown do report they're interlaced. If LAV is applying a soft pulldown shouldn't it always indicate the output is interlaced?

I can provide a sample later today if that will help.

SeeMoreDigital

3rd February 2015, 19:12

Nevcairiel,

Does the 'LAV Audio Configuration' option actually contain a DSD decoder filter? I can't find an enable/disable option...

Cheers

nevcairiel

3rd February 2015, 19:18

Stereodude

3rd February 2015, 20:44

Soft-Pulldown is progressive content really, so if anything this disc is more correct than others. But at the end it'll just report what the MPEG-2 bitstream says. If it contains a progressive sequence flag, then thats what LAV will use.
Well, something isn't right. When I used the QuickSync decoder option in LAV on the same DVD it reported it was interlaced.

I'd be thrilled if LAV played soft pulldown DVDs at 23.976Hz, ignored the 3:2 pulldown, and reported a 23.976Hz framerate upstream, but that doesn't seem to happen. madVR still shows the framerate as 29.97Hz on the DVDs I've ever tried. The 29.97Hz reported rate causes all sorts of difficulties (like enabling smooth motion if you force a 23.976Hz refresh rate, or preventing the refresh rate from changing).

I've only been able to get correct 23.976Hz playback of DVDs by having the MPEG-2 decoder output "interlaced" video (post 3:2 pulldown) which madVR then IVTC's to 23.976Hz on the fly. This particular disc was a pain because madVR didn't see it as interlaced so I couldn't IVTC it, until I realized I could force enable deinterlacing in madVR.

I realize that it's possible to remove the soft pulldown flagging when demuxing from the .vob's with something like eac3to and remux in a .mkv (assuming the mpeg-2 stream is 100% soft pulldown), but I want to be able to just put a disc in the drive and watch it, not process a disc for 30 minutes to a .mkv first.

foxyshadis

3rd February 2015, 21:34

Yes, indeed.

But, since libavcodec can decode it, why not support it in lav filters?

Why not just tag some frames as key frames, at least the first? Sure, they'll be corrupt until the intra refresh is finished, but that's how it works anyway. Keyless streams are pretty rare, and I'm sure they'd be a pain to support (since seeking would always either be corrupt or have to decode back X frames and hope it's enough).

foxyshadis

3rd February 2015, 21:38

I have since generated the timecode v2 file using TDec. When I inputted it into x264, automatic timebase generation failed again. After manually entering the numerator for the timebase, 1001, timebase generation succeeded and the encode proceeded. The resulting timecodes_v2 file from x264 appears to be the same except for every third frame in the 20000-30000 range being rounded up by .00001, and the use of UNIX instead of CRLF line endings (which resulted in a smaller file).

After muxing with either timecodes file, however, the audio progressively slipped further and further behind the video on MPC-HC 1.7.8 (have not tested them on the iPad).

I also did an encode without inputting a timecodes file, and then muxed the resulting .264 with the TDec-generated timecodes. Exactly the same result.

Should I post the timecodes here? Or the first few minutes of muxed files that keep going out of sync?

Sounds like the problem is in the script or the input, not in the encoding and muxing. Have you checked sync against the original input file? And when forcing 24 fps IVTC (for testing even if it looks jerky)? That'll conclusively rule out a timecode problem.

SeeMoreDigital

3rd February 2015, 22:15

This particular disc was a pain because madVR didn't see it as interlaced so I couldn't IVTC it, until I realized I could force enable deinterlacing in madVR.Which disc is it. Do you have a sample?

Stereodude

4th February 2015, 01:32

Which disc is it. Do you have a sample?
It's 12 Monkeys. I cut a short 1 minute sample (http://stereodude.net/12_Monkeys_trimmed.7z).

I need to recant what I said about the QuickSync decoder in LAV. It behaves differently, but not in the manner I stated earlier. If you force deinterlacing when decoding with QS madVR doesn't see a 3:2 pattern. When decoding with CUVID and avcodec madVR will see the 3:2 pattern when forced to deinterlacing. I am a tad puzzled about how madVR finds a 3:2 pattern when the video output doesn't appear interlaced from any of the decoders. :confused:

huhn

5th February 2015, 14:15

It's 12 Monkeys. I cut a short 1 minute sample (http://stereodude.net/12_Monkeys_trimmed.7z).

I need to recant what I said about the QuickSync decoder in LAV. It behaves differently, but not in the manner I stated earlier. If you force deinterlacing when decoding with QS madVR doesn't see a 3:2 pattern. When decoding with CUVID and avcodec madVR will see the 3:2 pattern when forced to deinterlacing. I am a tad puzzled about how madVR finds a 3:2 pattern when the video output doesn't appear interlaced from any of the decoders. :confused:

i guess the file is soft telecine.
madVR switches to 23p on it own and plays this file totally smooth without using madVR IVTC or deinterlacing.

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Duration : 59s 977ms
Bit rate mode : Variable
Bit rate : 3 437 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.332
Time code of first frame : 00:59:58;15
Time code source : Group of pictures header
Stream size : 24.6 MiB (87%)

Stereodude

5th February 2015, 17:26

i guess the file is soft telecine.
madVR switches to 23p on it own and plays this file totally smooth without using madVR IVTC or deinterlacing.
In my testing it engages Smooth Motion if the PC refresh rate is set to "23p" because the "source filter" reports the frame rate is 29.97Hz. Yes, I know smooth motion can be turned off, but I'm not sure how it handles it then because it still sees a mismatch between the source filter and the display refresh.

If it wants to decode it as progressive that's great, but why then misreport the framerate?

huhn

6th February 2015, 05:54

it looks like madVR is taking these informations from the source filter lav source (madVR OSD: "says source filter"). the source filter clearly says 29p.

smoothmotion = SM

ffdshow with lavfilter as source splitter
SM engages, madVR uses 23p and no deinterlacing or IVTC is used. it is work ok with ffdshow looks like ffdshow is correctly correcting the frame duration. playback is 23p with 23 hz input so madVR SM should not trigger. so there is an issue with madVR looks like madVR uses the source filter and refreshrate informations to trigger SM I wonder why it is able to switch to 23p and why it isn't using this information for SM.

lavfilter
SM engages, madVR uses 23p and no deinterlacing or IVTC is used. looks like the frame duration is not corrected and madVR is blending frames the wrong why. not easy to judge with the sample. SM shouldn't trigger madVR still get's 23p from somewhere.
lavfilter should at least correct the frame duration like ffdshow.

mpc video decoder DXVA and lavfilter source
SM doesn't engages, madVR uses 59p and no deinterlacing or IVTC is used. playback is not smooth at all.

mpc video decoder and lavfilter source
same as lavfilter.

not sure how to fix this or even where the issue is coming from madVR libav?

and I have not tested QS, CUVID and DXVA from INTEL, NVIDIA and AMD and as you can see the decoder has something to do with this.

my display modes:
1080p23, 1080p24, 1080p50, 1080p59, 1080p60

THX-UltraII

6th February 2015, 09:14

Is LAV video filter able to deal with MVC MKV 3D files that are made with Makemkv?

Stereodude

6th February 2015, 13:28

Is LAV video filter able to deal with MVC MKV 3D files that are made with Makemkv?
I'm pretty sure the answer is no, but I haven't tried it. AFAIK, LAV is built on FFMPEG which, AFAIK, can't decode MVC H.264.

THX-UltraII

6th February 2015, 13:59

I'm pretty sure the answer is no, but I haven't tried it. AFAIK, LAV is built on FFMPEG which, AFAIK, can't decode MVC H.264.hmmmm. I m looking for a solution to play 3D movies in MPC-HC + LAV filters + madVR as output renderer......

videonerd

7th February 2015, 10:52

Hi developers, fantastic software. I am using mpchc/madvr/built-in lav.

I observe that using CUVID, seeking is delayed/lag (skip forward/back) however with software decoding, seeking is instant. Is this expected or are there other related settings that may be in play? Nvidia Titan.

Thank you!

LigH

7th February 2015, 11:11

May depend on whether fast seeking is enabled in the player: Either the playback starts immediately at the nearest GOP start (coarse seeking), or it has to decode up to the seek position from the previous GOP start (fine seeking, but delayed playback). Hardware decoding may not support both, but I don't know details here. At least I know that hardware decoding speed may be limited to about realtime in earlier decoding chip generations, while software decoding (especially multithreaded) can be a lot faster.

DragonQ

7th February 2015, 13:55

DragonQ

7th February 2015, 16:44

I've finally found a way of recording the Astra UHD test stream currently broadcasting. I suppose I shouldn't be surprised that my laptop's Core i5-3320M can't cope with it at all, even with MPC-HC x64 + LAV Filters + EVR. :(

It gets 37-40 fps with ~85% CPU usage and ~40% GPU usage. I assume it's using the GPU just for resizing to 1080p.

Wow I didn't realise quite how much better HEVC decoding was in the 64-bit build. The sample works fine on my desktop (Xeon X5650 @ 4 GHz) when using MPC-HC x64, with CPU usage at 20-40% and GPU usage at 20-25% depending on the scene being decoded. With MPC-HC x86, I can't watch it smoothly because some scenes send the CPU to near-100% (12 cores not enough!) and frames are dropped. This is all with EVR by the way, MadVR is a no-go even with all settings at minimal levels.