LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

I put it as a task on the bugtracker, i'll probably do it at some point, sometimes i need a day thinking about bits and assembler, instead of high level things - then i'll do it. :D

[CruNcher]

dscaler deinterlacing looked always a bit strange and broken to me, didnt provide good results. so I have always used either yadif or the ffmpeg deinterlacer

I meant using the Renderers Deinterlacer (Nvidia GPU) not Software ones and those results @ playback :)
so how does the Decoder behaves with VMRs internal Deinterlacing via Nvidias Pixel Adaptive Deinterlacer.
Lav Video gives Flawless results :)

[STaRGaZeR]

I put it as a task on the bugtracker, i'll probably do it at some point, sometimes i need a day thinking about bits and assembler, instead of high level things - then i'll do it. :D

No rush. So many interesting things to see implemented, like issue 16 :D

[Thunderbolt8]

I meant using the Renderers Deinterlacer (Nvidia GPU) not Software ones and those results @ playback :)
so how does the Decoder behaves with VMRs internal Deinterlacing via Nvidias Pixel Adaptive Deinterlacer.
Lav Video gives Flawless results :)ati here -.-

[mindbomb]

No, interlaced VC-1 does not work (and it'll be quite a while until it does)

i have the feeling this was mentioned before, but is there any chance you can incorporate an intel or microsoft vc-1 decoder in place of ffmpeg's?

or perhaps allow it to use ASVC1Vid.dll from arcsoft tmt5 similiar to how lav audio can use dtsdecoderdll.dll?
If that is possible, it would allow multithreaded vc-1 decoding as well as playback of interlaced vc-1.

[Midzuki]

or perhaps allow it to use ASVC1Vid.dll from arcsoft tmt5 similiar to how lav audio can use dtsdecoderdll.dll?

It would be interesting to see the VC-1 DMO decoder connect to a TS splitter. OK, ffdshow already does this, BUT it is not "aspect-ratio perfect" (yet - ?). ArcSoft's VC-1 decoder is not flawless either, see this:

http://forum.doom9.org/showthread.php?p=1519841#post1519841

[nevcairiel]

The MS VC-1 DMO decoder connects just fine to LAV Splitter when splitting TS files.

Anyhow, there are no plans to include any external video decoders at this time.

[Midzuki]

The MS VC-1 DMO decoder connects just fine to LAV Splitter when splitting TS files.

You are right :o , I wasn't aware of the fact that ffdshow has the power to prevent the direct access to the Microsoft wmv9 decoder. :mad:

[roytam1]

Newer nightly: http://roy.orz.hm/lavf-w32-nightlies/lavf-my110817-30d75eb3.7z

Notice: libav will commit Kostya's RM/RV patches which fixes the timestamping issue:
https://lists.libav.org/pipermail/libav-devel/2011-August/009461.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009479.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009536.html

But from my testing, its timestamps aren't better than the fake timestamps by NextPlayer's workaround patch.
So nevcairiel you may consider revert it in your ffmpeg.git branch once it is merged.

[Midzuki]

^ Thanks for the new build, gonna test it A.S.A.P.

For the time being... :devil:


Originally posted by mplayerc.exe

C:\Path-To\720x540.ts::Output
LAV Splitter::Video

Media Type 0:
--------------------------
Video: WVC1 960x540 (8:3) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}

subtype: Unknown GUID Name {D979F77B-DBEA-4BF6-9E6D-1D7E57FBAD53}

formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 139

VIDEOINFOHEADER:
rcSource: (0,0)-(960,540)
rcTarget: (0,0)-(960,540)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333667

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 8
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 67
biWidth: 960
biHeight: 540
biPlanes: 1
biBitCount: 12
biCompression: WVC1
biSizeImage: 777600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0010: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0020: 00 00 00 00 00 00 00 00 63 17 05 00 00 00 00 00 ........c.......
0030: 00 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 43 00 00 00 c0 03 00 00 ........C...À...
0050: 1c 02 00 00 01 00 0c 00 57 56 43 31 80 dd 0b 00 ........WVC1€Ý..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070:|00 00 00 01 0f e2 00 16 71 0d 0a 1d f8 43 7f 03 .....â..q...øC.
0080: 02 80 c8 80 00 00 01 0e 4c 10 80 .€È€....L.€


Media Type 1:
--------------------------
Video: WVC1 960x540 (8:3) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {629B40AD-AD74-4EF4-A985-F0C8D92E5ECA}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 139

VIDEOINFOHEADER:
rcSource: (0,0)-(960,540)
rcTarget: (0,0)-(960,540)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333667

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 8
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 67
biWidth: 960
biHeight: 540
biPlanes: 1
biBitCount: 12
biCompression: WVC1
biSizeImage: 777600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0010: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0020: 00 00 00 00 00 00 00 00 63 17 05 00 00 00 00 00 ........c.......
0030: 00 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 43 00 00 00 c0 03 00 00 ........C...À...
0050: 1c 02 00 00 01 00 0c 00 57 56 43 31 80 dd 0b 00 ........WVC1€Ý..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070:|00 00 00 01 0f e2 00 16 71 0d 0a 1d f8 43 7f 03 .....â..q...øC.
0080: 02 80 c8 80 00 00 01 0e 4c 10 80 .€È€....L.€


Media Type 2:
--------------------------
Video: WVC1 960x540 (8:3) 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 139

VIDEOINFOHEADER:
rcSource: (0,0)-(960,540)
rcTarget: (0,0)-(960,540)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 333667

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 8
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 67
biWidth: 960
biHeight: 540
biPlanes: 1
biBitCount: 12
biCompression: WVC1
biSizeImage: 777600
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0010: 00 00 00 00 00 00 00 00 c0 03 00 00 1c 02 00 00 ........À.......
0020: 00 00 00 00 00 00 00 00 63 17 05 00 00 00 00 00 ........c.......
0030: 00 00 00 00 00 00 00 00 08 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 43 00 00 00 c0 03 00 00 ........C...À...
0050: 1c 02 00 00 01 00 0c 00 57 56 43 31 80 dd 0b 00 ........WVC1€Ý..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070:|00 00 00 01 0f e2 00 16 71 0d 0a 1d f8 43 7f 03 .....â..q...øC.
0080: 02 80 c8 80 00 00 01 0e 4c 10 80 .€È€....L.€

[Midzuki]

Newer nightly: http://roy.orz.hm/lavf-w32-nightlies/lavf-my110817-30d75eb3.7z

By turning-off VC-1 decoding through ffdshow, MpegSplitter.ax can connect to the VC-1 DMO decoder, however LAV Splitter still cannot do it :confused:

As for LAV Video, it behaves the same as MPCVideoDec.ax, —

— that is to say, it still sucks at VC-1 -.-

[Sebastiii]

Not yet.
http://code.google.com/p/lavfilters/issues/detail?id=10

You can compile your own version, and in LAVAudio.h set "REQUEST_FLOAT" to 0.

Thank you,

I have tested yesterday and the connection is made but not all stream.

Is it possible that you can get a look on it please, just to know what is missing ? (i mean surely on MPAudio side or mediatype)

http://dl.dropbox.com/u/10536084/lav/Accurate_sync_ver_21a.zip

With this Audio Renderer for MP, it's really more smooth than Reclock, so it would be nice to make it work when LAVAudio :)

Cheers,
Seb.

This track didn't connect for example :
Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : ES
Codec ID : A_DTS
Duration : 2h 37mn
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 7 canaux / 6 canaux
Channel positions : Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48,0 KHz
Bit depth : 24 bits
Compression mode : Avec perte
Stream size : 1,66 Gio (21%)
Language : Français

[Gaius]

I signed up just to say thanks for LAV Filters. I was recommended them by a friend who mentioned you added a video decoder to it and since then, I've stopped using FFshow and just use LAV everything with MPC-HC.

[nevcairiel]

Notice: libav will commit Kostya's RM/RV patches which fixes the timestamping issue:
https://lists.libav.org/pipermail/libav-devel/2011-August/009461.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009479.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009536.html

But from my testing, its timestamps aren't better than the fake timestamps by NextPlayer's workaround patch.
So nevcairiel you may consider revert it in your ffmpeg.git branch once it is merged.

Your list here seems to lack the new RV30/RV40 parser, did you include that too in the test? Without it, it wouldn't work right.

Anyway, i'll test when its commited.

[nevcairiel]

As for LAV Video, it behaves the same as MPCVideoDec.ax, —

— that is to say, it still sucks at VC-1 -.-

If by sucks you mean it doesn't support interlaced, then sure.
Otherwise it just supports what ffmpeg supports, and all progressive files play just fine for me. If there are any decoding issues, then say ffmpeg sucks, because its the same shared component. :p

I also just updated ffmpeg for the AR and width/height fixes.

[nevcairiel]

Is it possible that you can get a look on it please, just to know what is missing ? (i mean surely on MPAudio side or mediatype)


That audio renderer is only designed to accept the exact same formats that WASAPI supports, and thats a absolutely *horrible* design.

DirectShow typically sends 24-bit as pure 24-bit, without padding. WASAPI on the other hand only likes 24-bit if its padded to 32-bit. Its the audio renderers job to do that!

Go complain at the people writing that audio renderer, its brain-dead stupid and should support simple sample-format conversion. As its designed right now, the only format it really understands is 16-bit integer. Thats a serious limitation, and i wouldn't use it.

[Midzuki]

As you wish, sir, ffmpeg sux :D

...

...

...that audio renderer, its brain-dead stupid and should support simple sample-format conversion. As its designed right now, the only format it really understands is 16-bit integer.

Man, that really suckxs :(

[roytam1]

Your list here seems to lack the new RV30/RV40 parser, did you include that too in the test? Without it, it wouldn't work right.

Anyway, i'll test when its commited.

Parsers were attached in 009479.html.

[nevcairiel]

btw, VC-1 interlaced in a MPEG-TS file, split with LAV Splitter, decoded with the MS DMO decoder.
Why would this not work?

http://images.gammatester.com/pics/e5e67090740325855f689cef159f527d.png

[nevcairiel]

Its time for another build!

This is Release Candidate 4, and from my side, the final release candidate before the final 0.32 at the end of the week.

x86: http://files.1f0.de/lavf/LAVFilters-0.32-rc4.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.32-rc4-x64.zip

Notable changes since the last build:
- Option for HQ pixel format conversion (note that HQ RGB conversion is right now way too slow for realtime 1080p 50/60fps content)
- ffmpeg updates

[starla]

That audio renderer is only designed to accept the exact same formats that WASAPI supports, and thats a absolutely *horrible* design.

DirectShow typically sends 24-bit as pure 24-bit, without padding. WASAPI on the other hand only likes 24-bit if its padded to 32-bit. Its the audio renderers job to do that!

Go complain at the people writing that audio renderer, its brain-dead stupid and should support simple sample-format conversion. As its designed right now, the only format it really understands is 16-bit integer. Thats a serious limitation, and i wouldn't use it.

Currently the audio renderer is in phase beta - not feature complete and it is stated that it doesn't support the resampling or bit depth conversions, those will come later. This is purely because of the development resources are lacking behind the real need (any free DS developers around? :)).

But thanks for the kind words anyways :)

br,
tourettes

[nevcairiel]

Currently the audio renderer is in phase beta - not feature complete and it is stated that it doesn't support the resampling or bit depth conversions, those will come later. This is purely because of the development resources are lacking behind the real need (any free DS developers around? :)).

But thanks for the kind words anyways :)

br,
tourettes

I didn't mean to offend anyone, but if it doesn't support anything more then 16-bit int, it just will not work with LAV Audio until the sample format conversion is implemented in either LAV Audio or the audio renderer. You can disable float in LAV Audio, but you cannot disable 24-bit integer for lossless sources.

[starla]

I didn't mean to offend anyone, but if it doesn't support anything more then 16-bit int, it just will not work with LAV Audio until the sample format conversion is implemented in either LAV Audio or the audio renderer. You can disable float in LAV Audio, but you cannot disable 24-bit integer for lossless sources.

No harm done. It was just a gap in communication about the features of in development component. Features that were kept away to simplify the testing of other parts (time strecthing, broken WASAPI drivers etc. were already hard enough to debug at once).

I really wish I would have time to work with the specific audio renderer, but other development has already stalled that work for about one year :(

[Sebastiii]

Thanks Nevcairiel and Starla for answer :)

[SamuriHL]

Its time for another build!

This is Release Candidate 4, and from my side, the final release candidate before the final 0.32 at the end of the week.

x86: http://files.1f0.de/lavf/LAVFilters-0.32-rc4.zip
x64: http://files.1f0.de/lavf/LAVFilters-0.32-rc4-x64.zip

Notable changes since the last build:
- Option for HQ pixel format conversion (note that HQ RGB conversion is right now way too slow for realtime 1080p 50/60fps content)
- ffmpeg updates

Installer:

http://www.mediafire.com/file/ckd4xh7vvips7a6/LAVFilters-0.32-rc4.exe

[nevcairiel]

Notice: libav will commit Kostya's RM/RV patches which fixes the timestamping issue:
https://lists.libav.org/pipermail/libav-devel/2011-August/009461.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009479.html
https://lists.libav.org/pipermail/libav-devel/2011-August/009536.html

But from my testing, its timestamps aren't better than the fake timestamps by NextPlayer's workaround patch.
So nevcairiel you may consider revert it in your ffmpeg.git branch once it is merged.

I actually tested the changes now, and the samples i have seem to work pretty good. I just had to change something in LAV Splitter to always use the DTS timestamps instead of the artificially generated PTS timestamps.

Here is a build with the ffmpeg changes applied, and the change to LAV Splitter, before i commit it:
http://files.1f0.de/lavf/LAVFilters-0.32-rc4-rm.zip

Please check if it works on your RM files as well, but i didnt have any issues with the samples you gave me, and i would greatly prefer to get rid of local changes, if the upstream changes work equally well.

[mbordas]

I hate to ask about anything to do with windows media player/center, cause I know the answer I'll probably get :)

But just out of curiosity, I have lavaudio & lavvideo working flawlessly in both by turning off all the tweaks in win7dsfilter EXCEPT the ms dtv-dvd video decoder, and by changing the registry keys for [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectShow\Preferred] to lavvideo.

The one thing that doesnt work is subtitles. But if I turn off the dtv-dvd decoder, I can't play dvds and I get really bad pq in live tv, as well as audio out of sync. I guess that's because wmp and wmc are locked to their decoder somehow and that's just the way it is. I just wondered if there might be some other workaround?

[roytam1]

I actually tested the changes now, and the samples i have seem to work pretty good. I just had to change something in LAV Splitter to always use the DTS timestamps instead of the artificially generated PTS timestamps.

Here is a build with the ffmpeg changes applied, and the change to LAV Splitter, before i commit it:
http://files.1f0.de/lavf/LAVFilters-0.32-rc4-rm.zip

Please check if it works on your RM files as well, but i didnt have any issues with the samples you gave me, and i would greatly prefer to get rid of local changes, if the upstream changes work equally well.

They plays smoothly here.
I only tested in avplay before, and the patchset works better in LAV Filters.

[e-t172]

WASAPI on the other hand only likes 24-bit if its padded to 32-bit.

That's only true for HDMI audio output. Most analog outputs work just fine with WASAPI Exclusive mode in "normal" 24-bit.

[noee]

That's only true for HDMI audio output. Most analog outputs work just fine with WASAPI Exclusive mode in "normal" 24-bit.

Yes and on my current ATI h/w (HD6570), multi-ch PCM out via HDMI works fine with 24bit WASAPI Excl. (using jRiver Media Center)

[CruNcher]

It seems absolute stable nev in it's current state also switch time in the Dshow chain is super fast :) i also see that it might not bad to actually combine MPC-HC and lav splitter because of certain playback scenarios where lav splitter could fail (especially renamed container) in this case low merrit included stuff becomes practical as it takes over.

PS: Also the Latm situation has improved allot :)

[nevcairiel]

I've been thinking about what i could do to improve the speed of swscale, because its really terribly slow, which i mostly attribute to the simple fact that its very generalized and not multithreaded.
It takes around 30ms to dither a 1920x1080 4:4:4 10bit frame to 4:4:4 8bit. Thats *alot* of time per frame. I have been thinking that i can do it alot faster in specialized code, which can only transform the most common formats.

Now, before i start implementing this, maybe someone that has also spent alot of time on this can comment on which dithering algorithms are preferable?
I'm currently looking at a standard ordered dithering (Bayes), which would be easy to implement and probably also quite fast.
As an alternative, i've been looking at Floyd-Steinberg error-diffusion dithering.

Any thoughts, or possible alternative ideas?
It shouldn't be a too complex algorithm, because it'll end up being slow, and plenty complicated to write in assembler. ;) Judging from that arguments, i would go with ordered. :d

Edit:
Some research shows that Floyd-Steinberg will most likely not be suitable for video dithering because it produces a jitter over the whole image when only small parts change.

[madshi]

Now, before i start implementing this, maybe someone that has also spent alot of time on this can comment on which dithering algorithms are preferable?
I'm currently looking at a standard ordered dithering (Bayes), which would be easy to implement and probably also quite fast.
As an alternative, i've been looking at Floyd-Steinberg error-diffusion dithering.

Any thoughts, or possible alternative ideas?
It shouldn't be a too complex algorithm, because it'll end up being slow, and plenty complicated to write in assembler. ;) Judging from that arguments, i would go with ordered. :d

Edit:
Some research shows that Floyd-Steinberg will most likely not be suitable for video dithering because it produces a jitter over the whole image when only small parts change.
AFAIK, Microsoft uses something similar (but not identical) to Floyd-Steinberg. I don't think there's any problem with jitter. We're not talking about reducing bitdepth to 1 bit, where such kind of jitter might be visible, we're reducing to 8 bit, where the dithering pattern should be pretty much invisible.

Best quality would of course be some kind of error diffusion. Floyd-Steinberg is a common used algorithm for that, but not necessarily the best. Ordered dither is a lot simpler and might be good enough. madVR currently uses TPDF dithering, similar to what is usually used in audio processing. TPDF dithering works like this:

(10bit + rand[0..3] - rand[0..3] + 2) >> 2 = 8bit

It might be better to increase the bitdepth of the whole calculation to achieve a better triangular distribution of the dithering noise. E.g.:

((10bit << 14) + rand[0..65535] - rand[0..65535] + 32768) >> 16 = 8bit

For the random values you could pre-calculate a full frame worth of white noise, and then choose a random offset into the frame for every new video frame. Or something like that...

Not sure whether ordered dithering or TPDF dithering is faster, cause I've never used ordered dithering yet.

[nevcairiel]

Ordered Dithering seems computationally speaking alot simpler then error diffusion, even a bit simpler then TPDF, but probably the same performance. swscale is doing ordered dithering now, and the result looks ok to me.
I don't think increasing the bitdepth is going to help. All the extra bits are 0, so only the first two bits will make a difference anyway. Or am i missing something?

Maybe i'll build some test version with two or three different algorithms to compare.

[pankov]

nevcairiel,
the sample mentioned in the madVR thread about then banding issue with VobSub does not play with LAV Splitter - it jumps directly to the end.
With Haali's splitter it plays fine.
Am I doing something wrong or is it a problem of LAV Splitter?

Here is the link if you can't find it
http://www.mediafire.com/?wbmyif3yf2mijti

[nevcairiel]

nevcairiel,
the sample mentioned in the madVR thread about then banding issue with VobSub does not play with LAV Splitter - it jumps directly to the end.
With Haali's splitter it plays fine.
Am I doing something wrong or is it a problem of LAV Splitter?

Here is the link if you can't find it
http://www.mediafire.com/?wbmyif3yf2mijti

The file seems to be H264 AnnexB muxed into MKV, such an format is very uncommon, not MKV spec-conform, and not supported (yet). :)
http://code.google.com/p/lavfilters/issues/detail?id=43

[Midzuki]

Just confirming, now LAV Video deals correctly with the AR flags in VC-1 :)

:thanks: :thanks: :thanks:

However, MpegSplitter.ax still is smoother than LAV Splitter. :devil:

Also, ffdshow still is faster than LAV Video. :devil: :devil:

BTW: any plans to add .vc1 (AND .264)to the input formats supported by LAV Splitter? :)

[Fadeout]

A problem I found is that this splitter doesn't seem to load linked/chaptered files. For example those anime where the OP is in a separate file to save space.

I was actually hoping to fix the other problem, the OP not playing well because the parameters aren't correctly loaded (only CoreAVC plays them fine).

[JEEB]

A problem I found is that this splitter doesn't seem to load linked/chaptered files. For example those anime where the OP is in a separate file to save space.
Ordered chapters-based segment linking is not supported by the libavformat demuxer yet. I remember elenril talking about implementing this with his playlist efforts, but so far he's been busy with other stuff.

tl;dr
LAV Splitter won't support this before libavformat will, unless nev codes it all in.

I was actually hoping to fix the other problem, the OP not playing well because the parameters aren't correctly loaded (only CoreAVC plays them fine).
Rephrase yourself, thank you. What exactly from the container or video stream does not get read?

[Fadeout]

What I mean is that with certain videos even with Haali + DXVA or internal CPU decoding some parts of these linked files aren't properly decoded (showing green screen with boxes of colors and corrupted stuff, but if you load the single segment it works fine), only CoreAVC does it properly (both in DXVA and CPU).

Possibly because the two segments are encoded in slightly different ways, so there's a possibility it can be fixed in the splitter, I don't know.

[Barlow]

What I mean is that with certain videos even with Haali + DXVA or internal CPU decoding some parts of these linked files aren't properly decoded (showing green screen with boxes of colors and corrupted stuff, but if you load the single segment it works fine), only CoreAVC does it properly (both in DXVA and CPU).

Possibly because the two segments are encoded in slightly different ways, so there's a possibility it can be fixed in the splitter, I don't know.

This is not a splitter issue. The problem is that some decoders do not like video parameters to change during playback. The internal MPC-HC video decoders have this problem (both DXVA and software) and the Microsoft DTV decoder has as well.
But CoreAVC is certainly not the only decoder to handle this correctly: both the LAV video decoder and the video decoder bundled with MadVR work correctly.

[rpm7200]

@nevcairiel
please, add lav cuvid decoder to the lav filters. sorry my bad english.

[lauhangwoo]

This (http://www.geocities.co.jp/lauhangwoo/etc/sample.zip) sample has no audio when I'm using LAV Splitter + WMP12 Decoder.
LAV Splitter + LAV Audio/ffdshow or MPC Splitter + any of these decoders works fine.

Also, I hope LAV Video's formats configuration having bit more organized order like LAV Audio's one, something like...

// ISO
mpeg1
mpeg2
mpeg4
msmpeg4

// ITU
h261
h263
h264

// Windows Media
wmv1/2
wmv3
vc-1

// On2
vp3 (including Theora)
vp6
vp8

// Sorenson
flv
svq

// Old QT
qtrle
qtrpza

// Old AVI
cinepak
indeo

// Camera
mjpeg
dv

// Real
rv1/2
rv3/4

// Game
smacker
bink

// Capture
camstudio
camtasia
fraps

// Compression
huffyuv
lagarith
zlib
qpeg

[clsid]

I noticed you added icons for the filters. Here are some comments:
- are the 256x256 icons really needed?
- 128x128 is not a size that Windows ever uses by default
- for the tray icon and start menu you only need 16x16 and 32x32
- the 16x16 icons do not look very good, partially because they do not use the full size, they have a transparent border like the larger ones, which is imo a waste for small sizes.

What do you think about something like this:
http://i.imgur.com/KBgLx.jpg

[Thunderbolt8]

I think the white letters are way better readable as small tray icon

[nevcairiel]

I didn't like the font you used, so i did some of my own in white with a slightly different layout

32x32:
http://files.1f0.de/icon/icon32.png or with softer scaling http://files.1f0.de/icon/icon32c.png

16x16
http://files.1f0.de/icon/icon16.png or with softer scaling http://files.1f0.de/icon/icon16c.png

[pankov]

nev,
I like your white letters but I really like the blue that clsid used (more intense). I guess it's because it's probably my favorite color ;)

[nevcairiel]

Yeah i thought it was too bright, the big white letters make it really look odd.

[Thunderbolt8]

so your white letters and clsids blue background and bingo

[nevcairiel]

Like that?

32x32:
http://files.1f0.de/icon/icon32d.png

16x16
http://files.1f0.de/icon/icon16d.png

Now i just need two more colors that look good, and i'm set. :p