LAV Filters - DirectShow Media Splitter and Decoders

[Aleksoid1978]

Nevcairiel
LAV Video + NV12 output + VMR7(w) + VMR Mixing mode + YUV Mixing - wrong color at ouptut.
LAV:
http://i.imgur.com/QrSswRA.png
MPC_BE:
http://i.imgur.com/rnvzWZM.png

[itsonlyjustincase]

For example H.264/H.265 CPU/EVR decoding with the iGPU of a SandyBridge as primary, is a lot slower than the exact CPU/EVR decoding with a faster discrete card as primary - with all the other parameters kept same.

This is unexplainable to me.



iGPU was using QuickSync ? Cause iGPU with DXVA is nothing in terms of performance compared to QuickSync so it is surprising

[nevcairiel]

Nevcairiel
LAV Video + NV12 output + VMR7(w) + VMR Mixing mode + YUV Mixing - wrong color at ouptut.

I know whats wrong, and I have a fix, just need to test a bit more.

[NikosD]

iGPU was using QuickSync ? Cause iGPU with DXVA is nothing in terms of performance compared to QuickSync so it is surprising

I didn't test hardware acceleration.
Not DXVA, not QuickSync.

I did several tests with CPU (software decoders only) for both H.265 & H.264.

The unexplainable for me, is that CPU decoders when using a renderer (as always during playback) are dependent by the GPU (hardware, drivers, OS) and have huge performance differences for the same CPU decoder, with different GPU.

So, it seems that there is no such thing as "CPU decoding" in real life playback.
It is always a CPU/GPU thing, even if you choose "software" decoding.

[michkrol]

The unexplainable for me, is that CPU decoders when using a renderer (as always during playback) are dependent by the GPU (hardware, drivers, OS) and have huge performance differences for the same CPU decoder, with different GPU.
The renderers are used obviously for rendering the video and aren't designed for displaying frames faster than the movie's framerate, especially faster than your display's refresh rate, since obviously it's pointless from the perspective of watching the movie.
The renderer uses the GPU to diplay the video, so it's limited by its capabilities, such as memory bandwidth, which you can't overcome.

So, it seems that there is no such thing as "CPU decoding" in real life playback.
It is always a CPU/GPU thing, even if you choose "software" decoding.
Rendering the decoded frame(s) on a display is not part of decoding, it's next step in playback. You can for example send the decoded frames to an encoder to transcode them to another format.

Since we've concluded that LAVFilters' H265 decoder works correctly and performance scales with frequency and cores count, I think we should stop going further off-topic or continue in a separate thread ;)

[NikosD]

The renderers are used obviously for rendering the video and aren't designed for displaying frames faster than the movie's framerate, especially faster than your display's refresh rate, since obviously it's pointless from the perspective of watching the movie.


This is definitely not true.
During benchmarking both CPU decoders and HW decoders can go many times faster than both movie's frame rate and refresh rate like 500fps


Since we've concluded that LAVFilters' H265 decoder works correctly and performance scales with frequency and cores count, I think we should stop going further off-topic or continue in a separate thread ;)

I'm not sure that this true "it works correctly", because all of my problems started when I a C2D@2.83 performed only 15% faster than a C2D@1.66 during playback.

Of course I don't know what nevcairiel can do about that, so I'll come back when I'll have a clean Nvidia win 8.1 system.
I'll do my tests again and if I find something interesting, I'll write again.

[roytam1]

Nevcairiel
LAV Video + NV12 output + VMR7(w) + VMR Mixing mode + YUV Mixing - wrong color at ouptut.
LAV:
http://i.imgur.com/QrSswRA.png
MPC_BE:
http://i.imgur.com/rnvzWZM.png

I know whats wrong, and I have a fix, just need to test a bit more.

Alright I built that branch. :)
http://roy.orz.hm/lavf-w32-nightlies/lavf-my131115-vmr7mix-866679a.7z

[itsonlyjustincase]

This is definitely not true.
During benchmarking both CPU decoders and HW decoders can go many times faster than both movie's frame rate and refresh rate like 500fps



I'm not sure that this true "it works correctly", because all of my problems started when I a C2D@2.83 performed only 15% faster than a C2D@1.66 during playback.

Of course I don't know what nevcairiel can do about that, so I'll come back when I'll have a clean Nvidia win 8.1 system.
I'll do my tests again and if I find something interesting, I'll write again.

Using intel hd 4000 without QuickSync is meaningless. You have to use optimization made for video otherwise it's understandable it wouldn't give good results.

Intel QuickSync beat EVERYTHING in terms of video encoding/decoding

[Vasilich]

The renderers are used obviously for rendering the video and aren't designed for displaying frames faster than the movie's framerate, especially faster than your display's refresh rate, since obviously it's pointless from the perspective of watching the movie.

This is definitely not true.
During benchmarking both CPU decoders and HW decoders can go many times faster than both movie's frame rate and refresh rate like 500fps.
mickrol talked about renderers, and you talk about decoders. Surely decoder doesn't know where decoded content will be rendered, so it has no limitations in speed. But renderer's task is to render, so it knows everything about refresh rate of the display. And it really makes no sense to render (not decode!) faster than the display can show it

[NikosD]

mickrol talked about renderers, and you talk about decoders. And it really makes no sense to render (not decode!) faster than the display can show it

What I wrote about decoders is true for renderers too.

In benchmark mode with EVR for example, you can go as high as your platform can go like 1000fps.
There are no limitations.

[littleD]

I didn't test hardware acceleration.
The unexplainable for me, is that CPU decoders when using a renderer (as always during playback) are dependent by the GPU (hardware, drivers, OS) and have huge performance differences for the same CPU decoder, with different GPU.Sorry for continuing offtop (it should really go to other thread), but i think statement above is obvious for me. There was always some EVR renderer overhead in benchmarks iifc everyone told about on this forum (I am long time reader heh). Evr is close to GPu this means it uses GPU logic for sure. Some decoders like LAv filters or ffdshow can be forced or automated to change colorspace or/and range levels on the fly before it goes to renderer. This means less work for gpu, and little more to CPU. But still there might be some limitations on texture uploading, drivers performance and featutes (like picture enhancements ON or OFF) that can be various among GPU vendors. Check out MadVR test, it might be old and no relevance, but clearly shows difference between gpus. NikosD, you noticed improvements in win8.1 over the win8, this means win 8.1 have some better EVR performance deep in system not dependent on drivers, as u said previously u use some legacy drivers on old rig.
I have checked WDDM 1.3 new features and there might be or not amazing shows off but im sure there are underlying improvements. I might be wrong with better multithreading support, i checked other single thread? decoders (xvid in LAV) and it shows improvement too in win 8.1. Improvement like higher/better cpu utilization. I'm not an expert, maybe some devs could say more what OS improvements are from win 7 to 8.1

[tzr916]

I had to downgrade to v58.2 because v59.1 is not deinterlacing properly. In fact it seems like it's not deinterlacing at all, no matter what Hardware/Software Acceleration option I try. I use Zoom Player with EVR to play US cable Tv shows (1080i mpeg2 wtv). A lot of it is badly flagged 29/59 material (easy to spot the jaggies on channel logos, etc). It looks fine using v58.2 (CUVID, AdaptiveHW, HQ, YADIF) but seems like there is something really wrong with v59.1

[nevcairiel]

Both YADIF and CUVID deinterlacing work just fine for me, and nothing really changed in those areas either, nothing at all really.
Please provide a sample to reproduce the issue.

[balkerman]

Thanks for Lav!

I use mpc-hc, lav, madvr and reclock.

I have an issue which occurs in 59.1 but not in 58.2, have downgraded back.

It has occurred on a few files. At the same point each time the file is played the sound glitches and sends static to random speakers in my surround sound setup. If i disable auto av sync it doesn't occur but av losses sync at that same point. Also it doesn't occur if i bypass reclock. Also if pause and replay after the glitch it fixes itself. The files are mkv, x264 with dts.

Hope this makes sense?

[nevcairiel]

You need to provide a sample file, or there is nothing i can do.
Ideally cut a small part of the file around the area that glitches. You can do time-based segments with mkvmerge, for example.

[balkerman]

Thanks for Lav!

I use mpc-hc, lav, madvr and reclock.

I have an issue which occurs in 59.1 but not in 58.2, have downgraded back.

It has occurred on a few files. At the same point each time the file is played the sound glitches and sends static to random speakers in my surround sound setup. If i disable auto av sync it doesn't occur but av losses sync at that same point. Also it doesn't occur if i bypass reclock. Also if pause and replay after the glitch it fixes itself. The files are mkv, x264 with dts.

Hope this makes sense?

Thanks for the mkvmerge tip, that made the process rather easy.
I have uploaded a sample of the file, the glitch occurs at about 11 seconds in.

https://drive.google.com/file/d/0Bx81dX3o2NZYYUoxU1k3d2V3aUE/edit?usp=sharing

Zip: https://drive.google.com/file/d/0Bx81dX3o2NZYcDNLQnJHc0tTRlE/edit?usp=sharing

[Megalith]

There seems to be a minor bug with video files that carry PCM 5.1 as the default stream; the LAV audio filter doesn't kick in until the audio stream is changed via the LAV splitter.

[nevcairiel]

There seems to be a minor bug with video files that carry PCM 5.1 as the default stream; the LAV audio filter doesn't kick in until the audio stream is changed via the LAV splitter.

PCM doesnt require a decoder, so thats expected.

Thanks for the mkvmerge tip, that made the process rather easy.
I have uploaded a sample of the file, the glitch occurs at about 11 seconds in.

https://drive.google.com/file/d/0Bx81dX3o2NZYYUoxU1k3d2V3aUE/edit?usp=sharing

Zip: https://drive.google.com/file/d/0Bx81dX3o2NZYcDNLQnJHc0tTRlE/edit?usp=sharing

Thanks for the sample, i found the issue and fixed it. :)

[balkerman]

Thanks for the sample, i found the issue and fixed it. :)

Glad i could contribute. Appreciate you having looked into it.

Thanks!

[tzr916]

I had to downgrade to v58.2 because v59.1 is not deinterlacing properly. In fact it seems like it's not deinterlacing at all, no matter what Hardware/Software Acceleration option I try. I use Zoom Player with EVR to play US cable Tv shows (1080i mpeg2 wtv). A lot of it is badly flagged 29/59 material (easy to spot the jaggies on channel logos, etc). It looks fine using v58.2 (CUVID, AdaptiveHW, HQ, YADIF) but seems like there is something really wrong with v59.1

Both YADIF and CUVID deinterlacing work just fine for me, and nothing really changed in those areas either, nothing at all really.
Please provide a sample to reproduce the issue.

Here is a wtv clip (https://drive.google.com/file/d/0B82GqdDf8HSyWlhRVTlxV0ZvSWM/edit?usp=sharing). Focus on the channel logo. I see jaggies (and other stuff) on my HTPC and laptop (both nvidia gpus).

v59.1-
http://imageshack.us/a/img541/8881/dn3a.jpg


v58.2-
http://imageshack.us/a/img201/7753/2foh.jpg

[nevcairiel]

Thanks for the sample, I'll have a look!

[Mercury_22]

@ Nev any chance you can make LAV work with a BD playlist (mpls) in which the audio format is changing (from AC3 5.1 to DTS-MA 5.1) after first m2ts from the playlist ?

e.g a playlist in which the first m2ts has an [eng] AC3 5.1 and a [fra] AC3 5.1 audio tracks and all the other m2ts files from the playlist have [eng] DTSMA 5.1 and [fra] AC3 5.1


P.S. Sorry but a sample is too big to upload

[nevcairiel]

Something like that doesnt really fit into the overall design right now, so not really going to happen any time soon.
Which BD is authored like this? I've never seen one.

[Mercury_22]

Something like that doesnt really fit into the overall design right now, so not really going to happen any time soon.
Which BD is authored like this? I've never seen one.

I've sent you a PM

[nevcairiel]

Here is a wtv clip (https://drive.google.com/file/d/0B82GqdDf8HSyWlhRVTlxV0ZvSWM/edit?usp=sharing). Focus on the channel logo. I see jaggies (and other stuff) on my HTPC and laptop (both nvidia gpus).

I dont see these issues in MPC-HC, so I tried ZoomPlayer.
However, while I see the problem in ZoomPlayer, ZP does not use LAV Video.

How do i get ZP to use LAV for these files? Its filter configuration is a mess. Its set to use LAV for MPEG2, but apparently it does not.

I assume you double checked that LAV Video is actually in use?

[omarank]

Thanks for the mkvmerge tip, that made the process rather easy.
I have uploaded a sample of the file, the glitch occurs at about 11 seconds in.

https://drive.google.com/file/d/0Bx8...it?usp=sharing

Zip: https://drive.google.com/file/d/0Bx8...it?usp=sharing


Thanks for the sample, i found the issue and fixed it. :)

I have observed this (perhaps similar) problem in multiple videos with DTS-MA track. I discovered a way of fixing this problem by applying a low pass-filter of 120 Hz in the LFE channel. I was under this impression that in Arcsoft dll they didn't low pass the LFE channel after decoding. This workaround works perfectly for all files with DTS streams, including the sample shared by Balkerman. Now that you have managed to find out the real cause of the problem, could you please indicate if this was actually related to LFE channel only?

[nevcairiel]

It has nothing to do with the decoded audio or LFE at all. It was just a bug in the parsing of the DTS stream.

For the record, at least DTS HD MA is decoded completely lossless with the arcsoft decoder. What once went in comes out again.

[tzr916]

I dont see these issues in MPC-HC, so I tried ZoomPlayer.
However, while I see the problem in ZoomPlayer, ZP does not use LAV Video.

How do i get ZP to use LAV for these files? Its filter configuration is a mess. Its set to use LAV for MPEG2, but apparently it does not.

I assume you double checked that LAV Video is actually in use?

Oops forgot to mention that ZP does have to be configured to use LAV for WTV. It's pretty simple and works great for me:

http://forum.inmatrix.com/index.php?showtopic=13624

[NikosD]

I've just finished testing LAV CPU H.265 decoder with EVR and Win 8.1 clean signature system.

The results were once again disaster for Nvidia and H.265 bbb_720p_c.ts clip:

C2D@2.83GHz - 69fps (EVR) - 97fps (EVR renderless) - Nvidia GT 610 - Win 8.1
C2D@1.66GHz - 56fps (EVR) - 59fps (EVR renderless) - Intel i945GM - Win 8.1

This is simply UNACCEPTABLE for Nvidia hardware.

There is only one chance that my system is the problem, but I doubt so.
My PCI-E speed is only x4 and PCI-E v1.1, but I don't think this is a bottleneck.

If the above results can be confirmed by other users, then Nvidia GPUs - at least the low cost models for HTPC - SHOULD BE AVOIDED for software decoding.

Use HW acceleration only with them.

[nevcairiel]

610 is the crappiest GPU you could ever buy, it should be avoided no matter what for.

[NikosD]

I got the same results using Win 8 and GT 430 and I thought it was an OS problem.
Obviously it wasn't.

I start to believe that something is not going so well in Nvidia HW (at least the low cost).

Maybe in other thread, other users can report the performance loss using software decoder and EVR renderer for various GPUs.

ATI 5750 has no problem at all.

[nevcairiel]

Any speed you get over the display refresh does not matter at all, anyway.

Anyway, this is off-topic, please stop the discussion now.
If you want to measure decoder performance, you should take any other factors out of the test environment.

[NikosD]

Of course it matters and it matters A LOT.

Because for easy clips you go over the refresh rate, but this is not the matter.

The problem is the HUGE performance drop of "pure" software decoding when using a renderer (playback situation).

So, in a more difficult clip, for example 1080p H.265 you can't even play it in realtime with a C2D@2.83GHz, although based on "pure" software decoding of the same CPU you should!

So if you have for example an ATI 5750 you can playback the clip in realtime with software decoding and if you have a GT 430 card, you can't play it in realtime using software decoding.

This is hilarious!

The CPU/GPU communication using the renderer eats 40% of the CPU decoding with Nvidia cards.

This is a HUGE problem for not so powerful CPU systems, playing tough clips.

I don't think you can do anything about it, but I should mention it because you propose many times CPU decoding over HW decoding and this is not good for Nvidia cards and low CPUs.

I stop the off-topic.

[omarank]

It has nothing to do with the decoded audio or LFE at all. It was just a bug in the parsing of the DTS stream.

For the record, at least DTS HD MA is decoded completely lossless with the arcsoft decoder. What once went in comes out again.

Ok. I am a bit surprised though, as to why Balkerman’s sample and the problematic files which I have play perfectly with the LPF applied to the LFE channel. I am sharing a sample of a problematic file with DTS-MA track. Could you please check if this sample too exhibits the problem due to the bug in the parsing of the DTS-MA stream?

Below is a link to the sample. One way of reproducing the problem is to enable mixing to stereo in LAV audio decoder and set LFE Mix Level to 2.24.

http://www.mediafire.com/?1cptip2ubtecye1

[nevcairiel]

Ok. I am a bit surprised though, as to why Balkerman’s sample and the problematic files which I have play perfectly with the LPF applied to the LFE channel. I am sharing a sample of a problematic file with DTS-MA track. Could you please check if this sample too exhibits the problem due to the bug in the parsing of the DTS-MA stream?

Below is a link to the sample. One way of reproducing the problem is to enable mixing to stereo in LAV audio decoder and set LFE Mix Level to 2.24.

http://www.mediafire.com/?1cptip2ubtecye1

That sample does not show the bug I just fixed.

One thing i noticed is that this stream seem to have high individual channel volume, so when you downmix to stereo, especially with LFE at such a high level, it'll cause the audio to clip, or LAVs clipping protection to engage. After stereo downmix the overall volume spiked to over 250% without clipping protection (without LFE its "only" at 160%)

Your issue seems completely unrelated. The issue in question would only cause that some audio blocks would be missing, and/or could be corrupted during playback. Missing blocks can cause a small gap in the audio which can produce an audible glitch when LAV corrects A/V sync.

I don't see how your thing is related at all. Quite possibly your low-pass mitigated the audible glitch somehow.

[luke823]

Hello all,
If you're interested to look at a new application built around LAV filters, please take a look at Media Browser Theater:

http://forum.doom9.org/showthread.php?p=1653975

[nevcairiel]

Oops forgot to mention that ZP does have to be configured to use LAV for WTV. It's pretty simple and works great for me:

http://forum.inmatrix.com/index.php?showtopic=13624

I still have issues reproducing the issue in your specific setup.

Can you confirm:
- You are using CUVID
- You have CUVID HW Adaptive Deinterlacing ON
- Its actually using LAV Splitter + LAV Video :D

The only time i see a similar looking issue is when i actually turn LAVs deinterlacing off, and deinterlacing is handed off to the renderer. Most renderers dont deal very well with such content.
I can also see it much more obvious if i use Microsofts decoder.

Once CUVID deinterlacing is active, or even YADIF is active (although cuvid looks a bit sharper, still), the issue goes away here.

[tzr916]

I still have issues reproducing the issue in your specific setup.

Can you confirm:
- You are using CUVID
- You have CUVID HW Adaptive Deinterlacing ON
- Its actually using LAV Splitter + LAV Video :D

The only time i see a similar looking issue is when i actually turn LAVs deinterlacing off, and deinterlacing is handed off to the renderer. Most renderers dont deal very well with such content.
I can also see it much more obvious if i use Microsofts decoder.

Once CUVID deinterlacing is active, or even YADIF is active (although cuvid looks a bit sharper, still), the issue goes away here.

Do you happen to know what renderer were you using in Zoom Player?

I am sure LAV Video is in use but I will test v59.1 again.

In the mean time, can you speculate on what is "wrong" with this clip? Why most renderers and the MS decoder cannot handle "them" properly?

[nevcairiel]

In the mean time, can you speculate on what is "wrong" with this clip? Why most renderers and the MS decoder cannot handle "them" properly?

Its simply soft-telecined. Its not really broken either.
The way soft telecine is done is that every other frame is marked as interlaced and repeat, and the frames in between are marked as progressive.

Because of this marking, bad deinterlacers get confused, and don't realize its actually a progressive/soft-telecined video and they dont need to do anything.

I have toyed with the idea before to try to detect soft-TC and just drop the telecine flags, to avoid such confusions on the renderers side, but its sadly not as simple as that.

PS:
I use the default renderer, EVR i guess.

[DragonQ]

Soft telecining is not something I've really come across because most things I watch are from PAL-region sources, but isn't soft-telecining really common on NTSC DVDs? If so, it seems rather crap that most deinterlacers can't handle it properly. I have noticed some occasional repeated/missing/dodgy frames on some videos derived from US HDTV sources that have been converted to 23.976p...is this likely to be because whatever software was used to reverse the telecining wasn't handling the flags 100% correctly?

[tzr916]

Its simply soft-telecined. Its not really broken either.
The way soft telecine is done is that every other frame is marked as interlaced and repeat, and the frames in between are marked as progressive...

Thanks. I was wondering why such a large amount of my content ends up marked this way? Is the defect introduced by my local cable provider? Is it the channel/broadcaster? Is it the the actual production of the content? Does it depend if the content was shot on film or on digital video?

A little more info- I never see the problem on the major networks (ABC, NBC, CBS, FOX). It comes and goes on most but not all of the other cable channels. I can't figure any pattern to it, one show will have it then the next won't (even on the same channel). It's bad in movies on channels like AMC, Syfy, USA, TNT, LIFE, LMN, HBO and in one hour shows on ID, TLC, DISC, SCIENCE, etc.

[madshi]

NTSC/ATSC content (both DVDs and broadcasts) is often partially soft-telecined and partially hard-telecined (jumping around between both variations in the middle of the movie). Add to that bad edits, video overlays and stuff, and it can be non-trivial to deinterlace that properly. In theory DXVA deinterlacing is supposed to be able to deal with this sort of stuff correctly, if you have IVTC activated in the GPU drivers. In real life it often works, but not always, depending on content, GPU hardware and GPU drivers. The most reliably method to play such content back is to use madVR's forced film mode. But that is not very comfortable because you have to manually enable it for film content and disable it for video content. So there is no perfect solution atm... :(

[nevcairiel]

Thanks. I was wondering why such a large amount of my content ends up marked this way? Is the defect introduced by my local cable provider? Is it the channel/broadcaster? Is it the the actual production of the content? Does it depend if the content was shot on film or on digital video?

Its not a "defect" as such, its just a way some channels seem to process their content, while many other channels prefer hard-telecine if they have to reach 29.97 fps.

[e-t172]

For the record, at least DTS HD MA is decoded completely lossless with the arcsoft decoder. What once went in comes out again.

According to Genelec (http://www.genelec.com/faq/multichannel/101-what-is-the-lfe-1-channel/), this is not how you're supposed to decode DTS-HD:

In the DTS-HD codec only [DTS-HD Master Audio™ (lossless) and DTS-HD High Resolution Audio™ (lossy)] the DTS-HD decoder applies a low-pass filter at 100 Hz (-3 dB) with a 60 dB/octave roll-off onto the LFE channel.

I've yet to find an official reference on this, however. DTS specs are not publicly readable, so I guess we'll never know.

[tzr916]

Its not a "defect" as such, its just a way some channels seem to process their content, while many other channels prefer hard-telecine if they have to reach 29.97 fps.
Is it possible to overcome the picture jaggies (and other visible defects) when playing soft telecine content using the MS decoder (WMC)? I've tried three different GPU's (2 nvidia, 1 AMD)

Why can consumer boxes like Tivo handle soft telecine content perfectly but PC's cannot? I had a Tivo with this same cable service for 6 months and NEVER saw this issue. I immediately noticed the picture issues after building my HTPC and using WMC.

[JEEB]

I've yet to find an official reference on this, however. DTS specs are not publicly readable, so I guess we'll never know.
Scroll down this (http://wiki.multimedia.cx/index.php?title=Mirrored_Files) page ;) . DTS wanted to get into broadcasting and it thus had to release a spec of sorts. It does have a lot of things under "get a license and grab the reference implementation from us", though.

[nevcairiel]

Is it possible to overcome the picture jaggies (and other visible defects) when playing soft telecine content using the MS decoder (WMC)? I've tried three different GPU's (2 nvidia, 1 AMD)

Probably not so easily, no.
I don't think you can change much about the TV playback chain in WMC, so not much you can do there sadly.

[madshi]

Why can consumer boxes like Tivo handle soft telecine content perfectly but PC's cannot?
Consumer electronics works quite differently: The decoder always outputs 60i, and then there's a deinterlacer after that. So whether content is soft-telecined or hard-telecined makes no difference there. This is both good and bad. It's "good" because soft-telecined content can't confuse the deinterlacer. But it's "bad" because crucial information is getting lost. Soft-telecined content is actually much easier to deinterlace properly, if you know what you're doing. So in theory, the PC should have an advantage. A PC based deinterlacer has more information available than a consumer electronics deinterlacer. So it should be possible to build a superior deinterlacing implementation for PCs (or at least one with similar quality).

One thing LAV could do is to (optionally) manually convert soft-telecined content into hard-telecined content. But I'm not sure if that's a good idea.

[ddjmagic]

nevcairiel - I hope you don't mind, but I thought I would respond here instead of inside the MB thread. Thanks.

I've asked multiple times, but nevcairiel hasn't been interested in adding that feature to LAV so I doubt it will ever happen there (I think hes too 'proud' because Slysoft can find the playlist better than LAV) anyway thanks for the answers - I definitely will be trying the various MB apps out, they look promising :)

I would implement it, if they actually exported the information on all discs, and not just those discs with that special copy protection (that name i forgot), which is apparently never used in europe and as such i never had a disc with it.

That's the whole point, Screenpass protected discs are the only discs (pretty much) where there is no logical way to determine the correct playlist (without reading the menu's)
Plus if needed the user could manually add the playlist themselves to the 'disc.inf' file, making playlist selection 100% correct every time (I've done this a few times on folder rips)

There are plenty of European discs with this protection, although perhaps none in Germany.

Regardless, I'm sure this would be a pretty easy feature for you to add, and would be an excellent addition to the already wealth of features LAV has.
I'd be grateful if you would consider adding it, as I doubt Slysoft will add the info for every disc :)

[e-t172]

Scroll down this (http://wiki.multimedia.cx/index.php?title=Mirrored_Files) page ;) . DTS wanted to get into broadcasting and it thus had to release a spec of sorts. It does have a lot of things under "get a license and grab the reference implementation from us", though.

Yeah, but nothing on DTS-HD MA, which apparently handles LFE differently than the other modes. I guess that's why we still don't have an open source DTS-HD MA decoder.