View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
Shark007
6th December 2012, 14:53
I meant that DXVAChecker doesn't want to detect my onbard nvidia card. It detects only the integrated intel hd 4000
The laptops' display uses the HD4000 iGPU.
You need to connect a display device to the HDMI output, to use the Nvidia GPU.
wanezhiling
6th December 2012, 15:08
You missed that. DXVAChecker always detects integrated GPU, ignore it.
Rename your media player, then the player could run in "NVIDIA GPU" mode after being set in NVIDIA control panel.
And then:
DXVA Checker (http://bluesky23.yu-nagi.com/en/DXVAChecker.html) --> Trace Log tab
Option: only check DXVA2_DecodeDeviceCreated
Click Start, run media player and play video, Click Refresh.
You will see if HW decoding is working.
itsonlyjustincase
6th December 2012, 15:59
You missed that. DXVAChecker always detects integrated GPU, ignore it.
Rename your media player, then the player could run in "NVIDIA GPU" mode after being set in NVIDIA control panel.
And then:
You mean ignoring what ? (sorry i'm french). My program serato and seratovideo are already set in the nvidia control panel to use nvidia card and do use it. The problem is the dxva checker program
wanezhiling
6th December 2012, 16:18
You could play a VC-1 video (Use LAV DXVA2 native) to figure out if your NVIDIA 620m is working.
For example: I used PotPlayer with LAV DXVA2 native.
http://i.imgur.com/c0mlm.png
It indicates that my PotPlayer is running under NVIDIA GPU because of ModeVC1_VLD2010.
If iGPU is active, you just couldn't see such information in this trace log tab.:)
itsonlyjustincase
6th December 2012, 16:59
You could play a VC-1 video (Use LAV DXVA2 native) to figure out if your NVIDIA 620m is working.
For example: I used PotPlayer with LAV DXVA2 native.
http://i.imgur.com/c0mlm.png
It indicates that my PotPlayer is running under NVIDIA GPU because of ModeVC1_VLD2010.
If iGPU is active, you just couldn't see such information in this trace log tab.:)
Lool thank you very much for the time you've taken to show me an example. I have understood how it work. My problem is that if you go in the first tab u'll see you nvidia card detected.In my case it's the iGPU which is detected
wanezhiling
6th December 2012, 17:07
My problem is that if you go in the first tab u'll see you nvidia card detected.In my case it's the iGPU which is detected
http://i.imgur.com/TVISk.jpg
Intel HD3000? No, its my NVIDIA GT520M.;)
http://i.imgur.com/n8kdy.jpg
This is the real Intel HD3000.:)
itsonlyjustincase
6th December 2012, 18:25
http://i.imgur.com/TVISk.jpg
Intel HD3000? No, its my NVIDIA GT520M.;)
http://i.imgur.com/n8kdy.jpg
This is the real Intel HD3000.:)
Ok i get it. So after testing it means my serato soft isn't using DXVA altough it is set in lav decoder options :s
itsonlyjustincase
6th December 2012, 18:27
I find it weird as perhaps your hd 3000 can play vc1 and supports dxva2
itsonlyjustincase
6th December 2012, 18:28
ANd looking at the print screen it does actually ! No man it isn't your geforce which is in use i promise
CommonMortal
6th December 2012, 19:53
Hi, i am new to LAV filters (have been using FFDshow until now).
I was wondering if someone could help me a bit with configuration.
1) My VGA is ATI HD 6570. Is it OK to choose "DVXA native" as hardware acceleration? Seems to work, i just don't know if "copy-back" is better.
2) I encode my Blue Rays for convenience reasons to x264 with Dolby ProLogic II AC3 stereo audio. My audio card also supports Dolby Headphone, is it's good combination. What settings should i use in Lav audio filter?
In particular.
What do i put in "Convert Output to Standard Channel layouts?"
Tick enable mixing to stereo or not?
Set "Matrix encoding" to Dolby Prologic II?
Should i do something with "Don't mix stereo sources?"
Something else?
Thank you in advance.
DragonQ
6th December 2012, 22:12
Grrrrrrrr, I can't get smooth video playback on my brand new laptop with any combination of software decoding, DXVA2, EVR, MadVR, Intel HD 4000 or nVidia NVS 5200m. Both CPU and GPU usage are nowhere near maxed out (<30%) yet I get frame drops all over the place.
Why can't anything ever be simple? :(
EDIT: Bloody Power Options...:rolleyes:
6233638
6th December 2012, 22:34
Grrrrrrrr, I can't get smooth video playback on my brand new laptop with any combination of software decoding, DXVA2, EVR, MadVR, Intel HD 4000 or nVidia NVS 5200m. Both CPU and GPU usage are nowhere near maxed out (<30%) yet I get frame drops all over the place.
Why can't anything ever be simple? :(
EDIT: Bloody Power Options...:rolleyes:The one "advantage" to using CUVID for decoding, is that it forces the GPU into its maximum power state.
This might be helpful if you don't want to mess with your system's general power saving options, though I'm surprised that it's not happening as required. (on my system if CPU/GPU load goes past a certain threshold, it changes power state)
DragonQ
6th December 2012, 22:45
I'm using the HD 4000 for now - I usually change power options anyway. When using full screen, I can have my preferred settings (DXVA2 Native & Bicubic 75 + AR chroma & Jinc3 + AR luma), but I have to disable chroma anti-ringing when not running full-screen. It may be that I can leave the anti-ringing enabled with the NVS 5200M but I kinda doubt it - we'll see once the freezing is fixed! ;)
LoopinFool
7th December 2012, 00:41
It would be great if LAV Video Splitter would support RTMP URLs with additional arguments (spaces) in them.
ffmpeg is able to read from RTMP streams like USTREAM delivers. Here's an example, which is the TWiT Live stream:
rtmp://ustreamlivefs.fplive.net/ustream3live-live/ playpath=stream_live_1_1_1524 swfUrl=http://static-cdn1.ustream.tv/swf/live/viewer.rsl:96.swf swfVfy=1 live=1
I don't know if this requires parsing the URL and passing the arguments through an API to the library or what. I just know it works as-is through ffmpeg via the command-line.
Simpler RTSP URLs that go directly to an Axis camera work pretty well. I am seeing some artifacts that don't appear in VLC connected to the same camera. Perhaps they are buffer underruns or missed UDP packets or something.
- LoopinFool
wanezhiling
7th December 2012, 02:23
I find it weird as perhaps your hd 3000 can play vc1 and supports dxva2
Why I ask you to test VC-1 with LAV DXVA2 native mode, because Intels VC-1 is special, only ArcSoft and CyberLinks DXVA decoders support ModeVC1_VLD_ClearVideo, LAV DXVA2 native does not support, LAV will just fall back to sw mode when playing a VC-1 file.
If you see ModeVC1_VLD or ModeVC1_VLD2010 in trace log tab when playing a VC-1 file, it indicates that your media player is running under NVIDIA GPU.
If you dont see such ModeVC1_VLD info in trace log tab when playing a VC-1 file, it indicates that your media player is running under Intel GPU.
I dont want say again...
itsonlyjustincase
7th December 2012, 03:25
Why I ask you to test VC-1 with LAV DXVA2 native mode, because Intels VC-1 is special, only ArcSoft and CyberLinks DXVA decoders support ModeVC1_VLD_ClearVideo, LAV DXVA2 native does not support, LAV will just fall back to sw mode when playing a VC-1 file.
If you see ModeVC1_VLD or ModeVC1_VLD2010 in trace log tab when playing a VC-1 file, it indicates that your media player is running under NVIDIA GPU.
If you dont see such ModeVC1_VLD info in trace log tab when playing a VC-1 file, it indicates that your media player is running under Intel GPU.
I dont want say again...
Anyway my player doesn't support vc1 :(. Thanks for your help
wanezhiling
7th December 2012, 03:56
I really dont know how to explain more detailed...:o
You just cant catch anything..
Your player doesn't support vc1, but LAV does!! LAV support VC1 DXVA on NVIDIA and AMD card!!
Why I ask you using dxva checker because you said <inactive> in lav video's properties page, right?
You just make sure LAV is running with your media player together, then using dxva checker can figure out if LAVs HW decoding is working.
It does not matter dxva checker runs in NVIDIA or iGPU, dxva checker(trace log tab) is just a tool to ensure if HW decoding is working.
itsonlyjustincase
7th December 2012, 10:36
I really dont know how to explain more detailed...:o
You just cant catch anything..
Your player doesn't support vc1, but LAV does!! LAV support VC1 DXVA on NVIDIA and AMD card!!
Why I ask you using dxva checker because you said <inactive> in lav video's properties page, right?
You just make sure LAV is running with your media player together, then using dxva checker can figure out if LAVs HW decoding is working.
It does not matter dxva checker runs in NVIDIA or iGPU, dxva checker(trace log tab) is just a tool to ensure if HW decoding is working.
I really appreciate your help thank you. The program is a bit shit it's not able to read .mkv files for example and this even if using haali+ffdshow. The best would be if you have time to test it by yourself. You'll be able to see how shitty it is :s. I had put the download links. It support H264 but not vc1. I don't know how they coded it but i can assure i'm not saying bullshit. Thanks to GPU-Z i could compare with and without DXVA or CUVID and in fact with we can see how the GPU is stressed (70% vs 5% without) and the CPU released. So i guess it might just be a displaying bug.
bjd
7th December 2012, 15:50
They probably do, if they do the conversion. I'm just wondering whether they might pass the float audio to the audio hardware driver and then maybe it's up to the audio hardware driver to do the float -> int conversion. I've really no idea, though, just shooting in the wild here...
Yep, once audio is passed from renderer to soundcard you are at the mercy of the design of the hardware/driver and if your experience with video card drivers is anything to go by! :eek:
For the moment I would rather put my trust in ReClock, pass it whatever Lav sends using WASAPI/Exclusive and let it resample the 32fp to 24 in my case before sending audio to the soundcard. I always have ReClock locked to the soundcard so it works in bit exact mode wherever possible.
Since the introduction of WASAPI audio in Vista, the mixer always resamples audio to 32fp regardless but we don't know how well it does it and then it outputs what you specify in the sound card shared mode properties.
AFAIK always best to avoid the mixer wherever possible and especially if you don't really need it.
6233638
7th December 2012, 17:53
It was my understanding that there are actually two different audio resamplers in Windows 7, and the "legacy" one had a lot of problems. (aliasing etc.)
This hotfix (http://support.microsoft.com/kb/2653312) updates the resampler and it should give high quality results. I believe the Windows 8 resampler is further improved from this. Anything older than this, and you want to avoid using the system mixer for audio resampling.
I don't know how Reclock compares. I do know that you have the option of switching between the "new" resampler and going back to the old "CPU hungry" SRC-based resampler by swapping out the resampler.dll file.
I use the old resampler with WASAPI output, as I think that will bypass any nastiness the audio drivers may be doing? The formats my card accepts change depending on the driver installed, but WASAPI will only ever accept 24-bit padded to 32, no matter what driver is installed.
omarank
7th December 2012, 19:16
Hi 6233638, do you mean to say that the new resampler in ReClock doesn't bypass any nastiness by the audio drivers in WASAPI? Also, from where can I get this old resampler of ReClock, for testing purposes? I wanted to know that if I am using WASAPI exclusive mode in ReClock, do I need to care about that Windows hotfix for audio resampler?
6233638
7th December 2012, 20:34
Hi 6233638, do you mean to say that the new resampler in ReClock doesn't bypass any nastiness by the audio drivers in WASAPI? Also, from where can I get this old resampler of ReClock, for testing purposes? I wanted to know that if I am using WASAPI exclusive mode in ReClock, do I need to care about that Windows hotfix for audio resampler?WASAPI alone should bypass any potentially bad conversions going on inside the driver I think, because it does not allow higher sample rates than the card can natively accept.
With DirectSound output, three different drivers gave me the options of 24-bit, 24-bit padded, 32-bit int, and 32-bit float as the best options it would accept.
With WASAPI, the card will only accept 24-bit padded to 32-bit, regardless of the driver installed, it rejects 24-bit and 32-bit int/float.
So I have to assume that when using DirectSound with the newer drivers, it's performing a conversion from 32-bit int/float to 24-bit, and I don't know how good/bad that may be. I don't know if that's done using the Windows resampler, or some code in the driver itself though.
WASAPI just seems to bypass the potential for problems.
If you are using WASAPI output, Windows will not be doing any resampling, so you don't need to worry about that hotfix. I don't know if the hotfix even applies to the resampler that would be used if you are using DirectSound out either. (but it can't hurt to have it installed)
This is the resampler dll I used for Reclock: http://www.datafilehost.com/download-7089655d.html
I don't know if it was compiled with optimisations enabled though, so in addition to using a more CPU intensive resampler (SRC) it may require even more CPU as a result of that. (I don't know if anyone has a dll compiled with optimisations)
You will have to open up the Reclock preferences again and re-select "best sinc interpolator" when you change the dll.
I don't know how SRC (and it's an older build of SRC at this point) compares to the Windows DirectSound mixer, or the newer resampler that now ships with Reclock. It was my understanding that the newer resampler for reclock was focused on reducing CPU usage, rather than necessarily being focused on the best audio quality at all costs. It's been a few years at this point now (reclock development seems to have stopped) so I don't remember the specifics and I could be mistaken.
Perhaps someone else could clarify this. (and if someone has compiled a more optimised dll using the latest SRC code, I'd appreciate the link)
madshi
7th December 2012, 20:45
SRC etc are samplerate converters. They are not bitdepth converters. That are 2 totally different things. Converting samplerate well is very very difficult and complex. Converting bitdepth is dead easy in comparison. What we were talking about in this thread (dithering needed when doing bitdepth reduction etc) has nothing to do with samplerate conversion at all. I don't think LAV Filter ever does any samplerate conversion, so discussion about samplerate converters doesn't really belong into this thread.
Pomegranate
7th December 2012, 21:04
Madshi, if one starts with a lossy audio file and it is decoded to 32 bit fp, is there any audible difference between
a) the 32-bit fp representation and
b) taking the 32-bit fp and reducing the bit depth to 24 bit integer, with or without dithering.
I can't seem to get a straight answer on this :p
nevcairiel
7th December 2012, 21:04
For the record, if your audio driver is doing terrible things, WASAPI won't stop it from doing them. But in general, on Windows 7, all audio processing is done by DirectSound/Windows Audio, and not left to the driver anymore, which should give you at least a somewhat consistent image of what happens, independent of driver quirks.
Thats the biggest difference to XP, where the driver itself had to convert to a hardware format, and in Vista/7, this is done by the OS.
nevcairiel
7th December 2012, 21:07
Madshi, if one starts with a lossy audio file and it is decoded to 32 bit fp, is there any audible difference between
a) the 32-bit fp representation and
b) taking the 32-bit fp and reducing the bit depth to 24 bit integer, with or without dithering.
I can't seem to get a straight answer on this :p
Audible in 24-bit, probably not, unless you have audio in *very* low volumes (32fp can better represent very low volumes than integer can) - like volume constantly below 5%, otherwise any rounding issues vanish in the inaudible parts. Heck most DACs only do 19-20 bits.
Pomegranate
7th December 2012, 21:53
Audible in 24-bit, probably not, unless you have audio in *very* low volumes (32fp can better represent very low volumes than integer can) - like volume constantly below 5%, otherwise any rounding issues vanish in the inaudible parts. Heck most DACs only do 19-20 bits.
:thanks:
Thank you very much for the clarification, kind sir.
So, for the majority of lossy encoded material comercially available, I'm perfectly fine with 32-bit fp to 24 bit int done inside LAV audio, while using kernel streaming?
6233638
7th December 2012, 21:53
SRC etc are samplerate converters. They are not bitdepth converters. That are 2 totally different things. Converting samplerate well is very very difficult and complex. Converting bitdepth is dead easy in comparison. What we were talking about in this thread (dithering needed when doing bitdepth reduction etc) has nothing to do with samplerate conversion at all. I don't think LAV Filter ever does any samplerate conversion, so discussion about samplerate converters doesn't really belong into this thread.Well that was maybe a bad example. Changing drivers would also let my card accept up to 192kHz, when it only supports up to 48kHz over WASAPI.
It sounds like that conversion would have been handled by the Windows mixer rather than the drivers though, which doesn't seem to be a bad thing from the sound of it. I was more concerned that it was being done by the drivers, and who knows what could have been going on there.
For what it's worth, I've just done some testing in Windows 8, and neither DirectSound or the old/new Reclock resamplers have aliasing problems. (as long as you are using Sinc in Reclock) From doing more reading, it looks like only WaveOut from Reclock would have been affected by the aliasing problems that hotfix was for.
The new Reclock resampler did have audible problems when downsampling 96kHz audio to 48 though. Both DirectSound and the old Reclock resampler were fine. (stayed silent once the sweep got above my threshold of hearing)
nevcairiel
7th December 2012, 21:55
So, for the majority of lossy encoded material comercially available, I'm perfectly fine with 32-bit fp to 24 bit int done inside LAV audio, while using kernel streaming?
Should be just fine. The next major release will most likely also include optional dithering.
Pomegranate
7th December 2012, 22:06
^ Cherry on top of the cake, good sir!
omarank
8th December 2012, 07:51
This is the resampler dll I used for Reclock: http://www.datafilehost.com/download-7089655d.html
Thanks. I wish ReClock development hadn't stopped.
Brom
8th December 2012, 12:16
For the record, if your audio driver is doing terrible things, WASAPI won't stop it from doing them. But in general, on Windows 7, all audio processing is done by DirectSound/Windows Audio, and not left to the driver anymore, which should give you at least a somewhat consistent image of what happens, independent of driver quirks.
Thats the biggest difference to XP, where the driver itself had to convert to a hardware format, and in Vista/7, this is done by the OS.How can you test if your driver is doing terrible things?
Under Win7 (i guess it started with Vista?) can you bitexactly stream the LPCM from the decoder (configured like that (http://forum.doom9.org/showthread.php?p=1534720#post1534720)) or is there still some processing by DirectSound/Windows Audio?
Qaq
8th December 2012, 12:17
The next major release will most likely also include optional dithering.
That would be great. At least for perfectly matched sources (MezzoHD 1080i50 for example) I could set ReClock to "original speed".
6233638
8th December 2012, 13:56
That would be great. At least for perfectly matched sources (MezzoHD 1080i50 for example) I could set ReClock to "original speed".Video framerate is never going to be a perfect match to your refresh rate.
ReClock should always be left at "Auto (best)" (note the speed it reports below that is not accurate - it's a bug that was never fixed)
And you should never use the "slave reference clock to audio" option.
mark0077
8th December 2012, 14:57
I disagree with using reclock. In both windows 7 and 8 reclock has never been reliable at detecting my displays refresh rate. Especially now in windows 8 where it detects 60.000 hZ when it's actually 59.94 hZ. This completely defeats the purpose if you ask me. So I personally recommend staying away from any of its auto settings. I only use it for wasapi now and try to simply get my display as close to content as possible.
Qaq
8th December 2012, 15:14
Video framerate is never going to be a perfect match to your refresh rate.
Just tried MezzoHD 1080i50 on 50Hz display with ReClock "auto". ReClock changed (very rare) 48000Hz from 47999 to 48001. Isn't it perfectly matched?
mrchisholm
8th December 2012, 16:22
a some what odd question perhaps but it's been bugging me for a while .. i'm streaming a transponder from TSReader to MPC-HC using LAV filters (splitter/video/audio) and i don't know if it's the issue with MPC or LAV filters or anything else but i have the same problem using graphedit and lav filters.
Problem is that when you start streaming a file is created in temporary internet files called 127_0_0_1[1] or similar (yes i'm streaming to the same PC) and the file seem to grow as the video is fed but when it hits 4GB the streams grinds to a halt. no errors, just stops (or well it seems like it actually restarts playing from where u started the stream when the file reaches 4GB).
I've tried streaming from TSReader to VLC and it does not seem to have this issue. I tried using other splitters in MPC but none of them seem to open the stream so i can't troubleshoot more with MPC.
I guess id just like to know if it at all could be a cause with LAV filters or if i need to go to TSreader devs to solve this problem.
EDIT: tried streaming from dvbviewer and it has the same issue as TSReader so that does not seem to be the cause of the problem.
ElBarto81
8th December 2012, 20:19
Hi, I would like to report an issue when using the LAV splitter (version 0.54.1) to play an FLV file. Video stream is H264, audio stream is Nellymoser, both of which get decoded by FFDShow.
When playing the FLV file in Media Player Classic (or any other DirectShow player), I don't get any audio. It looks like the splitter doesn't even detect the audio stream. If I use another splitter (Flash Video Splitter), the audio stream does get detected, but then there's no working playback/seeking: I only see the first frame and position stays at 0:00. Video playback/seeking works perfectly with the LAV splitter.
I'm willing to PM a download link to the FLV file if necessary.
filler56789
8th December 2012, 21:10
Hi, I would like to report an issue when using the LAV splitter (version 0.54.1) to play an FLV file. Video stream is H264, audio stream is Nellymoser, both of which get decoded by FFDShow.
When playing the FLV file in Media Player Classic (or any other DirectShow player), I don't get any audio. It looks like the splitter doesn't even detect the audio stream. If I use another splitter (Flash Video Splitter), the audio stream does get detected, but then there's no working playback/seeking: I only see the first frame and position stays at 0:00. Video playback/seeking works perfectly with the LAV splitter.
Sounds like you've got an improperly-muxed file
(but I can be wrong).
nevcairiel
8th December 2012, 21:36
I'm willing to PM a download link to the FLV file if necessary.
That would be the only way to get the details i need. :)
Brom
9th December 2012, 14:15
Somwhere else someone reported:
DTS-MA 6.1:
Arcsoft 1.1.0.0 decodes as 0x13f
eac3to 3.24 overrides to 0x70f and encodes the FLAC with that
FLAC 6.1 with WAVEFORMATEXTENSIBLE_CHANNEL_MASK: 0X70F as metadata:
LAV Audio 0.54.1 decodes as 0x13f
madFlac 1.10 decodes as 0x70f
ffdshow rev4494 decodes as 0x70fWhy does LAV Audio remap 0x70f to 0x13f?
This old post by madshi seems to indicate that 0x13f is wrong:
http://forum.doom9.org/showthread.php?p=1187128#post1187128
This old post by madshi seems to indicate that 0x13f will result in problems:
http://forum.doom9.org/showpost.php?p=1153688&postcount=5339
nevcairiel
9th December 2012, 14:28
The 6.1 channel order is chosen on a simple thing: The channel order HDMI devices expect. With the channel order implied by 0x70f, HDMI receivers will assign channels to the wrong speakers, with 0x13f, it will work just fine. At least on my receiver, and i never got complaints otherwise.
So unless you have some real-world problems, skip the theoretical assumptions, and stick to what happens in real devices. ;)
PS:
If you disable "Convert Output to Standard Channel Layouts" in LAV Audio options, it should give you whatever channel order was stored in the file, without any remapping.
cyberbeing
9th December 2012, 19:59
Does LAV Splitter already support those new CueDuration and CueRelativePosition MKV elements for optimal subtitle display on seek, or is that something missing from FFMPEG which you'll need to code yourself?
nevcairiel
9th December 2012, 20:00
How the hell would it already support them if the only tool that can write them was just released an hour ago? :P
I usually prefer faster seeking over subtitle display myself, though.
cyberbeing
9th December 2012, 20:14
How the hell would it already support them if the only tool that can write them was just released an hour ago? :P
Wishful thinking. It seems like it was finalized over a month ago, so theoretically ffmpeg or someone could have supported it, without actual test files.
I usually prefer faster seeking over subtitle display myself, though.
So does that mean you prefer to seek multiple times until you find the block which contains the start of the subtitle line, or that you just don't care about seeing subtitles when you have them enabled. ;)
nevcairiel
9th December 2012, 22:02
So does that mean you prefer to seek multiple times until you find the block which contains the start of the subtitle line, or that you just don't care about seeing subtitles when you have them enabled. ;)
It'll sync audio and video to the seek time, not subtitles.
So yeah, if you seek in the middle of a sub, you won't get to see it, because i just don't know if there is a subtitle just one data block before, or maybe none at all, or 100mb before ... its impossible to know, now at least.
Patches welcome, doubtful i will spend much time on this anytime soon.
Not sure how hard that even would be to add, maybe even easy, do it in the high-level code above matroska seek logic, check if there is a Cue point with Time+Duration for a subtitle which falls into your frame, and then adjust the target seek time to that. Don't even have to toy with the low-level seeking. Maybe, just thinking out loud here.
If you wanted make working on this easier, you could prepare a sample file which helps to demonstrate the problem which is supposed to be fixed by this (preferably muxed by mkvmerge 5.9.0 so when i try implementing it, it actually helps :p)
If i don't have to dig around (or even make) for this stuff, it'll make it a lot easier.
PS:
Keep in mind that i do not use ffmpegs matroska demuxer.
cyberbeing
9th December 2012, 23:32
I sent you some simple samples muxed with mkvmerge 5.9.0.
Not sure how hard that even would be to add, maybe even easy, do it in the high-level code above matroska seek logic, check if there is a Cue point with Time+Duration for a subtitle which falls into your frame, and then adjust the target seek time to that.
It's probably a bit more complex than that, when you consider overlapping subtitle lines (CueDuration) residing in multiple MKV clusters scattered minutes to hours apart. In order for this to be in any way efficient, you'd want to seek and pull subtitles as directly as possible using CueRelativePosition, while not actually seeking the video or audio at all. Implmenting an intelligent background subtitle cache of some sort, may also be useful for cutting down on potential random access seeks.
Mercury_22
10th December 2012, 00:55
@ Nev
Strange thing happened after today's ffmpeg updates, most likely a false positive (my Avira it's going nuts ? :) ) but I thought to report this to you : when trying to build a new version of LAV my AV it's saying that "print_options.exe" from ffmpeg/doc/ it's a Trojan?! (https://www.virustotal.com/file/7a7dbd36120b6a4aa6afdb63b09ceb2315e14336d0cdaa700451c78e96529459/analysis/1355096405/)
leewalk
10th December 2012, 08:24
Win8 doesn't include DVD Navigator.
Will Lav support DVD navigation? Or are there any "recommended" alternatives?
It would be great to see Lav's (simple) blueray navigation extended to DVDs...
Thanks! Lee
nevcairiel
10th December 2012, 09:01
@ Nev
Strange thing happened after today's ffmpeg updates, most likely a false positive (my Avira it's going nuts ? :) ) but I thought to report this to you : when trying to build a new version of LAV my AV it's saying that "print_options.exe" from ffmpeg/doc/ it's a Trojan?! (https://www.virustotal.com/file/7a7dbd36120b6a4aa6afdb63b09ceb2315e14336d0cdaa700451c78e96529459/analysis/1355096405/)
That file is compiled during the build process, you can go read the sources yourself if you wish, its most certainly not a trojan. :p
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.