LAV Filters - DirectShow Media Splitter and Decoders

[Keiyakusha]

Originally Posted by nevcairiel

- Handle the "Default" flag in MKV files with multiple video streams
- Improved transition between ordered chapters in certain (badly formed) MKV files

Thanks! Exactly what I needed... though this means one of my milti-edition files is "badly formed". This is what I thought but couldn't figure out how to fix it. >__<

[nevcairiel]

"badly formed" in this case just means that the chapter does not *exactly* match a Cue point, however if the new version fixed it, then there is a cue point very close by at least, so the chapter work was just "sloppy" (ie. a few milliseconds off target)

[cyberbeing]

There seems to be a LAV Splitter regression regarding MKV Segment Linking which was introduced between LAVFilters-0.55.3-73-g3f9ce87 and LAVFilters-0.56.1.

LAVFilters-0.55.3-73-g3f9ce87 (working) <- LAVFilter test builds inbetween (crash) -> LAVFilters-0.56 (crash) -> LAVFilters-0.56.1 (issue) -> LAVFilters-0.58.0 (issue)

I'll PM you a sample.

[nevcairiel]

Its not a regression if it never worked in a release.

[pOpY]

Dear nev.

v0.58 doesnt solve my issue.
I have updated Issue 353 on bugtracker.

https://code.google.com/p/lavfilters/issues/detail?id=353

Ill think now you should be able to easily reproduce the problem.

thx
pOpY

[pOpY]

Also i had to edit build_ffmpeg.sh line 21-23 from.

strip_libs() {
x86_64-w64-mingw32-strip lib*/*-lav-*.dll
}

to

strip_libs() {
strip lib*/*-lav-*.dll
}

to work with my MinGW.

[nevcairiel]

Thats because your mingw is incomplete.

[pOpY]

hmm, thats not good
could you please provide me your MINGW directory or pint me in the right direction

Ill have used this one: http://nuwen.net/mingw.html
with all components and msys.

thx
pOpY

[nevcairiel]

Thats apparently the "old" mingw32, while around here we switched to mingw-w64 a long time ago.
Its curious though, GCC 4.8.1 shouldn't even build with the old mingw, but hey, what can you do.

My mingw-w64 based toolchain is always available here (without MSYS, you still need that from somewhere else):
http://files.1f0.de/mingw/

Edit:
The mingw-w64 project has a complete MSYS package which should work:
http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS

Unzip MSYS, and then put my mingw-w64 toolchain into MSYS\mingw
To build ffmpeg you'll need some additional tools like YASM, though.

[kasper93]

You can also grab XhmikosR's package http://xhmikosr.1f0.de/tools/

[nevcairiel]

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

[Aegwyn11]

Originally Posted by nevcairiel

The latest version is not the latest release. :P

Lol got it, thanks!

[pOpY]

Originally Posted by 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

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]

Originally Posted by thegilpins

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]

Originally Posted by nevcairiel

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]

Originally Posted by michkrol

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?