LAV Filters - DirectShow Media Splitter and Decoders

[BeNooL]

will this also fix playback of mkv generated by X264 where one cannot seek (using MeGui to encode) ?

When trying to seek, playback always goes back to start of video.

[nevcairiel]

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.

[sneaker_ger]

You mean we might have to wait for like 5 minutes, similar to ffmpegsource?

[madshi]

Originally Posted by nevcairiel

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.

Wouldn't it make sense to start building the index in a background thread right when the video file is loaded? Then, when the first seek isn't done right away, it might already work instantly?

[nevcairiel]

Originally Posted by sneaker_ger

You mean we might have to wait for like 5 minutes, similar to ffmpegsource?

If the file is multiple gigabytes and does not have a seeking index in the file, it is quite possible that it will take a while - i'm unsure about 5 minutes though.

I have a 1.6GB file without such an index, and it takes about 10 seconds on a relatively slow harddrive to build that index. If the file is say a 1080p Blu-ray rip of 20GB, it would i guess take around 2 minutes or so (or even less on better hardware)

In general, you should rather remux those files to add an index instead. MKV sadly is not designed to seek without an index - so either you have one in the file, or you need to build one.
This is still a great advantage over the situation now, because now it doesn't allow seeking at all.

Originally Posted by madshi

Wouldn't it make sense to start building the index in a background thread right when the video file is loaded? Then, when the first seek isn't done right away, it might already work instantly?

Building the index requires seeking through all clusters in the file (well, actually in 10MB steps, which could be increased to speed up index creation for the cost of more "inaccurate" seeks), which could have a serious impact on fluid playback.
It looks like Gabest MKV splitter always builds the index on opening, while Haali also builds it on demand (Hey, i'm using Haalis matroskaparser library afterall!)

Such files are just not perfect. If anything, they should only result as intermediate files in a encoding process, your final file should always have a Cue index, otherwise the mux is just wrong.

[mindbomb]

my experience has been that with my incomplete files muxed with haali's muxer, there is a slight delay.

However, the seeking problems with mature files muxed with mkvmerge have also gone away, and there is no delay at all in that case, despite they're large size.

[sneaker_ger]

Originally Posted by nevcairiel

I have a 1.6GB file without such an index, and it takes about 10 seconds on a relatively slow harddrive to build that index.

So that's why harddrives are so expensive today. I thought 160 MB/s was fast...

Originally Posted by nevcairiel

Such files are just not perfect. If anything, they should only result as intermediate files in a encoding process, your final file should always have a Cue index, otherwise the mux is just wrong.

I agree, index is a must. I only use it for intermediate files/testing, so I can have a preview of the current x264 output, to decide whether I'm happy with the result or if I have to stop the encoding process.

[nevcairiel]

Originally Posted by sneaker_ger

So that's why harddrives are so expensive today. I thought 160 MB/s was fast...

It doesn't read every block of the file. It looks for a Cluster, reads its timecode, jumps 10MB further ahead, looks for the next cluster, rinse and repeat. I would guess it reads maybe 1/10th of the whole file, with alot of seeking involved.

ffmpegsource indexes the timestamp of every frame for frame-accurate seeking/editing, so it will be slower.
I would suggest to wait and test before drawing any more conclusions.

As an alternative to the index building i could implement a binary search seek, but that would mean seeking is never fast on such files, but there is no initial delay either. Not sure if thats better - but its surely alot of effort for files that are not really *that* common for normal users.

[Sebastiii]

Originally Posted by Wodde

have i missed something?
I have LAV 0.40 installed, but there is no Titleselection?

EDIT: Ah, J.River 17.

Well thats fine, but thats a paid software, i prefer a free one

What about MPC HC?

You can try Mediaportal with BlurayHandler plugin (based on LAF Filter of course) :
http://www.team-mediaportal.com/exte...-handler-0-9-7
http://forum.team-mediaportal.com/me...-7-beta-81068/

Or Internal Bluray Menu on Mediaportal too :
http://forum.team-mediaportal.com/ge...upport-102375/

Thanks

[Sebastiii]

Originally Posted by nevcairiel

Most likely, yes.
There will be a delay on the first seek while it builds a index, but further seeks should be working just fine and fast.

Yep, i can confirm that
Nice

[GRENDIZER]

Hello, I'm a new user of LAV and I have a question about bitstreaming.

My config: HTPC running Win7 64, soundcard; Realtek HD audio in motherboard, audio receiver and speakers: Logitech Z5500, cable: optical.

I've been checking if AC3 audio is working on these speakers, and it works. Testing the file "Test AC3 v2.0.avi", my audio receiver displays "Dolby Digital" and the surround test works.

One thing I do not understand is that in the LAV audio options, under "bitstreaming", wether "Dolby Digital (AC3)" is checked or not, the surround sound works, and the Audio receiver says it's "Dolby Digital". I thought that when it's not checked, LAV decodes the AC3 and in that case, the audio receiver would not receive any proper data?

Thanks
Gz

[masonwu]

haha nevcairiel ,thank you for your work effort on these filter . and could i use the binary filter in my HTPC product ?

[sneaker_ger]

You have to follow the GPLv2, I guess.

[nevcairiel]

Originally Posted by GRENDIZER

One thing I do not understand is that in the LAV audio options, under "bitstreaming", wether "Dolby Digital (AC3)" is checked or not, the surround sound works, and the Audio receiver says it's "Dolby Digital". I thought that when it's not checked, LAV decodes the AC3 and in that case, the audio receiver would not receive any proper data?

Some audio drivers have an option to compress any audio into AC3 when connected via Optical, so that you can send multi-channel PCM over the link, and are not limited to stereo.

In any case, as long as you get audio and it sounds good, all is well!

[Fullmetal Encoder]

Originally Posted by nevcairiel

...while Haali also builds it on demand (Hey, i'm using Haalis matroskaparser library afterall!)

Does this mean we are a step closer to having full MKV ordered chapters support?

[nevcairiel]

Baby steps.

[STaRGaZeR]

Isn't this the same parser as Haali uses for mkv? Seeking works surprisingly similiar (read: very good)

[nevcairiel]

Originally Posted by STaRGaZeR

Isn't this the same parser as Haali uses for mkv? Seeking works surprisingly similiar (read: very good)

Since its the parser he wrote, i would assume its also used by his DirectShow filter.

[STaRGaZeR]

Me likes

[rica]

Originally Posted by SamuriHL

I'm going to point out the obvious one that people overlook....you're doing this with the 32 bit version of LAV and NOT the 64 bit version.............right?

Yes, it is 32 bit version on Seven 32 SP1 and i'm trying to decode a dtshd-master audio.