View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
CruNcher
16th December 2011, 00:11
Hmm nev i encountered a very interesting FLV seek issue (instability) that isn't apparent in the Native MPC-HC splitter though it was with the latest official release not the newer update you posted recently (didn't checked that yet) i added this flv issue to my list, if i checked the latest update and it's still their i gonna post a sample of this issue.
THX-UltraII
16th December 2011, 09:36
Hi Nevcairiel,
First of all I would like to thank you for creating LAV filters.
I want to ask you if something is possible:
You ever heard of D-Box motion code system? People (D-Box owners) where looking for a HTPC solution for D-Box for years and a guy from the AVS forum modified your LAV version to finally achieve what D-Box self told was impossible: simultaneously audio output of 2 streams at the same time; one stream with the HD audio (going to a receiver via HD video card to be able to get HD audio) and one stream with the lossy dts/dd stream (going to D-Box decoder via external spdif usb audio card). This was needed because D-Box motion systems uses only the lossy dts/dd streams to be able to detect movies. With a player like PowerDVD you can only select one audio stream and one audio device. That is a problem for Blurays because you cannot use the HD streams (TrueHD, DTS-HD or LPCM) and the D-Box system simultaneously.
So a guy from the AVS forum modified MPC-HC and your LAV Filters to use two audio streams with two audio devices:
- The HD audio will be sent through HDMI to the A/V Receiver (bitstream).
- The lossy AC3 or DTS will be sent as bitstream through SPDIF (digital or coax) to the D-Box controller
His latest version is 0.40 and every time you release a new version he has to modify it and release a separate version (can t get in contact with him for a month now and I really want the new features that 0.42 brought).
Is there a change you can integrate this in your official versions or post a 'D-Box version' everytime you release a new LAV version?
nevcairiel
16th December 2011, 13:44
I have no interest in such a feature, and my limited time is better spent on features that i do have an interest in, because thats more fun doing. :)
Anyhow, i'm not totally against such an idea, so if anyone wants to provide a clean patch to do what it needs to do (and is willing to work with me to get it in proper shape) I'm willing to listen, and at least look it over.
THX-UltraII
16th December 2011, 15:04
I understand that you are not interested in this but thanks you are willing to cooperate with this!
Here s the site where Germain (a D-Box user) modified your LAV filters to get the result D-Box users need.
http://htpcfordbox.over-blog.com/
I tried to reach him for almost a month now but can t get in contact with him anymore since the last update to 0.40 he did. I need some fixes you implemented in 0.41 and 0.42 but don t have a clue how to modify your version to his version.
Reino
16th December 2011, 19:09
Unlike MPC-HC's internal MKV Splitter, letting LAV Splitter handle this, DVD-Audio-testfile (ARAW;24bit,96000Hz,4608Kbs).mka (http://www.mediafire.com/?km42s999u8rgfcc), file results in an immediate crash.
It's the original DVD-Audio-testfile.wav (iirc also posted here somewhere on the forum) converted to WavPack and put in a Matroska container.
nevcairiel
16th December 2011, 21:06
Unlike MPC-HC's internal MKV Splitter, letting LAV Splitter handle this, DVD-Audio-testfile (ARAW;24bit,96000Hz,4608Kbs).mka (http://www.mediafire.com/?km42s999u8rgfcc), file results in an immediate crash.
It's the original DVD-Audio-testfile.wav (iirc also posted here somewhere on the forum) converted to WavPack and put in a Matroska container.
Thats so odd.
- LAV Splitter + LAV Audio = crash
- LAV Splitter + ffdshow = all fine
- Other splitter + LAV Audio = all fine
I think i figured it out though, the new ffmpeg audio decoding API is at fault here.
Edit:
Fixed
mllmx
17th December 2011, 09:40
Long time reading, first time posting. First I want to thank nevcairiel for developing this amazing filters. I've just upgraded from an htib Onkyo to a Denon AVR-2112, I used to have the Onkyo plugged to the analog outputs and use dtsdecoderdll.dll for DTS-HD decoding. Now I'm bitstreaming everything and I couldn't help to notice something odd in the chain using graphstudio. It goes Lav Splitter -> Lav Audio Decoder -> DirectSound. The issue is this: I can't get Lav Splitter to output 24 bit audio.
Every file I test is shown in the out pin of Lav Splitter as 16 bit. MediaInfo shows the bitdepth ok.
The results in grapstudio are:
16/48->16/48
24/48->16/48
24/96->16/96
I'd really like to know what am I doing wrong here, since when I was using the analog path with reclock it was 24 bit from start to end of the chain.
Hope someone can help.
nevcairiel
17th December 2011, 10:25
The bitdepth communicated by LAV Splitter is of little consequence. Whats important is what LAV Audio shows on its status page.
Reino
17th December 2011, 22:16
Fix confirmed, thank you.
While both the LAV Splitter and LAV Splitter Source have the same merit by default, I noticed after a setup install the latter is being used in almost all cases, instead of File Source (Async) + LAV Splitter (manual install). Why's that and can you tell me what the difference between them is?
I got some more LAV Splitter troubling samples for you:
IMA ADPCM Audio
shuffle-ima41.mov (http://samples.mplayerhq.hu/A-codecs/ima-adpcm/shuffle-ima41.mov): connecting to FFDShow fails.
QDM2 Audio
sample_sorenson.mov (https://support.apple.com/kb/ht1425): connecting to FFDShow fails.
AMV[AMVV+IMA ADPCM AMV]
comedian.amv (http://samples.mplayerhq.hu/amv/comedian.amv):
- seeking bar unavailable
- although FFDShow is capable of decoding both the video and audio part ("Other MJPEG" and "Other ADPCM" on Codecs-tab of Video and Audio Decoder config respectively), it fails to connect to FFDShow.
- no problem with MPC-HC's internal AVI Splitter.
- funny notice: although LAV Audio Decoder can decode the audio part, in MPC-HC the LAV Splitter, without any decoding, passes it through to the build-in Audio Switcher (if it's enabled),...resulting in horrible noice. :p
Reino
18th December 2011, 01:17
Nellymoser
http://samples.mplayerhq.hu/A-codecs/Nelly_Moser/nellymoser-in-flv.flv (http://samples.mplayerhq.hu/A-codecs/Nelly_Moser/nellymoser-in-flv.flv): seeking bar unavailable.
http://samples.mplayerhq.hu/A-codecs/Nelly_Moser/h264_NellyMoser.mp4 (http://samples.mplayerhq.hu/A-codecs/Nelly_Moser/h264_NellyMoser.mp4): connecting to FFDShow Audio Decoder fails.
LAV Splitter - Subtitle Selection Mode
While testing today's build (by XhmikosR (http://xhmikosr.1f0.de/lavfilters/LAVFilters-0.42-20111217_1256.exe)) I noticed something strange. It seems the "Subtitle Selection Mode"-option has been compromised for some(!) files (at least when set to "Default". haven't tested the others).
Somehow no subtitle stream is automatically selected while starting a movie with embedded subs of which 1 is flagged as default. LAV Filters 0.42 from 30 november doesn't have this issue.
I'd like to stress though that it only concerns 'some'(!) files. But after a lot of searching I couldn't find the determining factor. The only thing that caught my attention was MPC-HC's Properties window on 2 different movies:
LAVFilters 0.42 (30112011):
Video: MPEG4 Video (H264) 1280x544 24.00fps [Video]
Audio: Dolby AC3 48000Hz 6ch 448kbps [Audio]
Subtitle: UTF-8 [Subtitle]
Video: MPEG4 Video (H264) 864x360 23.98fps [Video]
Audio: Vorbis 48000Hz stereo [Audio]
Subtitle: UTF-8 [Subtitle]
====================================
LAVFilters 0.42 (17122011):
Video: MPEG4 Video (H264) 1280x544 24.00fps [Video]
Audio: Dolby AC3 48000Hz 6ch 448kbps [Audio]
Text [Subtitle]
Video: MPEG4 Video (H264) 864x360 23.98fps [Video]
Audio: Vorbis 48000Hz stereo [Audio]
Text [Subtitle]
Paladin77
18th December 2011, 11:27
+1 I was facing a similar problem when I was told that the subs weren't flagged properly as default (don't bite my head off that's what encoders told me, probably whoever encoded the file didn't do a good job in flagging sub stream as default). Anyways a few pages back when I asked for a workaround: http://forum.doom9.org/showpost.php?p=1544529&postcount=7666
FYI I am using latest compiled build of LAV filters as well by XhmikosR
EDIT Confirmed. I blocked Haali and tried a multi subtitle stream mkv file WITHOUT that workaround. Default stream doesn't load I get no subtitles and have to load it manually or use that workaround I mentioned above.
Sample here: http://www.filesonic.com/file/1015487831/haruhi_suzumiya_no_yuutsu_hare_hare_yukai.mkv
EDIT 2: Just as control I retried with Haali an subs load normally. So the Stream is indeed flagged as default. Will try to hunt an old LAV version and try again.
nevcairiel
18th December 2011, 12:15
EDIT Confirmed. I blocked Haali and tried a multi subtitle stream mkv file WITHOUT that workaround. Default stream doesn't load I get no subtitles and have to load it manually or use that workaround I mentioned above.
Sample here: http://www.filesonic.com/file/1015487831/haruhi_suzumiya_no_yuutsu_hare_hare_yukai.mkv
The first subtitle stream is properly flagged default, and LAV activates it just fine for me.
Subtitle Selection Mode set to "Default". Tried with both no languages configured and languages configured to "eng" and "eng,und"
Maybe the build you're using is defective. :)
There haven't been any changes to the selection logic for a while, and everything seems fine for me.
Try with this instead: http://files.1f0.de/lavf/LAVFilters-0.42-25-g8c422f8.zip
No changes, just a build that i know is working.
Paladin77
18th December 2011, 13:21
Fixed thank you. Must've been a defective build as you said. Sorry for the hassle.
dead_screem
18th December 2011, 20:41
Some ISDB-T TS files have their 1seg sub program auto selected instead of the main program, started happening some time after 0.42, first happens in previous test build 0.42.10.
http://www.megaupload.com/?d=QBRH6F6I
Its about time we had proper program switching added, and also to do away with automatically selecting the "best" program and just default to the first program.
nev, you had a chance to look into this bug?
Mosu
19th December 2011, 11:20
In my experience, trusting the MKV header information is even worse (it commonly has 60 fps for interlaced 60i content, which is just not correct). The only reliable thing would be to decode some frames and see what we get, but thats really alot more effort then worth (and VFR still blows that ouf of the water)
Matroska headers do NOT have a field for the number of frames per second. It's a common misconception. They do have a field that indicates the default duration for a frame. Its inverse is often used as the number of FPS which is correct often enough, but it simply is not the same (nor is it meant to be).
The rules for a block's duration are simple (in decreasing order of priority):
If a BlockGroup contains a Duration element then use that.
If the track's headers contain a DefaultDuration element then use that.
Else use the difference between the current block's timecode and the next block's timecode.
The rules for timecodes are even simpler: Each block has a timecode on the container level. This one trumps everything else (e.g. if the bitstream itself contains a timecode or something else calculated on e.g. default_duration & number of frames).
It doesn't matter whether or not other container formats (e.g. MP4) have different semantics. These are the semantics that Matroska use.
nevcairiel
19th December 2011, 11:27
Matroska headers do NOT have a field for the number of frames per second. It's a common misconception. They do have a field that indicates the default duration for a frame.
Which is even another argument for not using it as FPS information, and rather use the bitstream or try to measure it.
PS:
There never was a question about the actual timecodes, just how to figure out the fps of the file.
madshi
19th December 2011, 11:43
@Mosu, just to explain: Any "FPS" information retrieved by trying to interpret the MKV file is not actually "used" during playback, but the DirectShow system expects a splitter to forward a generic FPS information to the downstream filters. This information is what the discussion was about. This FPS information field is often used by display mode / refresh rate switchers to switch the GPU into the right display mode / refresh rate. Because of that it's kinda important to get this information right and since MKV doesn't have a reliable and always set correctly "FPS" field, the big question is how to best get an "FPS" information from an MKV file.
Or in other words: How can a refresh rate switcher quickly look at an MKV file and decide which refresh rate to switch the GPU to, for playback of this MKV file?
e-t172
19th December 2011, 12:00
FWIW, ReClock doesn't trust any FPS information from the source filter and just calculates the FPS from the first 5 seconds of timestamps or so. That's why ReClock only starts a few seconds after the beginning of playback. When used with a refresh rate script, this means that the refresh rate will change a few seconds after playback starts. Which is a little annoying, but at least it's reliable.
My opinion is that it's the job of the video renderer to determine the correct refresh rate, and it should do so using the timestamps on the first 5 frames or so. In this case we don't need enormous precision on the FPS value since the possible refresh rates are given by the OS anyway. Also, the renderer should constantly watch the timestamps for changes in average FPS and switch again if it changes. One typical application would be live TV, where the renderer would automatically switch between 60p and 24p when IVTC kicks in and out.
nevcairiel
19th December 2011, 12:09
One typical application would be live TV, where the renderer would automatically switch between 60p and 24p when IVTC kicks in and out.
Thats absolutely not practical, as on todays monitors/TVs a switch is a rather disruptive process. There is VFR material which switches quite frequently between 24p and 30p, doing a refresh rate change every time would entirely destroy the viewing experience.
madshi
19th December 2011, 12:13
FWIW, ReClock doesn't trust any FPS information from the source filter and just calculates the FPS from the first 5 seconds of timestamps or so. That's why ReClock only starts a few seconds after the beginning of playback. When used with a refresh rate script, this means that the refresh rate will change a few seconds after playback starts. Which is a little annoying, but at least it's reliable.
My opinion is that it's the job of the video renderer to determine the correct refresh rate, and it should do so using the timestamps on the first 5 frames or so. In this case we don't need enormous precision on the FPS value since the possible refresh rates are given by the OS anyway. Also, the renderer should constantly watch the timestamps for changes in average FPS and switch again if it changes. One typical application would be live TV, where the renderer would automatically switch between 60p and 24p when IVTC kicks in and out.
All true, but it's not as easy as you make it sound. The framestamps of broadcasts are often not reliable. I have samples where even the timestamps of I-frames are juddering like hell. Looking at the first 5 frames, only, wouldn't work at all to get a reliable FPS information, especially if you want to support both 24fps and 25fps sources. Even worse, if you want to support 23.976fps and 24.000fps sources. But I agree with you that the video renderer should watch over timestamps and react according to the circumstances. That's on my to do list for madVR. I just don't think that 5 frames will cut it. Not even close.
BTW, the funny part starts if you have film sources with video overlay. Do you switch to 24Hz or 60Hz for such sources? What if the video overlay comes and goes for a couple of frames, all the time? (These are rhethorical questions.)
sneaker_ger
19th December 2011, 12:16
One answer: get a 120 Hz display.
STaRGaZeR
19th December 2011, 14:07
One answer: get a 120 Hz display.
http://img854.imageshack.us/img854/2237/sinttuloqo.th.png (http://imageshack.us/photo/my-images/854/sinttuloqo.png/)
;)
There are problems thou: lack of quality monitors, lack of TVs, crappy HDMI not supporting 1080p120, 25/50 if you live in Europe, possible incompatibility with 48p and other retarded "new" framerates, etc.
nevcairiel
19th December 2011, 16:05
IMA ADPCM Audio
shuffle-ima41.mov (http://samples.mplayerhq.hu/A-codecs/ima-adpcm/shuffle-ima41.mov): connecting to FFDShow fails.
QDM2 Audio
sample_sorenson.mov (https://support.apple.com/kb/ht1425): connecting to FFDShow fails.
No idea why ffdshow doesn't like those, it doesn't seem to do anything much different then i, but then again, i honestly don't care about some odd-ball formats. I added a special interface to LAV Audio to ensure that nearly all audio can be decoded, even when there is no "standard" DirectShow type between them, and for the rare/odd/old formats, i suggest to just use it.
AMV[AMVV+IMA ADPCM AMV]
comedian.amv (http://samples.mplayerhq.hu/amv/comedian.amv):
- seeking bar unavailable
- although FFDShow is capable of decoding both the video and audio part ("Other MJPEG" and "Other ADPCM" on Codecs-tab of Video and Audio Decoder config respectively), it fails to connect to FFDShow.
- no problem with MPC-HC's internal AVI Splitter.
- funny notice: although LAV Audio Decoder can decode the audio part, in MPC-HC the LAV Splitter, without any decoding, passes it through to the build-in Audio Switcher (if it's enabled),...resulting in horrible noice. :p
Should be fixed, except the seeking bar. It just doesn't have a duration for the file, no duration = no seeking, thats a issue more for the ffmpeg guys then me. ;)
nevcairiel
19th December 2011, 16:16
nev, you had a chance to look into this bug?
There isn't technically a "bug".
The logic does what its supposed to do - select the first program in a file which has audio and video - in your case its just not the program you want.
I could probably try to add some more logic to also prefer higher resolution content, however i would rather not add any more temporary hacks and just work on program switching at some point in the future. When, i cannot say.
looney
19th December 2011, 17:10
Also, you seem to be repeating yourself.
infact-infact it aint nice thing to say ;) or mock up just because i didnt lector myself, those was my troubles written up onto forum post, i wasnt try to sell a book.
I get full 100% CPU usage when benchmarking the x86 version on a quad-core, which means it uses multi-threading just fine.
Try to set the threads option to some specific value, something like 4 or 6, maybe Auto isn't working right.
Default MTn for 0.37-0.39 and now 0.42 is 2 threads (i didnt mess anything just install). But still 36% is way lower (by praised W7 by 14%) than underclocked x4 can do @2.5GHz. So to repeat myself as you stated x86-64 works with at least two cores, while x86 version is stucked on one core only when LAV default settings MTn=2cores are selected. It wans't on Auto (FO=Auto but my source is progressive and i can diff those two)
Sry, if my kb eat up some chars.
Reino
19th December 2011, 18:37
I added a special interface to LAV Audio to...Don't get me wrong, LAV Audio does a good job. It's LAV Splitter that's concerned here! With these 2 files it does connect to FFDShow's Video Decoder, but not to its Audio Decoder.Should be fixed, except the seeking bar. It just doesn't have a duration for the file, no duration = no seeking, thats a issue more for the ffmpeg guys then me. ;)Ok, well thanks for your effort though. It's just that with this file the MPC-HC AVI Splitter connects to FFDShow's Video and Audio Decoder no problem AND seeking is possible.
I thought your aim was to at least equal MPC-HC filters their capabilities, so that's why I'm reporting.
nevcairiel
19th December 2011, 18:47
Don't get me wrong, LAV Audio does a good job. It's LAV Splitter that's concerned here! With these 2 files it does connect to FFDShow's Video Decoder, but not to its Audio Decoder.
Since there is no "standard" for these formats, i could as well just claim that my way is the right way, and ffdshow is doing it wrong, but thats just pointless.
The point is, i will not spend extra effort to support ffdshow on these rather obscure codecs (especially considering no-one even knows how or why ffdshow does some things)
LAV Audio only works because there is magic going on between LAV Splitter and LAV Audio which will allow like 99% of all audio to be decoded.
FWIW, it does actually seem to be a ffdshow problem. It has some strict restrictions on accepting these codecs, even though those wouldn't be required.
This falls into my category of not adding "hacks" to support broken filters.
Ok, well thanks for your effort though. It's just that with this file the MPC-HC AVI Splitter connects to FFDShow's Video and Audio Decoder no problem AND seeking is possible.
I thought your aim was to at least equal MPC-HC filters their capabilities, so that's why I'm reporting.
The MPC-HC AVI Splitter doesn't even get used for that file for me, it falls back to the MS Avi Splitter.
I didn't try forcing it manually in GraphStudio or something, just in MPC-HC itself.
Reino
19th December 2011, 20:17
No problem! I can understand you'd like to keep your code "clean". I don't know the details, but iirc QuickTime support in FFDShow is done with lots of hacks, so I can understand your reasoning. Thanks for the info.
boyumeow
20th December 2011, 03:59
@CoRoNe & Paladin77,
RoyTam build is at http://roy.orz.hm in case U need it to compare with. Thanks.
dead_screem
20th December 2011, 04:27
There isn't technically a "bug".
The logic does what its supposed to do - select the first program in a file which has audio and video - in your case its just not the program you want.yes, there is. It worked perfectly fine in 0.42, the main program gets selected. starting in 0.42.10 1seg gets selected. And unless there is something else to it... the main 1080i mpeg2 program IS the first program as far as i can tell by looking in mediainfo.
I could probably try to add some more logic to also prefer higher resolution content, however i would rather not add any more temporary hacks and just work on program switching at some point in the future. When, i cannot say.
seeing as this used to work fine... I would imagine that finding out what was changed between 0.42 and 0.42.10 and see what broke it.
Aleksoid1978
20th December 2011, 04:44
The MPC-HC AVI Splitter doesn't even get used for that file for me, it falls back to the MS Avi Splitter.
I didn't try forcing it manually in GraphStudio or something, just in MPC-HC itself.
Internal MPC Avi Splitter work fine with comedian.amv
http://i031.radikal.ru/1112/05/f0f5286218dct.jpg (http://radikal.ru/F/i031.radikal.ru/1112/05/f0f5286218dc.png.html)
nevcairiel
20th December 2011, 09:07
Internal MPC Avi Splitter work fine with comedian.amv
http://i031.radikal.ru/1112/05/f0f5286218dct.jpg (http://radikal.ru/F/i031.radikal.ru/1112/05/f0f5286218dc.png.html)
thats not the internal avi splitter, thats the stand-alone registered version. :P
nevcairiel
20th December 2011, 09:39
seeing as this used to work fine... I would imagine that finding out what was changed between 0.42 and 0.42.10 and see what broke it.
I found what changed, but anyway, that doesn't change the fact that its basically coincidence that the program you want is the first in the file.
Aleksoid1978
20th December 2011, 11:31
thats not the internal avi splitter, thats the stand-alone registered version. :P
No - it's internal filter. I don't have MPC-HC filter as external in system. It's connect to File Async source.
nevcairiel
20th December 2011, 20:58
Here is a test build of all changes up until now. You can consider it a release candidate.
http://files.1f0.de/lavf/LAVFilters-0.42-45-gbd824b1.zip
There have been a few regressions caused by the audio API change in ffmpeg, however i do hope that i got all of those fixed by now.
Preliminary changelog since 0.42:
- Improved mkv keyframe seeking
- Improved handling of soft-telecine material and cuvid deinterlacing
- Performance enhancements during buffering (less likely to cause your playback to glitch)
- Media Type fixes for some audio formats
- Disabled Float audio by default on Windows XP to avoid buggy audio drivers
- Improved support for 10-bit 4:2:2 content
- Fixed a crash in LAV Video when the downstream filter did not provide a aligned buffer
- Support for AMV decoding
I plan to release this tomorrow or the day after, so if you still find/know of any regression since 0.42 (or maybe another bug), say so now. :)
mkanet
20th December 2011, 22:11
Some of you might remember the issue I mentioned with mixed soft/hard telecined mpeg2 HDTV content.
Strictly for academic purposes (trying to educate myself), I was hoping someone would be nice enough to explain why people see the stuttering effect during soft-telecined sections of these type of mixed videos on specific video cards.
Is it that the video card doesn't honor soft-telecine flags in mixed content? What would be the best explanation to why the below Nvidia display cards can comfortably handle these parts of the videos; and, other display cards can't as well. I noticed that my Nvidia 545GT stutters even worse during the soft-telecine sections of the video when adding video processing such as edge enhancement, color enhancement, and AAx16).
Do some display cards with extra mpeg2 hardware decoding capabilities introduce a bug; or, is it performance related? I'm not sure why my old junky 2nd gen Purevideo HD GeForce 8500GT would playback this content very nicely; but my 4th generation Nvidia 545GT can't handle it. Both display cards have an IVTC option that's supposed to work; which I'm guessing only works when my display is set to 23.976hz:
http://i67.photobucket.com/albums/h283/mkanet/th_2IVTC.jpg (http://i67.photobucket.com/albums/h283/mkanet/2IVTC.jpg)
http://i67.photobucket.com/albums/h283/mkanet/2IVTC.jpg
This is the list of cards that are reported to not have any issues. All I have to do is swap my 545GT with the 8500GT for the stuttering to completely go away on mpeg2 (same computer, drivers, settings, and directshow filters):
GeForce 8500 GT
GeForce 8600 GT/GTS
GeForce 9300
GeForce 9400 (including ION platforms)
GeForce GT 430
GeForce GT 440
nevcairiel
20th December 2011, 22:20
This is not a topic directly related to LAV Filters, so please take it to a new thread for discussion.
FWIW, my GTX 570 and GTS 450 have no issues either.
mkanet
20th December 2011, 22:52
So sorry Nev. I didn't mean any disrespect. I guess I got spoiled by all the smart friendly people in this thread. I'll post my questions in a different thread. I will try to latest build to see if it will help any with the issue.
This is not a topic directly related to LAV Filters, so please take it to a new thread for discussion.
FWIW, my GTX 570 and GTS 450 have no issues either.
hubblec4
21st December 2011, 00:29
hi nevcairiel
this fearure:
Added support for MKV nested chapters
means that its possible to play a mkv with multiple editions?
i have tested it with the movie Green Lantern. there are two editons.
when i play the video i cant find any way to select the editions. the video plays the entire file (first editon and the rest).
nevcairiel
21st December 2011, 00:32
this fearure:
Added support for MKV nested chapters
means that its possible to play a mkv with multiple editions?
No, it does not. It means what it says, it allows you to navigate into nested chapters, ie a structure like this:
A
-> A1
-> A2
-> A2.1
B
Before, it would only show A and B.
It does not change playback at all. People need to stop assuming so many things. You mention MKV and chapter, and they are like "OMG OMG". Jeez. MKV has normal chapters, too! :)
sexus
21st December 2011, 07:24
Or just use LAV Audio decoder, it can decode pretty much everything.
Even though it's based on ffmpeg, which is (or was) limited to 16 bit in ffdshow for flac, I think nevcariel fixed that issue.
However, for guaranteed compatibility, it would be nice if madshi and nevcariel would access madflac in LAV Audio directly, the way he has with the Arcsoft DTS decoder.
Then we would have one complete audio decoder for everything. And stream switching, even for different audio types, should just work.
is this possible to integrate into your lav filters nevcairiel ? then we wouldnt have to use madflac anymore , since madflac crashes my mpchc on switching flac tracks in my movie -.-'
Here is a test build of all changes up until now. You can consider it a release candidate.
http://files.1f0.de/lavf/LAVFilters-0.42-45-gbd824b1.zip
There have been a few regressions caused by the audio API change in ffmpeg, however i do hope that i got all of those fixed by now.
Preliminary changelog since 0.42:
- Improved mkv keyframe seeking
- Improved handling of soft-telecine material and cuvid deinterlacing
- Performance enhancements during buffering (less likely to cause your playback to glitch)
- Media Type fixes for some audio formats
- Disabled Float audio by default on Windows XP to avoid buggy audio drivers
- Improved support for 10-bit 4:2:2 content
- Fixed a crash in LAV Video when the downstream filter did not provide a aligned buffer
- Support for AMV decoding
I plan to release this tomorrow or the day after, so if you still find/know of any regression since 0.42 (or maybe another bug), say so now. :)
well still waiting for dvd support ;)
ryrynz
21st December 2011, 07:50
Yeah having that is going to be awesome.
He's started on it as shown below, hopefully can make it into the next release.
http://code.google.com/p/lavfilters/issues/list
sexus
21st December 2011, 09:31
yeah i hope so too so we can finally remove ffdshow video from the equation for good ...
hubblec4
21st December 2011, 11:56
No, it does not.
Have you planned for the future such a function?
It is very important, as more and more films appear with two versions.I would like to keep both versions, and only Haali splitter can handle properly at the moment.
bjd
21st December 2011, 12:15
@nevcairiel
I am just testing the latest version of the video decoder and in particular the "Treat as Progressive" option.
1) If "Treat as Progressive" is enabled for mpeg2 source either soft telecine NTSC region1 dvd or region2 PAL and the cuvid decoder set to 50p/60p, I get either 50p or 60p rendered. Should I not get the same frame rate as I input as it is supposed to be a progressive stream being decoded so interlacing should be ignored ?
nevcairiel
21st December 2011, 12:50
I am just testing the latest version of the video decoder and in particular the "Treat as Progressive" option.
1) If "Treat as Progressive" is enabled for mpeg2 source either soft telecine NTSC region1 dvd or region2 PAL and the cuvid decoder set to 50p/60p, I get either 50p or 60p rendered. Should I not get the same frame rate as I input as it is supposed to be a progressive stream being decoded so interlacing should be ignored ?
Works fine here, no frame gets deinterlaced, it generates 24/25 fps on soft-telecine or PAL material respectively.
bjd
21st December 2011, 13:22
thanks Nev, that is what i expected it do :confused:
I will do some more testing as i am getting the same results on two different systems. So just to confirm i should be able to pass 23.976 from NTSC soft telecine or 25p PAL to MadVR with this option enabled ?
nevcairiel
21st December 2011, 13:23
Sure, but at least for soft-telecined NTSC the mediatype will most likely say 29.97, and not 23.976, sadly thats not easy to correct.
bjd
21st December 2011, 13:43
Thanks again.
It seems having Bob or Adaptive enabled overrides "Treat as Progressive" for me. None (Weave) corrects the issue,and then i can use the 47i madvr hack to get the display rate correct in madvr for NTSC source.
nevcairiel
21st December 2011, 16:21
LAV Filters 0.43
LAV Splitter
- Improved MKV seeking and demuxing performance
- Improved buffering for smoother playback (especially at start/after seeks)
- Fixed a few audio media type issues
- Fixed a minor resource handle leak
LAV Audio
- Updated to new ffmpeg audio decoding API
- Disabled Float Audio output on Windows XP by default
LAV Video
- Fixed handling of soft-telecined MPEG2/H264 broadcasts in CUVID mode
- Improved support for 4:2:2 10-bit streams
- Fixed a crash related to unaligned memory buffers on Windows XP
- Added support for decoding AMV streams
Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.43.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.43.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.43-x64.zip)
Nothing to see here, move along!
In case you find a regression or another kind of bug, you may stay and report it, however.
Merry Christmas to everyone!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.