LAV Filters - DirectShow Media Splitter and Decoders

[clsid]

The Intel driver applies some processing filters when using DXVA2. You can disable that in driver settings.

[clsid]

Got a bug report where a Matroska file contained more than 64 tracks.

So I tried increasing MAX_TRACKS to 80. But things got unstable and freezes. Even got a process stuck and unable to kill. Are more changes required?

I also noticed that in FFmpeg Matroska encoder, MAX_TRACKS is set to 126.

[nevcairiel]

Matroska files in LAV Splitter are limited to 64 tracks. Changing that would require quite some work.

[arapaz]

Hi,

I have a 3d video in a .mkv with a full side-by-side image (3840 x 1980)
The mkv has flags for multi view count and layout.
When played with MPC-BE/LAV/MadVR (3d set to auto), the output is not framepacked sent to the TV, it is the original image.

Is it possible that LAV split the image in 2 views and send that to MadVR as 3d ?

Thnaks

[josey_wells]

First, let me say that LAV Filters is a fantastic product, and I have been utilizing it for more than a decade.

With my current configuration of Pot Player, MadVR, LAV Filters, and HDMI receiver, any version of LAV filters above V0.80.0-7 Beta with audio bitstreaming enabled hangs on startup. If bitstreaming is disabled then no hang occurs.

To rule out all other causes, I have used other players such as MPC-BE & MPC-HC, other renderers such as EVR, and other HDMI receivers.

It would be appreciated if this could be looked at.

[Sunspark]

I was playing again with decoding methods the other night. I've always maintained that there is a subtle visual difference besides the native one which we know has issues.

AI says that I am not imagining things, that there actually is a difference with quicksync decoding with older Intel hardware due to this and that reason. Also goes on to say that because of fixed-function, etc. there can also be very subtle differences between software decoding and dxva2-copyback.

Came across this 2011 article today, it's not about LAV, but it does discuss software and hardware decoding so it might be of interest for some. https://www.tomshardware.com/reviews/video-transcoding-amd-app-nvidia-cuda-intel-quicksync,2839.html

[nevcairiel]

The truth of the matter is that there is one correct way of decoding any codec newer then MPEG-2 (MPEG-2 still had some inaccuracies in its IDCT that doesn't make it bitexact), any other methods are factually wrong.

- DXVA2-CB (and D3D11-CB) has been proven to be identical to software decode on any semi-recent hardware, so both of those are "perfect" as software decode is tested against the reference.
- DXVA2-Native has some issues not with decode, but with the way renderers access the image - its not designed to get a perfect version of the image for further processing, instead its really designed to shove it into DXVA2 Video Processing, which puts you at the mercy of the driver/hardware.
- D3D11 Native does not have this issue, and gives you access to the perfect pixel data, if thats used correctly

If any of those above are not true, then the driver does some undue processing, or the decoder is not up to the specification. Of course any hardware in history may have had issues, but video hardware from 15 years ago as in that article is practically unusable by now. Very old Intel stuff was indeed a bit weird with decode, but thats been over with for 10 years or so.

[nevcairiel]

First, let me say that LAV Filters is a fantastic product, and I have been utilizing it for more than a decade.

With my current configuration of Pot Player, MadVR, LAV Filters, and HDMI receiver, any version of LAV filters above V0.80.0-7 Beta with audio bitstreaming enabled hangs on startup. If bitstreaming is disabled then no hang occurs.

To rule out all other causes, I have used other players such as MPC-BE & MPC-HC, other renderers such as EVR, and other HDMI receivers.

It would be appreciated if this could be looked at.

You'll have to elaborate a bit more. Others seemingly are not reporting any issues, so it must be something specific for your use.

Does this happen with all files, any particular ones? Are you bitstreaming all codecs? Did you try different audio renderers?

And can you confirm that issue did indeed start with 0.80.0-9? (versions are available at https://files.1f0.de/lavf/nightly/)

[flossy_cake]

Hello nevcairiel and thank you as well

Question tho: is AI correct in telling me that when LAV is decoding a soft telecine MPEG2 DVD remux mkv which is 23.976p with repeat flags, LAV ignores the repeat flags and outputs 23.976p, but actually still provides the repeat flags to the downstream renderer and the renderer applies the repeat flags thus the renderer creates a 59.94p output from the 23.976p stream with 3:2 judder that is visible even at 119.88hz display mode? Because that is consistent with what I'm seeing and just wanted to confirm this behaviour, thank you.

[nevcairiel]

LAV will certainly not apply soft-telecine for you, but it will forward the flags to the renderer. That part is correct. If the renderer applies it, is out of my control.
Note that a strict soft-telecine stream may have video frame timestamps that already match a 60fps cadence, just with gaps. You can commonly observe this with MPEG-2 streams from HD-DVD (eg. .evo files), so even if you don't apply the field/frame repeating, the judder would be there due to that.

[flossy_cake]

LAV will certainly not apply soft-telecine for you, but it will forward the flags to the renderer. That part is correct. If the renderer applies it, is out of my control.
Note that a strict soft-telecine stream may have video frame timestamps that already match a 60fps cadence, just with gaps. You can commonly observe this with MPEG-2 streams from HD-DVD (eg. .evo files), so even if you don't apply the field/frame repeating, the judder would be there due to that.

Thanks.

My method to determine that is to use MPCVR's debug overlay which reports the real time frame rate coming out of LAV (the first of the two fps values in the overlay).

For anyone else reading this and wondering how to remove the 3:2 judder, the two simplest ways are:

1. Tag the file name with [deint=film] which MadVR will see and will perform decimation 59.94p -> 23.976p (MadVR debug reports 3:2 cadence detected). Or:

2. Set display mode to 23.976hz. This seems to work by coincidence since a 59.94 3:2 cadence if selected from every 23.976th of a second just happens to result in a 1:1 cadence of the original source frames

There are other methods but they are beyond the scope of this post

[huhn]

LAV will certainly not apply soft-telecine for you, but it will forward the flags to the renderer. That part is correct. If the renderer applies it, is out of my control.
Note that a strict soft-telecine stream may have video frame timestamps that already match a 60fps cadence, just with gaps. You can commonly observe this with MPEG-2 streams from HD-DVD (eg. .evo files), so even if you don't apply the field/frame repeating, the judder would be there due to that.

hardware decoder did soft telecine to hard telecine in the past i need to recheck that.
software clearly didn't and works as you said.

[nevcairiel]

DXVA/D3D11 certainly doesn't even have the ability to do that, as it would require producing more frames then input, which the interface is not capable of. Also, its not even given the metadata. The other hardware decoders are deprecated (in part due to such odd behavior, wouldn't be surprised if this was QuickSync)

[huhn]

i noticed that issue in the 900 series maybe cuvid? i had an intel 4000 CPU too.

so the interface that deints is different from the decoding one? one of these clearly can create more frames then the input.

and yes mpcVR has issues with softtelecine dvds with 60 HZ cadence frame stamps. not an lavfilter issue it gives all the information to fix that with the repeat flags.

[flossy_cake]

For testing purposes here's a short clip of the format in question which contains some scrolling patterns to visualize 3:2 judder

https://drive.google.com/uc?export=download&id=15z1Y0VGg1Wg8iqPCJDXEwdcL4llgvq-9

[Sunspark]

Hi, with the NUC connected to the TV over HDMI these days I am seeing some values that I wonder if they are supposed to be that way.

Unlike before when it was using the 3.5mm and the Realtek driver, currently it is using the Intel Display Audio driver which is used for HDMI. In the properties for it, it says it supports hdcp, dolby digital, and 16, 20 and 24 bit.

With LAV audio decoding, I see it saying output 32 bit.. shouldn't that change to 24? Or is it Windows that changes it? Where it gets trickier with this is that the 32 value remains whether the player is in shared mode or exclusive mode.

Likewise, if I do something like change Windows default to 16 bit 44100 and look at LAV again, it still says 32 bit 48000 output.. regardless of whether the player is in shared mode or exclusive mode.

The sound seems fine, but I find it strange.

I believe it is using PCM because this is a TV not a receiver, and the HUD on the TV says PCM if I click on info on the remote.

So to recap, in the first part, should it not change to 24 because the driver says that is what is supported? In the second part if in shared mode, change to 16 or whatever because that is what Windows is reporting as the system mixer value? (Ignore system mixer is not checked here for this test.)

PS. I have also been doing the downmixing to stereo on the PC side instead of having the TV do the mixing.

[nevcairiel]

LAV Audio will always prefer to output whatever it decodes into. Its typically the audio renderer that changes it to match your audio device.

[Sunspark]

Part of why I am confused here is because if the driver properties only say 16-24, then where is 32 coming from? The input is 32, but the output is also 32. When I compared the same file using the MPC decoder, it said the input was 32 and the output was 24. Different decoders and different renderers.. so in this case, LAV is paired with Sanear. But if it's a renderer issue then shouldn't Sanear know that the driver only reports 24?

[huhn]

cause lossy audio is more accurate if it is decoded to float instead of int.

float 32 is the default format for lossy audio.
int 32 should be used if forced or the audio is actually 32 bit.

[nevcairiel]

Part of why I am confused here is because if the driver properties only say 16-24, then where is 32 coming from? The input is 32, but the output is also 32. When I compared the same file using the MPC decoder, it said the input was 32 and the output was 24. Different decoders and different renderers.. so in this case, LAV is paired with Sanear. But if it's a renderer issue then shouldn't Sanear know that the driver only reports 24?

The actual decoder always outputs whatever it outputs, there is generally no choice. So audio has to be converted at some point to match what the audio device wants.

Ideally, you do this conversion in the audio renderer. So LAV Audio outputs 32-bit float because thats what the decoder outputs. SaneAR then converts it to 24-bit for the audio hardware.

If you do downmixing in LAV, then the audio also naturally turns into floating point, since its more accurate to do mixing in floating point.

The audio renderer can also request LAV Audio to do this conversion, but its better to do it as late as possible, so LAV showing output of 32-bit is generally a good thing.

[josey_wells]

You'll have to elaborate a bit more. Others seemingly are not reporting any issues, so it must be something specific for your use.

Does this happen with all files, any particular ones? Are you bitstreaming all codecs? Did you try different audio renderers?

And can you confirm that issue did indeed start with 0.80.0-9? (versions are available at https://files.1f0.de/lavf/nightly/)

Thank you for the response. I am bitstreaming all codecs, and it was happening with all files. I did not try different audio renderers.

So having just gotten back, I downloaded several versions of the nightly LAV filters so I could trace down which one was causing the issue.

However, I could not replicate the issue and am now running the 0.81.0-6 Beta.

The key difference between my machine and others is probably that I am running Windows Server 2025 Standard as the OS instead of a Windows 10 or 11 variant. So it seems that the February 2026 cumulative update resolved this issue which has been going on for about the last 6 months which required running 0.80.0-7 Beta.

[Blight]

I'm trying to decode an Apple Pro res file, it seems to be using a subtype not supported by LAV or any video renderer (it may be RAW):
MEDIASUBTYPE_aprh {68727061-0000-0010-8000-00AA00389B71}

You can download it from here (4.1gb):
https://f005.backblazeb2.com/file/MotionCam-Public/2025/ProResRAW_vs_MotionCamRAW/02%20sources/01_A001_09211049_C068.mov

This is the original page where I got it from:
https://f005.backblazeb2.com/file/MotionCam-Public/2025/ProResRAW_vs_MotionCamRAW/ProResRAW_vs_MotionCamRAW.html

Can LAV Video Decoder support this?

[flossy_cake]

If you do downmixing in LAV, then the audio also naturally turns into floating point, since its more accurate to do mixing in floating point.


Regarding downmixing a 5.1 to stereo, could you please clarify if AI is giving me bad information regarding the clipping protection feature...

AI is saying that when I enable clipping protection , and the downmix contains clipping resulting from the downmix (due to channel summing that occurs during downmix), then LAV will reduce the global volume until it's no longer clipping, and then AI says it will raise the global volume back up to where it was before after the clipping frames/blocks of audio are finished.

The bit in blue seems wrong to me. I am observing that after a loud clipping gunshot, the global volume reduces, and then stays at this lower level for the remainder of the audio track, even after I seek to an earlier point in the video before the gunshot occured - is this the correct and intended behaviour?

:thanks:

[nevcairiel]

Clipping protection does never let up again during normal playback.

[flossy_cake]

Clipping protection does never let up again during normal playback.

Cool, that seems right. I tested that on versions 0.75 and 0.80 and got the same result on both.

I can see in the changelog you wrote "Clipping protection is no longer reset on seeks" and I challenged AI on that and it seemed AI kind of admitted it was wrong but then still doubled down on its initial error:

https://i.imgur.com/7Cshxjr.png



I reckon it would be cool if there was an option in LAV to allow returning the volume to normal after say 10 seconds of no clipping. 10 seconds is what Dolby uses for their "music standard slow" DRC algorithm. i.e the decay parameter slowly and gradually restores the gain back to where it was over 10 seconds to avoid volume "pumping".

I tried living with LAVs clipping protection but it's no good for me because the volume is too inconsistent - one loud gunshot or explosion and now BOOM the volume of dialogue is now all quiet and needs manual adjustment half way through the movie.

I know you are aware of this and is why you put "normalise matrix" to avoid that, which is good, and I'm using that for now. I can use normalise matrix and then follow that with Avisynth Normalize() to get full and consistent volume. I can also use SoxFilter("compand") to implement all the Dolby DRC curves but it can't handle seeking and takes forever to initialise cause Normalize has to scan the whole audio track from start to finish to find the loudest peak (which includes running it through SoxFilter compander first to find the resulting peak after that) so it's not very practical.

Here are the benefits I can think of for adding an optional decay on the clipping protection:

1. It's a realtime solution that doesn't require prescanning the entire audio track

2. It allows through full volume where possible (unlike normalize matrix)

3. It wouldn't suffer from volume pumping if the decay is set to something longer like 10 seconds

4. The amount of CPU processing is negligible and its probably only a few lines of code

[Sunspark]

I dealt with the issue a long time ago by turning clipping protection off. I have full-range speakers. I figure it's needed more for headphones and tracks that operate close to the limit.

You can work around it by using loudness equalization in the soundcard's drivers (or the player's normalization function).. soundcard works better for no-effort, but if you use mpv you can tune quite a lot of parameters for compression, normalization, etc.

[flossy_cake]

You can work around it by using loudness equalization in the soundcard's drivers (or the player's normalization function).. soundcard works better for no-effort, but if you use mpv you can tune quite a lot of parameters for compression, normalization, etc.

The problem is I've tried those DRC options but they all sound bad to me with volume pumping especially during music in a beat frequency with kick drums or other loud percussive hits. Dolby's DRC is better designed to avoid pumping and have lots of profiles to choose from, but it's not a realtime solution due to technical issues which I wont go into.

Anyway I generally try to avoid using DRC because it's not the true volume level of the content. It's a bit like using dynamic contrast on the TV. Peak normalisation is how you get full volume without pumping and preserving the original artistic intent in relation to volume, but that requires scanning the entire audio track prior to playback to find the loudest peak, so that's not a realtime solution either.

LAV offers 2 realtime solutions (normalise matrix and clipping protection)

Normalise matrix reduces the volume to avoid clipping caused by downmixing, and there is no pumping, but results in a very quiet volume due to it allowing overhead for potential peaks due to audio track summing during downmixing, and therefore needs a pass of peak normalisation afterwards to correct that, which we can't do because it would take too long to scan the entire track as mentioned and is beyond the scope of what LAV does.

This leaves clipping protection which would be great if it decayed to 0dB with a long decay time to avoid pumping. However this would still not improve a source that was recorded with a low peak volume in the first place (some audio tracks are mastered with huge amounts of dynamic range headroom for explosions, and these would not be normalised in any way, but this is the artistic intent so I wouldn't want to change it anyway personally).

Another possible solution -- and I recall mentioning this to nevcairiel before -- is for LAV to look for tags in the file path telling it what gain to apply. The user could then do their own offline peak normalisation batch-processing of all videos in their library to scan for loudest peak and tag the file name as such, eg. "C:\MyVideo [gain=6dB].mkv" and LAV sees the [gain=6dB] tag and applies that once at the start of playback.

[flossy_cake]

Actually Sunspark you could be right and a combination of these settings might be acceptable to me:

LAV: normalize matrix enabled, clipping protection disabled

At this point the output of LAV's downmixer is guaranteed free of clipping, pumping or volume changes that weren't in the source. But the overall volume is very quiet due to the matrix allowing headroom for channel summation, so peak normalization is needed:

MPC-HC Audio Switcher: normalize enabled, regain volume disabled

Disabling regain volume should prevent pumping caused by a constant pattern of "loud-quiet-loud" samples in the source, such as found in music.

However there could still be instability of the overall volume if a movie starts with quiet dialogue , then loud explosion, then more quiet dialogue afterwards. In this case, after the explosion, the dialogue will be quieter than before the explosion. To mitigate this, reduce the "max amplification" value to something where it's less noticeable.

But this is a limitation of realtime processing and the only way to solve it is to scan the whole audio track prior to playback and find the loudest peak, which isn't really practical.

Well actually in foobar2000's replaygain the scanning is quite fast but when you have 6 channels to scan that takes 3x longer.

AI says Libav/ffmpeg contains functions for scanning the whole audio track to find the loudest peak, so maybe this would be a better option to have.

[Sunspark]

Is there a lot of stuff that clips? I've never noticed it, but I don't have good hearing. :)

[flossy_cake]

Is there a lot of stuff that clips? I've never noticed it, but I don't have good hearing. :)

To be clear, it's not the content that contains clipping, it's LAV that is causing clipping when it downmixes to stereo, due to the summing of channels which can make them mathematically exceed 0dB. So it's an issue with the very practice of downmixing and honestly I was surprised to recently learn this. Those 2 LAV options "normalize matrix" and "prevent clipping" have nothing to do with normalizing the source levels, they only relate to dealing with clipping caused by LAV itself due to its own downmixing.

This little sidequest began for me a couple of days ago when I was looking at Breaking Bad S03E07. On this loud gunshot frame, the 5.1 source being output by LAV , i.e with no downmixing done by LAV, is not clipping, and Avisyth's Normalize filter scanned the entire track and found the loudest frame only had 0.1dB of clipping:

https://i.imgur.com/w8TIZ2L.png

Now with LAV downmixing to stereo, we have 5.74dB of clipping above 0dB:

https://i.imgur.com/UBYQTWN.png

The "amplify DB" value is from the Avisynth Normalize filter which is reporting how much it had to adjust the volume by to avoid clipping on the loudest frame which is the one being screenshotted (66562).

So anyway, I think the solution I was asking nevcairiel for (the "prevent clipping" but with a decay back to full volume) would be achievable with MPC-HC audio switcher's Normalize set to 100% (which means don't increase volume) and "regain volume" ticked too (so it will raise back to 100% level after reducing it due to its clipping detection) and then disable both "clipping protection" and "normalize matrix" in LAV so that MPC-HC's switcher deals with the clipping instead of LAV. Although I don't know how long its regain decay length is, will need to do some testing on that to see if it creates pumping.

In the end, I don't think this problem is solvable if the root cause is that summing channels will always result in higher levels. So you just have to put up with some volume anomalies when downmixing.

edit: and actually that is correct too because 3 speakers sound louder than 2 when all are outputting the same volume. According to AI the extra speaker (center) would result in something perceptually like 1.8dB louder for all 3 front speakers combined.

[nevcairiel]

If you don't downmix the LFE, then clipping is relatively rare even in a stereo downmix, at least from a 5.1, from 7.1 its of course more severe as its even more channel.

[flossy_cake]

If you don't downmix the LFE, then clipping is relatively rare even in a stereo downmix, at least from a 5.1, from 7.1 its of course more severe as its even more channel.

I have always used your default downmixing settings which is center 1.00, surround 0.71, LFE 0.

If it's as rare as you say, then maybe I'll just let it clip? To be honest I never actually noticed any audible clipping while watching anything on my 5" JBL monitors so maybe it's a minor issue.

But on that gunshot scene, I tested just now and MPC-HC Normalize 100% + Regain volume sucessfully lowered the gunshot without affecting dialogue on other scenes, so maybe that could be good too.

https://i.imgur.com/yiPst39.png

And be sure to untick "Apply DRC for formats AC3/EAC3" on Audio Settings tab because I heard some sources that used that metadata really poorly with audible pumping like Stargate SG1 and Beverly Hills Cop 2 DVD in the intro sequence when Axel revs the engine it goes unusually quiet.

[Sunspark]

@flossy_cake Try dropping the surrounds to 0.50. See what happens on your graph.. I've been using 0.50 lately instead of 0.71 for the surrounds. Helps with spoken dialogue for me. The rest of the Mixing pane settings in the screenshot are the same.

I don't use the normalize in the player because the one in the realtek sound driver worked better for me.. you need to be in shared mode for it though, otherwise it has to be what HC has if you're in exclusive mode.

There's another mixer you can try too with HC (also shared mode), the Windows mixer. Go to your control panel (old control panel) and open sound, go through the wizard and make sure full-range is selected.. then go to properties for the audio device you're using and ensure it's a good setting like 24/48000 so it won't be resampling your video. Now in LAV uncheck mixing and in HC make sure "ignore system mixer" is not checked.. so what's going to happen now is that LAV will decode the source and it will be Windows doing the downmixing using their own coefficients which are not the same as LAV's. Try your graph again with the Windows mixer.

Lastly, if you want a full array of knobs and dials, you can do a fancy mixing job using https://equalizerapo.com/ It's overkill for me so I don't use it, but if you really need to dial something in, this is basically the only thing you can get that is free on Windows.

[flossy_cake]

@flossy_cake Try dropping the surrounds to 0.50. See what happens on your graph.. I've been using 0.50 lately instead of 0.71 for the surrounds. Helps with spoken dialogue for me. The rest of the Mixing pane settings in the screenshot are the same.


Pretty much the same

https://i.imgur.com/yum8TZH.png


It must be the the summing of the 3 fronts circled in red that is causing it. The 4th bar is LFE, 5th and 6th are surrounds.

https://i.imgur.com/FepV0Up.png

[flossy_cake]

I don't use the normalize in the player because the one in the realtek sound driver worked better for me..

The way I've got it set in the screenshot won't do much for boosting quiet dialogue or any sort of DRC type thing that you're probably after. All it will do is the same as clipping protection in LAV but with the added benefit of restoring it back to the original volume level after the clipping stops so that subsequent quiet dialogue won't be too quiet.

What I don't understand is why MPC-HC's normalizer makes the gunshot sound perceptually quieter. I was expecting it to sound the same volume but just without clipping, since both the clipped and unclipped versions are going to end up at 0dB at the optical cable going to my speakers anyway (apparently optical PCM uses integer values which can't exceed 0dB). I need to get some third party tools to debug the output levels of MPC-HC's normalizer.

[Sunspark]

I remember now, when I was playing around with HC's Normalize+Regain, I felt that 100% was not a good setting, and that's what you have set in the screenshot. Try 200% instead. 400% is too loud.

Everyone has their own different implementation of how it should work. VLC's is decent, MPV's is very customizable but you really need to know what you're doing. BE's gain control is terrible and should not be used, but their AC-3 DRC works well if the source has good metadata.

[flossy_cake]

I remember now, when I was playing around with HC's Normalize+Regain, I felt that 100% was not a good setting, and that's what you have set in the screenshot. Try 200% instead. 400% is too loud.

I deliberately set it to 100% to avoid pumping. At 100% it doesn't raise the volume at all, it normalises to 100% which means "don't boost the volume, just leave it at 100%" which would mean something like "mutliply by 1.0" which just equals itself. So it's like passthrough.

But because the feature is still active, it's still monitoring for clipping above 0db (such as what comes out of LAV's downmixer) and reacts to that by reducing the level to avoid clipping when detected.

Then, the "regain volume" feature ensures it is raised it back to 100% after the clipping ends, which helps because then you aren't stuck with quiet dialogue after a loud explosion went into clipping for the first time.

In other words, it's the same as LAV's "clipping protection" but with the added benefit of raising it back to 100% afterwards, which is exactly what I was begging nevcairiel for earlier.

This is good for me, but not necessarily good for everyone eg. if the source was mastered with huge dynamic range where the dialogue is SUPPOSED to be quiet in relation to explosions, and you want to listen to the audio quietly at night on a modest speaker setup. In that case you'd need a DRC solution and can achieve that by raising the value above 100% to something like 200% which I would agree is a better setting than the default 400%. But then you will probably get some pumping due to the decay curves which I don't know how the MPC author has set up.

I am only familiar with the Dolby DRC curves - "music light fast" and "music standard fast" are my go-to's. From memory, "music standard fast" was causing some pumping on the intro song to Family Guy and I had to switch to the light preset. There probably isn't a one-size-fits-all solution that works perfectly for all content types. I often wondered how TV networks do it and I suspect they have metadata for each program being aired that would act as a hint for automated systems to choose which DRC curve would suit that content type. For news and sitcoms for intsance, they might choose the Dolby "speech" DRC curve. I suspect these Dolby DRC curves are what's used to create the AC3/EAC3 metadata for that other DRC feature.

[starsat]

Hello,

Could somebody take a look on this test Transport Stream file?
https://filebin.net/3amgivcfkmiohow1
It is playing correctly on mine RTX 4060 only if I'll select NVIDIA CUVID.
Playout through both DXVA (native/copy-back) and D3D11 gives macroblocks, like the TS file would be damaged, but it is not.

[Aleksoid1978]

Stream is incompatible with DXVA decoders.

[starsat]

There's no doubt about that ;)
But what exactly makes this stream unplayable? Looks quite normal for me, AVC High@L4.1, 4:2:0, 8-bit, BT.709, 1920x1080.
This can be improved?

[huhn]

you try to get this to amd nvidia intel and hope they improve that for the next generation but beyond that reencode?

on the other hand this is Separate Field Coding which is very unusual to me. usually mbaff is used. that's maybe the one thing the hardware decoder can not handle or is missing to do a proper decode
or get's and it actual is mbaff honours SFC and falls flat?

something like that.

[starsat]

Thanks, so in fact this can be fixed only on HW level?

As a curiosity - additional stream with issues on DXVA, but here I have 2 samples taken from different time.
This service seems to dynamically changing something and one sample is unplayable, but other, taken just few hours later - is playable.
https://filebin.net/owg6sml9thygult1

[flossy_cake]

Hmm, new member, 3 posts, wants us to play a weird glitched file. Nope! Could be some kind of buffer overflow attack to make the decoder do something it isn't supposed to.

[starsat]

Everybody was a new member at some point ;)
I'm just a satellite TV viewer, I'm using AltDVB app as my viewer and observed such behaviour for a long time, but I was never able to understand why (very rarely) this is happening.
I finally found some time to register and prepare samples and that's the whole story ;)

Last sample is from Equ TV from Hot Bird: https://www.lyngsat.com/tvchannels/it/Equ-TV.html
I saw this also on NHK World Japan from Hot Bird: https://www.lyngsat.com/tvchannels/jp/NHK-World-Japan.html
And the first sample is from some feed. All files are just a clean TS satellite recordings.

But of course no pressure on anybody, I was just curious if this is a bug and can be fixed or it's not a bug and nothing can be done about this.

[flossy_cake]

Well, you sound human so I guess I'll take you on face value. Lest we all become radical skeptics.

In my experience, .ts recordings off my Enigma-based PVRs can be glitched due to the splicing not being done to the nearest GOP or however it works when the PVR chooses to start/stop the recording mid way through the stream.

You can use ffmpeg to check the file for errors


"C:\program files\ffmpeg\bin\ffmpeg.exe" -v error -i "C:\Recording.ts" -f null NUL


It probably will have errors but that doesn't mean it should be unplayable, just an indicator of the severity

Then use ffmpeg to remux it to a .mkv file, and ffmpeg will effectively repair it as much as possible


"C:\program files\ffmpeg\bin\ffmpeg.exe" -i "C:\Recording.ts" -c copy "C:\Repaired.mkv"

[starsat]

Thanks for reply ;)
I've run these commands, for first I have some:

[h264 @ 000001c3bc63d700] sps_id 0 out of range
[h264 @ 000001c3bc63d700] non-existing PPS 0 referenced
[h264 @ 000001c3bc63d700] sps_id 0 out of range
[h264 @ 000001c3bc63d700] non-existing PPS 0 referenced
[h264 @ 000001c3bc63d700] no frame!

But I see the same messages also for good files (which are playing fine). Just the count differs - sometimes there are a bit more of these, sometime a bit less. E.g. the first sample produces the smallest count of these messages.

The attempt to save as MKV (also tried MP4) does not improve the playback, but if I do the lossy conversion:

.\ffmpeg.exe -i "H:\DXVA playback issues\20260222_0633 FTS-10842000H-DAV.TS" -vcodec libx264 -acodec aac "repaired.mp4"

Then file plays fine :) But that won't help for the live playback, because the issue is also visible during live playback - so if I have DXVA2 (native or copy-back) or D3D11 selected - I've got the same playback issues live. Only switch to CUVID helps.

What is even more puzzling - these two mentioned channels from Hot Bird satellite doesn't always have the issue visible. E.g now NHK plays fine, but Equ TV - does not.

This is definitely not a signal issue, because recording has got no lost packages inside.

Also to exclude that it is a player issue - instead of AltDVB I tried on TransEdit (part of DVBViewer package) with LAV Video/LAV Audio just to see the same issue on DXVA2, but not on CUVID.

That's how it plays - first photo from live playback from DXVA2, second from CUVID

https://i.ibb.co/MxpmTh4b/equ-dxva.png (https://ibb.co/W4FL93wQ)

https://i.ibb.co/1GTSgDVL/equ-cuvid.png (https://ibb.co/d4DhTd9r)

[flossy_cake]

Thanks for reply ;)
I've run these commands, for first I have some:

[h264 @ 000001c3bc63d700] sps_id 0 out of range
[h264 @ 000001c3bc63d700] non-existing PPS 0 referenced
[h264 @ 000001c3bc63d700] sps_id 0 out of range
[h264 @ 000001c3bc63d700] non-existing PPS 0 referenced
[h264 @ 000001c3bc63d700] no frame!

But I see the same messages also for good files (which are playing fine). Just the count differs - sometimes there are a bit more of these, sometime a bit less. E.g. the first sample produces the smallest count of these messages.

The attempt to save as MKV (also tried MP4) does not improve the playback, but if I do the lossy conversion:

.\ffmpeg.exe -i "H:\DXVA playback issues\20260222_0633 FTS-10842000H-DAV.TS" -vcodec libx264 -acodec aac "repaired.mp4"

Then file plays fine :) But that won't help for the live playback, because the issue is also visible during live playback - so if I have DXVA2 (native or copy-back) or D3D11 selected - I've got the same playback issues live. Only switch to CUVID helps.

What is even more puzzling - these two mentioned channels from Hot Bird satellite doesn't always have the issue visible. E.g now NHK plays fine, but Equ TV - does not.

This is definitely not a signal issue, because recording has got no lost packages inside.

Also to exclude that it is a player issue - instead of AltDVB I tried on TransEdit (part of DVBViewer package) with LAV Video/LAV Audio just to see the same issue on DXVA2, but not on CUVID.

That's how it plays - first photo from live playback from DXVA2, second from CUVID

https://i.ibb.co/MxpmTh4b/equ-dxva.png (https://ibb.co/W4FL93wQ)

https://i.ibb.co/1GTSgDVL/equ-cuvid.png (https://ibb.co/d4DhTd9r)



If the corruption only exists at the very start and end of the file due to those being the clipping points by the PVR, try clipping 30 seconds off the start and end with eg. for a 10 minute clip

"C:\program files\ffmpeg\bin\ffmpeg.exe" -ss 00:00:30 -to 00:09:30 -i "C:\Recording.ts" -c copy "C:\Repaired.mkv"

ffmpeg has other options for repairing files without transcoding, ask ChatGPT or Grok

[starsat]

Thanks, I'll try that, but having in mind that this also affects live playback between DXVA and CUVID, I'm not sure if we're heading the right direction here ;)

[Sunspark]

As a curiosity - additional stream with issues on DXVA, but here I have 2 samples taken from different time.
This service seems to dynamically changing something and one sample is unplayable, but other, taken just few hours later - is playable.
https://filebin.net/owg6sml9thygult1

Both samples are playable for me.. one clip is 3 guys at a table talking, and the other is mostly part of a commercial with a landscape view.

Ran test with VLC.

So, for lavfilters, does it make a difference if you change the decoder to software (none)?

[starsat]

Thanks, I've made some check across players:
- VLC 3.0.23 x64 - issue visible
- VLC 4.0 x64 (latest nightly) - issue visible
- MPC BE 1.8.9 x64 - issue visible
- MPC HE 2.6.3 x65 - issue not visible by default, but after checking the settings - it has got set DXVA2 (native) and plays only because Active Hardware Accelerator is "<none>". After switching to copy-back - issue shows up.

So, for lavfilters, does it make a difference if you change the decoder to software (none)?

Yes, in case of software (none) - files are also playing fine.

It seems thay if HW acceleration will kick in - it will damage playback of these specific channels (live) or streams (files).

But why CUVID plays the channels/files fine? It isn't HW decoder?

I'll try also to upgrade nVidia drivers for my GTX 4060 in a minute and I'll return with results ;)

EDIT: New nVidia drivers didn't help.

Some more tests on MPC BE

Preferred decoder:
D3D11, DXVA2 - fail
DXVA2 - fail
D3D11cb - fail
D3D12cb - fail
NVDEC - ok, stream plays fine