LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

That works too, it contains my toolchain and enough of MSYS to build most projects.

[Aegwyn11]

The latest version is not the latest release. :P

Lol got it, thanks!

[pOpY]

I have analyzed the problem with ffplay.
The problem is the default 5000000µs analyzeduration timeout of ffmpeg.

if ill play the stream with the following command:

ffplay -i udp://239.200.199.103:20000 -analyzeduration 250000

The stream/picture is shown very quickly!

Can you please make the setting adjustable in LAV Splitter?
This would be great.

Thanks
pOpY

Dear nev.

Have opened a new issue regarding the problem above.

Here it is: CLICK ME (https://code.google.com/p/lavfilters/issues/detail?id=368)

best regards
Tobias

[thegilpins]

Hi,

Just updated LAV from 0.57 to 0.58 and I am having problems with QuickSync in that HD content judders and other lower quality videos are taking 2 seconds to display, when the audio plays straightaway. This is only an issue with 0.58 and not 0.57. Also I changed LAV video to use CUVID and the issues does not occur, so I assume it is related to the new Intel decoder added in the newer version of LAV.

I am using PotPlayer with LAV and MadVR.

Anyone else having problems with LAV and QuickSync in version 0.58?

I have a Z77 board with an overclocked 3770K.

[michkrol]

Anyone else having problems with LAV and QuickSync in version 0.58?

Now that I've checked I get similar problem to yours with interlaced content, while having "Adaptive HW Deinterlacing" enabled, progressive content is ok.
Could you confirm this and try some progressive content and/or using YADIF instead?

Also a link to sample file might help inspect the issue. If it's something you don't publicly available, you could probably PM the link to either LAVFilters' or QuickSync Decoder's respective developer.

[nevcairiel]

LAVs version of the QuickSync decoder does not have the Live TV issue. I wouldn't have used it otherwise.

[Nicola]

"Improved transition between ordered chapters in certain (badly formed) MKV files"
I like how now transition are fine (dunno if perfect but no big visible issue as before) and the fact you pointed out the MKV vere badly formed (cause I said so to the ones doing that and guess the answer).
Thanks a lot!

[michkrol]

LAVs version of the QuickSync decoder does not have the Live TV issue. I wouldn't have used it otherwise.

Thanks for the clarification.

As for the HW deinterlacing bug, it's probably driver's bug or my system is broken, since I remember it working in 0.57 and it doesn't after downgrading, it also doesn't work in ffdshow's QuickSync. I'm using Intel's 15.31.12.3204 drivers, will try other version later.

[thegilpins]

Now that I've checked I get similar problem to yours with interlaced content, while having "Adaptive HW Deinterlacing" enabled, progressive content is ok.
Could you confirm this and try some progressive content and/or using YADIF instead?

I deinterlace in MadVR so I am not using that in LAV. Issues occur with either bluray disc or MP4 files that are H264.

I can use quicksync with ffdshow without issue, it is just LAV v0.58 that is a problem for me. I have rolled back to 0.57.

Let me know if you need any further information.

[omarank]

Hi Nevcairiel.. I played a DCP sample using LAV filters and madVR. I found that madVR was guessing primaries of the video as DCI-P3, and because of that colours were grossly incorrect. When I changed the primaries manually in madVR to BT.709, the colours looked correct then. Since the video is in XYZ colour space, LAV must be converting it from XYZ to RGB, as madVR shows RGB input. I was wondering which primaries does LAV use when converting XYZ to RGB: is it BT.709 always? Shouldn't LAV pass on the primaries information to madVR so that it doesn't have to guess, in these situations when LAV does the conversion to RGB?

A little OT: In DCP content, audio and video streams are in two separate mxf files. Can anyone please tell me how to play them together in MPC-HC?

[nevcairiel]

From all i know about XYZ, it does not behave like YUV at all and there is no such transfer matrix like BT.709 involved.
And because XYZ is converted to RGB by LAV Video already, i don't think madVR should apply any color matrix changes at all.

[omarank]

Thanks for the quick reply.. I am not talking about transfer matrix, rather I am talking about primaries. If I understand it correctly, any RGB signal carries RGB information with respect to some primaries. In this case, the converted RGB video is apparently with Rec.709 primaries. madVR is guessing the primaries as DCI-P3 because it doesn't get any such information from the upstream and then makes its guess depending on the resolution of the video. Shouldn't LAV provide this information to madVR?

[nevcairiel]

How would LAV know the primaries? Or are those DCP streams always BT.709 primaries?

If madVR is trying to be too smart for its own good, you should talk to madshi.

[omarank]

I will not drag this further. However, I feel that this is something related to LAV. In my understanding of colorimetry, XYZ colour space can theoretically have any colour information, while RGB colour space is always limited by some defined gamut. So, when you convert XYZ to RGB, it is done using a defined gamut and white point. For videos, white point is going to be D65 but gamut may change. My confusion is what if a DCP content actually has colour information outside Rec.709 and say, inside DCI-P3. In that case, XYZ to RGB conversion should be done such that RGB is defined using DCI-P3 primaries. And this primaries information should be further passed on to the renderer.

Alternatively, LAV can just skip XYZ to RGB conversion. It can pass the decoded video in XYZ colour space to madVR, and the conversion to RGB can be taken care of by madVR.

I hope all this makes sense. If you think my understanding is flawed, you may clarify.

[kiwijunglist]

Hi

I use Win7 x64 with an ATI HD4670 and MediaPortal (EVR renderer) connected via HDMI directly into a TV that accepts 0-255 colourspace

I prefer to use 0-255 RGB colour-space in CCC. My video codec is LAV DXVA2 (native)

Question:

What is likely to give a better quality RGB conversion + 0-255 expansion?

1. Using LAV to expand + convert
LAV Settings: output RGB32, 0-255 only.

(or)

2. Using GPU to expand + convert
LAV Settings: output same colourspace + format as video.

Thanks!
Kiwi

Note: I do not want to output 16-235 from my video card, because it behaves strangely and I think it just expands everything to 0-255 then compresses back to 0-235.

[nevcairiel]

I will not drag this further. However, I feel that this is something related to LAV. In my understanding of colorimetry, XYZ colour space can theoretically have any colour information, while RGB colour space is always limited by some defined gamut. So, when you convert XYZ to RGB, it is done using a defined gamut and white point. For videos, white point is going to be D65 but gamut may change. My confusion is what if a DCP content actually has colour information outside Rec.709 and say, inside DCI-P3. In that case, XYZ to RGB conversion should be done such that RGB is defined using DCI-P3 primaries. And this primaries information should be further passed on to the renderer.

Alternatively, LAV can just skip XYZ to RGB conversion. It can pass the decoded video in XYZ colour space to madVR, and the conversion to RGB can be taken care of by madVR.



XYZ output is out of question, nothing supports XYZ input, and it would also cause extreme complexity inside LAV to support it, because it cannot be handled by the same code as RGB/YUV.

Regarding the XYZ to RGB conversion, the conversion is done using the matrix for XYZ -> sRGB, so can i assume that this then also contains sRGB/BT.709 primaries?

[nevcairiel]

My video codec is LAV DXVA2 (native)

[..]

What is likely to give a better quality RGB conversion + 0-255 expansion?


When you use DXVA2 Native, LAV cannot change the colors at all. Its up to the render to do this.

[madshi]

Regarding the XYZ to RGB conversion, the conversion is done using the matrix for XYZ -> sRGB, so can i assume that this then also contains sRGB/BT.709 primaries?
Yes. However, if the source is 2048 or 4096 pixels wide, then madVR automatically detects this as being DCI, and then madVR also expects you to use XYZ -> DCI-P3 instead of XYZ -> sRGB. You can still use XYZ -> sRGB, but you should then tell madVR about it by setting the DXVA_VideoPrimaries_BT709 flag. Well, at least in theory that should fix the problem, I haven't actually tested this myself yet.

If madVR thinks that the source is DCI-P3, and if the madVR settings say that your display is calibrated for BT.709 gamut, then madVR will convert the source from DCI-P3 to BT.709 gamut, and that's where omarank's problem comes from.

[nevcairiel]

Well i can easily export the flag then. The conversions always uses the same matrix, especially considering that other than madVR nothing would even consider using other primaries, using BT.709 seems like the best choice for compatibility.

[madshi]

Now that I think about it, you're right that using BT.709 is the best thing to do for LAV. Just flag it, please, the rest is my problem then. Maybe I should remove the auto-detection for DCI-P3. Not sure...

[nevcairiel]

I've already added the flag, i'll test it later when i get home where my DCP samples live.

[mindbomb]

I have a problem on this mkv file with a primary dts audio and secondary vorbis audios. The secondary vorbis ones don't appear to play when switching from the primary track.

http://www.mediafire.com/?4aigshee7a56chv

[Reino]

This only seems to affect LAV Audio Decoder. All fine with FFDShow.

Probably a rare case, but thought I'd report it anyway:
http://www.hydrogenaudio.org/forums/index.php?showtopic=101502&view=findpost&p=838118 (http://www.hydrogenaudio.org/forums/index.php?showtopic=101502&view=findpost&p=838118)
Hangs when time-seeking and on looping in MPC-HC/BE.

[omarank]

Yes. However, if the source is 2048 or 4096 pixels wide, then madVR automatically detects this as being DCI, and then madVR also expects you to use XYZ -> DCI-P3 instead of XYZ -> sRGB. You can still use XYZ -> sRGB, but you should then tell madVR about it by setting the DXVA_VideoPrimaries_BT709 flag. Well, at least in theory that should fix the problem, I haven't actually tested this myself yet.

If madVR thinks that the source is DCI-P3, and if the madVR settings say that your display is calibrated for BT.709 gamut, then madVR will convert the source from DCI-P3 to BT.709 gamut, and that's where omarank's problem comes from.

@ Madshi: If madVR detects the source as DCI-P3, is madVR going to do the conversion from sRGB to XYZ and then from XYZ to DCI-P3 (as LAV will always be providing sRGB)?

[JEEB]

I have a problem on this mkv file with a primary dts audio and secondary vorbis audios. The secondary vorbis ones don't appear to play when switching from the primary track.
Same thing as another user reported to me with an old file of his. First of all, it's not limited to LAV in any way or form. Second of all, no need for such a big sample. Here (http://www.cccp-project.net/beta/test_files/possibly_broken_vorbis_stream.ogg)'s a short and small sample that does the same.

When the vorbis track of these files is taken through current ffmpeg, you will get this:
[vorbis @ 0481d960] Invalid codebook entry count
[vorbis @ 0481d960] Vorbis setup header packet corrupt (codebooks).
[vorbis @ 0481d960] Setup header corrupt.

On May 13th ffmpeg got a new sanity check (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e6b6ae46951e242d7caf11acf5b1f10f109e1c96) for vorbis streams, and these streams seem to hit it and thus not initialize. I've been poking people on #ffmpeg-devel to have someone check if the sample I linked really is invalid, or if the check is too strict. If it is broken, then there's not much to be done about it, and if the check is too strict then it will get revised.

Most of these samples at least seem to play fine if you play them with an ffmpeg that is older than May 13th.

[Aleksoid1978]

Same thing as another user reported to me with an old file of his. First of all, it's not limited to LAV in any way or form. Second of all, no need for such a big sample. Here (http://www.cccp-project.net/beta/test_files/possibly_broken_vorbis_stream.ogg)'s a short and small sample that does the same.

When the vorbis track of these files is taken through current ffmpeg, you will get this:
[vorbis @ 0481d960] Invalid codebook entry count
[vorbis @ 0481d960] Vorbis setup header packet corrupt (codebooks).
[vorbis @ 0481d960] Setup header corrupt.

On May 13th ffmpeg got a new sanity check (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=e6b6ae46951e242d7caf11acf5b1f10f109e1c96) for vorbis streams, and these streams seem to hit it and thus not initialize. I've been poking people on #ffmpeg-devel to have someone check if the sample I linked really is invalid, or if the check is too strict. If it is broken, then there's not much to be done about it, and if the check is too strict then it will get revised.

Most of these samples at least seem to play fine if you play them with an ffmpeg that is older than May 13th.

In MPC-BE's ffmpeg i just remove this check:

if (entries <= 0) {
av_log(vc->avctx, AV_LOG_ERROR, "Invalid codebook entry count\n");
ret = AVERROR_INVALIDDATA;
goto error;
}


entries can be a zero value.

and all play fine.

[nevcairiel]

The check should probably be only "entries < 0", removing it completely leaves you open to security-relevant issues again (the whole point why it was added in the first place).

[JEEB]

The check should probably be only "entries < 0", removing it completely leaves you open to security-relevant issues again (the whole point why it was added in the first place).
Sounds good. Cehoyos seems to have finally noted the report I did on IRC and there's now an issue (https://ffmpeg.org/trac/ffmpeg/ticket/2720) on the tracker about this. We'll see how it gets fixed.

[madshi]

@ Madshi: If madVR detects the source as DCI-P3, is madVR going to do the conversion from sRGB to XYZ and then from XYZ to DCI-P3 (as LAV will always be providing sRGB)?
I'm not going through XYZ for the conversion, but I'm converting from sRGB to DCI-P3 directly, in linear light. I'm not really a total expert on this, but I believe the end result should be the same.

Well, there's one potential issue: When converting XYZ to sRGB, results might be outside of the usual range, so maybe clipping could occur inside of LAV's conversion routine? @nevcairiel, could you check that? (Don't know how, though).

[nevcairiel]

I cannot tell you if it would result in clipping, i really don't understand enough of it, i do know though that it does clip the values during conversion, otherwise it could potentially overflow the 16-bit pixels, and that wouldn't be good ;)
FWIW, the conversion is in ffmpeg.

[madshi]

Well, the BT.709 gamut is a relatively small subset of the DCI-P3 gamut. So if ffmpeg converts to RGB BT.709 then all color values outside of the BT.709 gamut (but still within the DCI-P3 gamut) must have values outside of the usual RGB range. So if you convert to PC levels RGB, all values outside of the BT.709 gamut must either have negative RGB components or larger than 255 (for 8bit). If these are clipped, there's no way to restore them. One possible workaround could be to use limited range RGB, that would leave a bit of headroom. But probably EVR/VMR can't handle limited range RGB? If that's the case then maybe the best solution would be to detect madVR and use XYZ->DCI-P3 conversion for madVR instead of XYZ->sRGB? Of course it's not a nice solution to hard code different behaviour depending on the detected renderer, but right now nothing else comes to my mind...

[nevcairiel]

Like i mentioned, the conversion is in ffmpeg, and i don't have any influence on this without hacking the code. And TBH, this thing is unimportant enough for me to simply ignore. (Not to mention that the JP2K decoder for that content is extremely slow)
Most screens are sRGB/BT.709 anyway, so in the end madVR would most likely clip these values away again anyhow?

[madshi]

Nobody stops you from calibrating your display to a wider gamut today (provided the display is actually capable of that). madVR would properly convert BT.709 videos to look correctly in the wider gamut. So for people who actually want to playback DCP content, calibrating to a wider gamut is a very valid option. If you say that most people use BT.709, anyway, then that's right. But most people also don't play DCP content.

I've seen in the ffmpeg/libav discussion list that recently BT.2020 support was added "somewhere" (don't know for which part of the code, though). Does the ffmpeg revision you're using allow you to alternatively use XYZ->BT.2020 instead of XYZ->BT.709? If so, that would be a valid alternative, when madVR is the renderer. You'd just have to flag this to madVR. FWIW, madVR already supports the following DXVA flags:

// DXVA primaries:
// 2: BT.709
// 3: BT.470 System M
// 4: BT.601 (PAL, SECAM)
// 5: SMPTE 170M
// 6: SMPTE 240M
// 7: BT.601 (PAL, SECAM)
// 8: SMPTE C
// 9: BT.2020 (UHDTV)
// 10: DCI-P3
// video bitstream primaries:
// 1: [DXVA: 2] 0.640 0.330, 0.300 0.600, 0.150 0.060, D65, BT.709, sRGB
// 4: [DXVA: 3] 0.670 0.330, 0.210 0.710, 0.140 0.080, C, BT.470 System M
// 5: [DXVA: 4] 0.640 0.330, 0.290 0.600, 0.150 0.060, D65, BT.601 (PAL, SECAM)
// 6: [DXVA: 8] 0.630 0.340, 0.310 0.595, 0.155 0.070, D65, BT.601 (NTSC), SMPTE C, SMPTE 170M
// 7: [DXVA: 6] 0.630 0.340, 0.310 0.595, 0.155 0.070, D65 SMPTE 240M
// 8: [DXVA: -] 0.681 0.319, 0.243 0.692, 0.145 0.049, C, Generic film (colour filters using Illuminant C)
// 9: [DXVA: 9] 0.708 0.292, 0.170 0.797, 0.131 0.046, D65, BT.2020 (UHDTV)
// 10: [DXVA: 10] 0.680 0.320, 0.265 0.690, 0.150 0.060, 0.68 0.32, DCI-P3

// DXVA decoding matrix
// 1: BT.709
// 2: BT.601
// 3: SMPTE 240M
// 4: BT.2020
// 7: YCgCo
// video bitstream decoding matrix:
// 0: [DXVA: -] Y = G, Cb = B, Cr = R
// 1: [DXVA: 1] kr 0.2126, kb 0.0722, BT.709
// 4: [DXVA: -] kr 0.3000, kb 0.1100, US 1953 Recommendation
// 5: [DXVA: 2] kr 0.2990, kb 0.1140, BT.601 (PAL, SECAM)
// 6: [DXVA: 2] kr 0.2990, kb 0.1140, BT.601 (NTSC)
// 7: [DXVA: 3] kr 0.2120, kb 0.0870, SMPTE 240M
// 8: [DXVA: 7] YCgCo
// 9: [DXVA: 4] kr 0.2627, kb 0.0593, BT.2020 (UHDTV)

[nevcairiel]

It has no options whatsoever, its hard coded to use the sRGB conversion matrix, which is really the most compatible thing you can do.

PS:
Where did you get the DXVA ids for BT.2020 and DCI-P3 primaries or YCgCo and BT.2020 matrix?
I've never seen these documented anywhere.

PPS:
If you want to support XYZ input in madVR, thats something i would be more comfortable hacking into place at some point than trying to guess the "best" XYZ -> RGB conversion matrix.

[madshi]

I've added those ids myself, so they're not "official" in any way at all. However, at least the BT.2020 video bitstream ids used by madVR match the latest h264 spec revision:

http://www.itu.int/rec/T-REC-H.264-201304-I/

If ffmpeg doesn't offer any way to do anything other than XYZ -> sRGB at the moment then maybe we should simply stick to sRGB for now. I'm sure at some point in the future ffmpeg will get support for XYZ -> BT.2020/DCI-P3, too. At that point maybe you can modify LAV accordingly.

[omarank]

If ffmpeg doesn't offer any way to do anything other than XYZ -> sRGB at the moment then maybe we should simply stick to sRGB for now. I'm sure at some point in the future ffmpeg will get support for XYZ -> BT.2020/DCI-P3, too. At that point maybe you can modify LAV accordingly.

There is one problem if LAV guesses the right conversion matrix. For example, if LAV guesses the primaries as DCI-P3 but the source happens to have the primaries as BT.2020, there'll be no way to manually force the primaries as BT.2020. On the other hand, if the XYZ -> RGB conversion happens in madVR, it can change the conversion matrix when the user toggles the primaries.

[nevcairiel]

As i understand XYZ, it doesn't have a defined set of primaries, its a complete mathematical abstraction of the whole thing.
You can convert it to sRGB or DCI-P3 or BT.2020 or whatever else you need, the only limitation you may run into is that the color space you choose is not able to represent all colors in the XYZ space.

[madshi]

Yes, I believe if LAV would convert to BT.2020, it should be no problem for madVR to correctly convert that to DCI-P3 (or vice versa). The only problem is clipping when using a too narrow gamut somewhere in the chain. But anyway, first of all ffmpeg/libav need to add support for XYZ -> BT.2020 / DCI-P3 conversion.

[nevcairiel]

Worst case i could implement this myself (move the code into LAV), which would make it more flexible (and possibly faster), but even if i put that on my list, it would be rather far down the list.

[madshi]

Well, I can see in the list ffmpeg development list that they're still heavily working on all the DCP related stuff. I'd say we should wait a while. Sooner or later they'll probably support DCI-P3 primaries correctly without needing any custom hacks from your side. At least that's what I would expect. Maybe you can put this on your to do list to revisit in half a year or so? If there's no solution until then, maybe we can work something out between us...

[nevcairiel]

This only seems to affect LAV Audio Decoder. All fine with FFDShow.

Probably a rare case, but thought I'd report it anyway:
http://www.hydrogenaudio.org/forums/index.php?showtopic=101502&view=findpost&p=838118 (http://www.hydrogenaudio.org/forums/index.php?showtopic=101502&view=findpost&p=838118)
Hangs when time-seeking and on looping in MPC-HC/BE.

I fail to see how FFDshow can change anything here, as LAV Splitter simply cannot seek such files - its not something in the audio decoder.

[Reino]

The first line is a reply to mindbomb.

[nevcairiel]

I see, that could've been a bit more obvious. :P

[bwo_j]

LAV Splitter bug when using 0.58 LAV Filters for h264 10bit 4:4:4 video.

On MadVR OSD,
LAV Splitter Output -> RGB32 8 bit RGB
Potplayer Internal MKV Splitter Output -> Y410 10bit 4:4:4

Edit:
[Sample link removed]

Issue due to limitations of xyvsfilter, resolved using xysubfilter.

[nevcairiel]

LAV Splitter bug when using 0.58 LAV Filters for h264 10bit 4:4:4 video.

On MadVR OSD,
LAV Splitter Output -> RGB32 8 bit RGB
Potplayer Internal MKV Splitter Output -> Y410 10bit 4:4:4


Works just fine for me. Must be something else in your setup.

[DarkSpace]

On MadVR OSD,
LAV Splitter Output -> RGB32 8 bit RGB
Potplayer Internal MKV Splitter Output -> Y410 10bit 4:4:4

Sample file: http://www.mediafire.com/?uubiw19vqvuuqkp
Just a guess, but do you use (xy-)VSFilter during playback as well? The sample file has subtitles, and (xy-)VSFilter doesn't support high-bitdepth 4:4:4 (http://code.google.com/p/xy-vsfilter/issues/detail?id=83) currently...

[bwo_j]

Just a guess, but do you use (xy-)VSFilter during playback as well? The sample file has subtitles, and (xy-)VSFilter doesn't support high-bitdepth 4:4:4 (http://code.google.com/p/xy-vsfilter/issues/detail?id=83) currently...

@Darkspace
Thanks & great guess. Confirmed on my side that xy-vsfilter is the culprit.

@nevcairiel
Thanks for taking a look & great work on LAV filters :)

[Deihmos]

I ave a 1080p video that would not play using lav splitter. I installed 5.8 then 5.7 and it did not work. I then uninstalled lav spliiter and installed haali splitter then the video played fine. I only use lav as a splitter. This is the video info. Does anyone know why lav splitter refuses to work with this video ? The lav splitter icon does not show when I try to play this video.

General
Unique ID : 210381042709451439878488213017028658392 (0x9E45EA3CB09CB81791144661870F04D8)
Complete name : Movies\Hansel & Gretel Witch Hunters (2013)\Hansel and Gretel Witch Hunters.mkv
Format : Matroska
Format version : Version 2
File size : 7.23 GiB
Duration : 1h 37mn
Overall bit rate : 10.6 Mbps
Encoded date : UTC 2013-05-16 18:04:12
Writing application : mkvmerge v5.8.0 ('No Sleep / Pillow') built on Sep 2 2012 15:37:04
Writing library : libebml v1.2.3 + libmatroska v1.3.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.0
Format settings, CABAC : No
Format settings, ReFrames : 2 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 37mn
Bit rate : 10 000 Kbps
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.271
Stream size : 6.65 GiB (92%)
Writing library : x264 core 112
Encoding settings : cabac=0 / ref=1 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=5 / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=0 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=10000 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Muxing mode : Header stripping
Codec ID : A_AC3
Duration : 1h 37mn
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 448 MiB (6%)
Language : English
Default : Yes
Forced : No

[jkauff]

nev,

I was playing the Blu-ray of A Bridge Too Far in Media Center 18 yesterday. The Dutch and German language portions of the film have English subtitles, but MC could only play with all subtitles or no subtitles. All my LAV-based players have the same problem, and I read that it was a LAV issue.

Not a big deal, because I was able to play it correctly in PowerDVD, but I wondered what the issue is? Can you explain?

[nevcairiel]

LAV can play with any subtitles that are on the disc, the only problem is that a Blu-ray only tells you the language and nothing else, so it cannot auto-select the proper one and you may need to manually switch around.