LAV Filters - DirectShow Media Splitter and Decoders

[SamuriHL]

You think it's ready for integration? Well it certainly matches the internal filters in terms of features. I was hoping for one more feature though. Audio bitstreaming would allow me to remove ffdshow from the chain. And I think there's a few other features on nev's to do list as well. Integration _is_ a good idea but how much work would it take and would we not see any updates while it was worked on?

[nevcairiel]

Originally Posted by SamuriHL

It seems to default to the first sub track when playing an mpls. Not sure if that's a setting in mpc-hc that I have set wrong or if it's the splitter doing it? In any case nice job on that!

Hm, subtitle track selection should work similar to how it works with any other files, depending on the setting in the LAV Splitter GUI.
I'll test that later, not sure which setting i had active in my setup, but i see no reason it wouldn't work as expected.

[Mercury_22]

Originally Posted by SamuriHL

You think it's ready for integration? Well it certainly matches the internal filters in terms of features. I was hoping for one more feature though. Audio bitstreaming would allow me to remove ffdshow from the chain. And I think there's a few other features on nev's to do list as well. Integration _is_ a good idea but how much work would it take and would we not see any updates while it was worked on?

Since as you say "matches the internal filters" I think it's ready
Plus then maybe more people can help with the new features or to "squash", if any, the remaining bugs
Just my 2 c

[SamuriHL]

Originally Posted by nevcairiel

Hm, subtitle track selection should work similar to how it works with any other files, depending on the setting in the LAV Splitter GUI.
I'll test that later, not sure which setting i had active in my setup, but i see no reason it wouldn't work as expected.

I've only tested it on that one Glee disc so far. I was simply testing to make sure I built everything correctly and happened to try the mpls files. Let me know what you find.

[SamuriHL]

Originally Posted by Mercury_22

Since as you say "matches the internal filters" I think it's ready
Plus then maybe more people can help with the new features or to "squash", if any, the remaining bugs
Just my 2 c

I'm definitely not against the idea by any means. I know that's a stated goal and quite frankly at this point I have all the internal filters disabled myself. Just wondering how much work that'd be and how much time it'd take.

[nevcairiel]

Originally Posted by clsid

Embedded subtitles requires LAV Splitter to be on a known list of compatible splitters inside the DirectVobSub code. I will commit a patch for it to MPC-HC

Thanks!

Originally Posted by SamuriHL

I've only tested it on that one Glee disc so far. I was simply testing to make sure I built everything correctly and happened to try the mpls files. Let me know what you find.

Well whats your setting in the LAV Splitter config? Full subs, no language preference (which is the default)? That will always get you the first sub track.

Originally Posted by Mercury_22

@nevcairiel
Maybe after releasing 0.20 can we expect a MPC-HC LAV branch or even better: LAV splitter and audio added as options to the existing splitters and audio ?

Probably not yet.
Integrating it itself is not that hard, the problem is how to do it properly. For a testing period, it would be preferred to offer the ability to choose between the two, possibly on a per-format basis. This would be a major UI redesign, which is really not much fun to do.

I could of course just add one big checkbox that says "Use LAV Filters (where available)", and be done with the UI changes .. but i dunno, some more fine-grained configuration would be better, i think.

There is also the problem with ffmpeg. The version i use is far superior to the version MPC-HC uses, but changing MPC-HCs internal filters (especially video) to use the more recent version will most likely break alot of stuff and be alot of work.

People that want to test it can easily just install the two external libraries, and be done with it, until i'm confident that i can just safely replace the internal filters without worrying about config options.

Anyway, I have some things i want to finish next, before i do anything else. Maybe with those features i could actually call it "1.0"
- BluRay title switching from within the player
- Embedded Font support for MKV (internal MKV splitter can do that)
- Audio Bitstreaming (internal audio decoder can at least do AC3/DTS SPDIF, even if it cannot do HD)
- Sample Format conversion (some audio drivers don't accept the 32-bit float output, should be able to convert it to 16/24 bit integer)
- Stereo downmixing would be a bonus, but not sure how/if to do this.

[SamuriHL]

Originally Posted by nevcairiel

Well whats your setting in the LAV Splitter config? Full subs, no language preference (which is the default)? That will always get you the first sub track.

Uhhhhhh, hmmm. Yea, I never changed the default so I'm quite sure that's what it's set to. Guess I'll go mess with that.

Probably not yet.
Integrating it itself is not that hard, the problem is how to do it properly. For a testing period, it would be preferred to offer the ability to choose between the two, possibly on a per-format basis. This would be a major UI redesign, which is really not much fun to do.

I could of course just add one big checkbox that says "Use LAV Filters (where available)", and be done with the UI changes .. but i dunno, some more fine-grained configuration would be better, i think.

There is also the problem with ffmpeg. The version i use is far superior to the version MPC-HC uses, but changing MPC-HCs internal filters (especially video) to use the more recent version will most likely break alot of stuff and be alot of work.

People that want to test it can easily just install the two external libraries, and be done with it, until i'm confident that i can just safely replace the internal filters without worrying about config options.

Anyway, I have some things i want to finish next, before i do anything else. Maybe with those features i could actually call it "1.0"
- BluRay title switching from within the player
- Embedded Font support for MKV (internal MKV splitter can do that)
- Audio Bitstreaming (internal audio decoder can at least do AC3/DTS SPDIF, even if it cannot do HD)
- Sample Format conversion (some audio drivers don't accept the 32-bit float output, should be able to convert it to 16/24 bit integer)
- Stereo downmixing would be a bonus, but not sure how/if to do this.

That's an awesome list. Just what you've done now has made MPC-HC infinitely more useful for MKV playback for some of us. And now with the BD support it's even better. It's getting to a point where it's really viable to replace my commercial player of choice. These features would only make it that much better.

[clsid]

Originally Posted by nevcairiel

Integrating it itself is not that hard, the problem is how to do it properly. For a testing period, it would be preferred to offer the ability to choose between the two, possibly on a per-format basis. This would be a major UI redesign, which is really not much fun to do.

I could of course just add one big checkbox that says "Use LAV Filters (where available)", and be done with the UI changes .. but i dunno, some more fine-grained configuration would be better, i think.

There is also the problem with ffmpeg. The version i use is far superior to the version MPC-HC uses, but changing MPC-HCs internal filters (especially video) to use the more recent version will most likely break alot of stuff and be alot of work.

People that want to test it can easily just install the two external libraries, and be done with it, until i'm confident that i can just safely replace the internal filters without worrying about config options.

If the internal filter functionality in MPC is ever redone, I would personally would like to see something like this:
* Filters are no longer embedded, but placed in a configurable external location (by default a subfolder called Filters). Simply check for the presence of a file for it to be listed on the "Internal Filters" page and to be used by MPC.
* Those filters will still be able be used without being registered, just like is done now with the embedded ones.
* Filters can of course optionally be registered to use them in other applications as well. So no need to have both embedded+external installed in such a situation. Less redundancy.
* Filters can now be updated without having to update MPC. Useful for regression testing, but also useful to keep development separated.
* Linking issues when using multiple versions of the same library (ffmpeg) in multiple filters are no longer an issue.
* Support for popular third party filters could be added as well, to use those in unregistered form. Useful for portable use.
* Smaller binary for people who don't use (some of the) internal filters.

[SamuriHL]

Originally Posted by clsid

If the internal filter functionality in MPC is ever redone, I would personally would like to see something like this:
* Filters are no longer embedded, but placed in a configurable external location (by default a subfolder called Filters). Simply check for the presence of a file for it to be listed on the "Internal Filters" page and to be used by MPC.
* Those filters will still be able be used without being registered, just like is done now with the embedded ones.
* Filters can of course optionally be registered to use them in other applications as well. So no need to have both embedded+external installed in such a situation. Less redundancy.
* Filters can now be updated without having to update MPC. Useful for regression testing, but also useful to keep development separated.
* Linking issues when using multiple versions of the same library (ffmpeg) in multiple filters are no longer an issue.
* Support for popular third party filters could be added as well, to use those in unregistered form. Useful for portable use.
* Smaller binary for people who don't use (some of the) internal filters.

That would be absolutely ideal! That way people can just drop in the filters they care about, not having to register them, and get the exact functionality they want. YES PLEASE!!! Those who prefer the current filters could still use them. Those that want the "new stuff" could go that route. We still need the external filter page for adding things like Cyberlink or ArcSoft filters or whatever, but, I can definitely get behind this idea!

[nevcairiel]

I would always vote for keeping the filters seperate, but in the past the MPC-HC team (especially Casimir) always blocked any attempts at splitting it. Apparently having one single .exe that does everything is somehow "better".

In any case, LAV Splitter is not designed to run "embedded", and i won't modify it to do so. Additionally its also not designed to use an embedded ffmpeg. So, yeah, unless the MPC-HC guys change their mind about this, nothing to see here.

I like the idea of simply having the filters in some directory. Although this requires some haxery for source filters, you can't simply figure out which formats they support like you can with a transform filter, so MPC-HC would have to know all the details about them. (Thats why source filters can't be used unregistered in MPC-HC right now)

Making it fully dynamic (like, drop in filter and it gets used) might not be 100% viable, but doing it at least for the "known" filters would work (original internal filters, LAV Filters, some other common filters)

You know, redesigning a key part of MPC-HC like this, could be easier to just write a new player and steal some stuff from MPC-HC. :P

[sneaker_ger]

Is there a way to set the seeking behavior to the ways Gabest and Haali work? Right now it will only seek to the nearest preceding keyframe and not to arbitrary frames (using Matroska). I didn't find any option to change this.

[nevcairiel]

Why would you want to seek to a non-keyframe? You can't decode them properly anyway.

[SamuriHL]

Nev, you were right. I fixed my subtitle issue by changing the default setting. Man I am SO happy with this setup right now! Once title changing is in there I'm very likely to drop my commercial players and just use this now. WELL DONE!

[CruNcher]

I have to say Amazing .ts .m2ts splitter 98% of test clips play even the ones that MPC-HC Splitter chokes on or Haalis Crash
The Hillary Sample works flawless in switching between the different PIDs though only with Cyberlinks Demuxer 2.0 (the switching is also super fast (instant), MPC-HC Splitter seems to need to get to the next Keyframe first before it switches). Also the DXVA to YUY2 switching for 4:2:2 Mpeg-2 Studio Profile works flawless so supporting decoder use Software Decoding instead of DXVA when getting MEDIASUBTYPE_YUY2 instead of some splitter MEDIASUBTYPE_MPEG2 great

[sneaker_ger]

Originally Posted by nevcairiel

Why would you want to seek to a non-keyframe? You can't decode them properly anyway.

Works just fine with Gabest and Haali. The decoder gets all the frames it needs to decode the desired frame. Of course seeking can take longer in case the GOP is really long.

[nevcairiel]

As you said, it actually seeks to the previous I-Frame. By doing this, all timestamps will actually be negative until the desired timestamp is reached. Negative timestamps in DirectShow indicate "Preroll", which should not be shown, but is required to init the decoder.

The alternative would be to simply disable this and seek to any frame directly, not looking for keyframes, GOPs and whatnot. This would not have any benefit to me, as it would only result in broken playback until the next I-Frame. I don't see the point offering this option.

I also don't really care what others do. I do what i think is right, and works.

[sneaker_ger]

I don't know the technical details, although I understand that the decoder needs the previous frames in case I'm not seeking to an I-Frame. But this works just fine using Haali and Gabest. If I seek to the end of a 10 second GOP with Haali, seeking might take a fraction of a second on my quad core. With your splitter I have to watch the entire GOP from start. This also means that you can't seek to chapter starts exactly if they don't start on an I-Frame (for whatever reason).

[CruNcher]

All the samples that have this *.ts VC-1 setup in order work too http://forum.doom9.org/showpost.php?...ostcount=16791
and all *.ts ADTS AAC playback flawless with lav audio also something not so common currently

[nevcairiel]

Originally Posted by sneaker_ger

I don't know the technical details, although I understand that the decoder needs the previous frames in case I'm not seeking to an I-Frame. But this works just fine using Haali and Gabest. If I seek to the end of a 10 second GOP with Haali, seeking might take a fraction of a second on my quad core. With your splitter I have to watch the entire GOP from start. This also means that you can't seek to chapter starts exactly if they don't start on an I-Frame (for whatever reason).

I have looked over the Gabest MPEG-TS splitter numerous times, and it really doesn't do anything special, it just seeks to the time requested.
If you really insist, i can add an option to allow frame accurate seeks instead of fast/fluid seeks, but i don't think its what most people want.

Originally Posted by CruNcher

All the samples that have this VC-1 setup in order work too http://forum.doom9.org/showpost.php?...ostcount=16791

You know, its much more interesting to know what does not work, so it can be improved upon.

[CruNcher]

Originally Posted by nevcairiel

I have looked over the Gabest MPEG-TS splitter numerous times, and it really doesn't do anything special, it just seeks to the time requested.
If you really insist, i can add an option to allow frame accurate seeks instead of fast/fluid seeks, but i don't think its what most people want.



You know, its much more interesting to know what does not work, so it can be improved upon.

hehe sample above i still look @ some audio issues with some hdpvr Haupauge Recorded streams (doesn't seem to be in sync) i upload those too
yep seems to be a issue other splitter work fine and keep it sync also that it goes out of sync with LAV CUVID seems to make it clear it's an valid issue (i mostly carefully check before i see something as a bug or a problem)

so here my problem samples are
http://www.mediafire.com/download.php?4k8lluvvvkxvyuz <- Goes out of sync
http://www.mediafire.com/download.php?3xjrymbaigi9mpl <- No Audio and Crash when entering Lav Audio Status display

also again both of V0lt samples which show issues not only in LAV Splitter
http://www.multiupload.com/PYBILYB30E <- Freezes
http://www.multiupload.com/MNHNZJKDOP <- Freezes

(all of them work flawless in Cyberlinks Demuxer 2.0 it has 100% success rate on all streams (yet to find a stream that doesn't work), also stream switching is instant for the Hilary sample with it)



Though it has the MEDIASUBTYPE_MPEG2 issue with DXVA and 4:2:2 streams i guess they dont care anyways about other streams they don't support and it would make no sense going to their support with that (so currently you have to manually switch of DXVA for those streams )

Which btw is also a issue for LAV CUVID see LAV CUVID thread (trying to playback every Bitstream without checking if it would work @ all)