View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
Gleb Egorych
23rd April 2011, 05:47
I confirm the "weird" character issue.
I'm using ZoomPlayer and with v0.23 I get the same strange characters in the video stream name for MPEG2 in .ts container.
Same here. Win7 x64, ZoomPlayer.
nevcairiel
23rd April 2011, 08:39
I confirm the "weird" character issue.
I'm using ZoomPlayer and with v0.23 I get the same strange characters in the video stream name for MPEG2 in .ts container. For other formats or when using v0.22 everything is fine - I get "mpeg2video main".
I see it too, but the weird thing is, only in release builds. And only on mpeg-2 .. how is that for making sense. o.O
Edit:
I still dont know why it happend, but i fixed it..
nevcairiel
23rd April 2011, 09:12
Check out these examples (http://www.mediafire.com/?d5l9yas32fplup2). Half of the sample noise in LAV Audio and MpaDecFilter. After my patch, most samples (except 64-bit float) are played without any problems in LAV Audio, and MpaDecFilter plays back all tracks. :p
Ah, i see what the problem is. I'll fix it.
Edit:
Fixed. S16LE, S24LE, S32LE, FL32LE play fine without any decoder now, and FL64LE plays fine with LAV Audio and MpaDec. All the big-endian formats still need the decoder, of course.
v0lt
23rd April 2011, 11:48
Fixed. S16LE, S24LE, S32LE, FL32LE play fine without any decoder now, and FL64LE plays fine with LAV Audio and MpaDec. All the big-endian formats still need the decoder, of course.
Thanks, now plays without any problems. :)
VipZ
23rd April 2011, 12:38
Nev, I found that AAC in MKV doesn't work well currently, some crash at start, others stall during playback and then some work ok, all the files work fine with the MPC splitter. If I create a sample of the files, they don't show the issue, but if I remux the entire file, the issue is present.
The issue occurs with any AAC decoder.
nevcairiel
23rd April 2011, 12:41
Without a sample, i cannot help you. All MKVs with AAC i have play just fine.
Did you try flipping the audio stream parsing switch?
VipZ
23rd April 2011, 13:01
Without a sample, i cannot help you. All MKVs with AAC i have play just fine.
Did you try flipping the audio stream parsing switch?
Let me try test to see at what size I need to cut to to show the issue. Yep I tried that option, made no difference.
Edit: Here is a sample http://www.mediafire.com/?86vluoud1m2lo6d
nevcairiel
23rd April 2011, 13:29
Thanks, i'll have a look.
What exactly is the problem with that file? It seems to start and play just fine, not sure what i should be looking for.
I see one issue with that file, that is that the FPS is detected wrong, funny thing is, i saw that exact problem before with another One Piece sample. But that alone shouldn't matter for playback.
Oh, one problem i noticed though, when you're using EVR-CP and have "Frame Time Correction" set to ON, that wrong FPS will totally break playback - but only video, audio is fine :D
VipZ
23rd April 2011, 13:43
Thanks, i'll have a look.
What exactly is the problem with that file? It seems to start and play just fine, not sure what i should be looking for.
Many frames get dropped, also the FPS is shown as 0fps. Here is a screenshot showing some info http://www.mediafire.com/i/?3g5ewddcq6bxzlz
I have also tested with both ffdshow and MPC DXVA for video decoding, with no difference.
EDIT, I just tried to remux it with just video, and same issue, so this isn't an issue with AAC in this file, but the H264 stream.
nevcairiel
23rd April 2011, 13:52
I applied some fix to ignore very unsual container fps (it reports something like 359,64 fps) and use the calculated average fps instead, which seems to fix this. There is still however some weird thing going on when i activate VSYNC in EVR-CP - this is a 29.97fps movie, but the VSYNC mode seems to want to squish it into 25-26fps despite my screen being 59.94, which should be a perfect match - something weird is going on (but this problem also exists with MPC-HC splitter)
Or is this variable frame rate content which would explain switches between 29.97 and 25 fps? o.O
VipZ
23rd April 2011, 13:54
I applied some fix to ignore very unsual container fps (it reports something like 359,64 fps) and use the calculated average fps instead, which seems to fix this. There is still however some weird thing going on when i activate VSYNC in EVR-CP - this is a 29.97fps movie, but the VSYNC mode seems to want to squish it into 24 or 25fps .. something weird is going on.
I just looked through a bunch of the files with this issue, they all have this is common with MediaInfo
Frame rate mode : Variable
Ger
23rd April 2011, 13:55
Seems to be the same VFR/ffmpeg issue (Github #31):
http://forum.doom9.org/showthread.php?p=1484908#post1484908
nevcairiel
23rd April 2011, 13:56
Well the change i did will at least report some fps, which is 29.97 in this samples case, which makes it work better - i guess. With VFR, this value is really meaningless, but apparently the MPC-HC EVR Renderer doesn't like getting a fps of around 359. :P
According to some resources i found, i'm just supposed to set it to 0 for VFR - lets see if i can detect this.
VipZ
23rd April 2011, 14:02
Well the change i did will at least report some fps, which is 29.97 in this samples case, which makes it work better - i guess. With VFR, this value is really meaningless, but apparently the MPC-HC EVR Renderer doesn't like getting a fps of around 359. :P
According to some resources i found, i'm just supposed to set it to 0 for VFR - lets see if i can detect this.
hehe :) Yep, you right, switching to EVR and the issue is no longer present
Thanks.
Ger
23rd April 2011, 14:06
Or if you want to keep using EVR-CP until the fix is ready/compiled, just press v to disable vsync for the time being.
nevcairiel
23rd April 2011, 14:07
Doesn't look like i can easily detect variable fps, but the fix i made will at least make sure that the fps reported will be somewhat sane, and actually fixed the two problem files i had (yours and the one from Ticket #31 - both One Piece, heh)
Or if you want to keep using EVR-CP until the fix is ready/compiled, just press v to disable vsync for the time being.
VSYNC doesn't break, Frame Time Correction does (press C). VSYNC just looks weird in the graph, one second its running as a straight line (29.97 on 59.94 display), then it switches to the jagged line (24p on 59.94Hz)
I thought it was to be blamed before i realized its VFR content.
With LAV Splitter, my goal is to never need Frame Time Correction again, so please turn it off, and if some movie doesn't play properly with it off (most likely only with one specific decoder), please report that, so i can fix the timestamps, thanks =)
Ger
23rd April 2011, 14:17
Huh? With LAV Splitter 0.23, internal MPC-HC decoder and EVR-CP, FTC on/off makes little difference for me with both samples. Disabling vsync OTOH seems to do the trick. I had FTC off in the first place.
With LAV Splitter, my goal is to never need Frame Time Correction again, so please turn it off, and if some movie doesn't play properly with it off (most likely only with one specific decoder), please report that, so i can fix the timestamps, thanks =)
I think I know one sample+decoder combination where FTC is needed. I'll verify later. Going to watch EPL footie now. :)
nevcairiel
23rd April 2011, 14:42
Maybe both need to be off for perfect playback, i didn't really pay attention that closely when testing. But the VSYNC thing i cannot fix anyway, thats all the renderers doing.
VipZ
23rd April 2011, 15:41
For me, disabling VSync does the trick for now.
Could someone upload the latest build if possible ? :)
nevcairiel
23rd April 2011, 16:16
<<buggy build, see a few posts below for a new one>>
I don't usually do these quick and untested builds, but this one is special - its extra untested!
In fact, i just upgraded ffmpeg - and they just recently removed all deprecated functions, and cleaned up the libraries alot. I hope i switched everything over to the proper APIs, and i hope everything still functions - but you never know after such a big ffmpeg update - so more testing from you guys. :p
Oh btw, the names of the ffmpeg libraries changed (all version numbers +1). Having both in one folder doesn't hurt, but just a heads up that you might want to clean them.
SamuriHL
23rd April 2011, 16:18
LOL! Great. :) And I was gong to watch the Batman collection today. I guess that'll be good to test it out. :)
SamuriHL
23rd April 2011, 16:31
Nev, it doesn't look like ffmpeg is committed. Can you please check as my build just failed.
nevcairiel
23rd April 2011, 16:35
Latest commit in my ffmpeg repository (http://git.1f0.de/gitweb?p=ffmpeg.git;a=commit;h=870b9910950d636a880c0a81865acf409b59833b): 870b9910950d636a880c0a81865acf409b59833b
Commit referenced in latest LAV Splitter commit: (https://github.com/Nevcairiel/LAVFSplitter/commit/fd6ad074519c7aba054ccda2b466b6496a197c05#diff-10) 870b9910950d636a880c0a81865acf409b59833b
Looks all good!
SamuriHL
23rd April 2011, 16:38
Freaky. I did another update and was able to pull the code. GIT just hates me. :D
nevcairiel
23rd April 2011, 18:39
The build earlier had a rather bad bug, it emptied the files it opened (only when using "LAV Splitter Source" to open files directly, when going through the "File Source (Async)" there was no way for this to happen, Blu-rays also didn't have that problem).
Silly ffmpeg changing the meaning of the file opening flags.
I have since fixed the bug, anyone doing custom builds, i recommend re-building them immediately. Here is a new build with that fixed:
http://files.1f0.de/lavf/LAVFilters-0.23-11-g5d50f7c.zip
SamuriHL
23rd April 2011, 18:53
YIKES! Good thing I'm only testing on blu-rays so far!!! :)
nevcairiel
23rd April 2011, 19:13
Yeah its the worst thing they can do, change the meaning of existing flags, so i have to keep up with their internal changes - you're not supposed to replace the internal file protocol, but hey, it doesn't support unicode path names on Windows, so i had to do something. :P
SamuriHL
23rd April 2011, 19:17
Nice. :) We do like the unicode path names in Windows. Especially for non-english windows users. :)
Gleb Egorych
23rd April 2011, 20:10
Silly ffmpeg changing the meaning of the file opening flags.
Funny bug, luckily I had a backup :)
VipZ
23rd April 2011, 20:11
Phew, just as well I removed the manual registry entries :)
Ger
23rd April 2011, 21:23
http://files.1f0.de/lavf/LAVFilters-0.23-11-g5d50f7c.zip
No new ffmpeg issues found so far. Never tried the file eating build. :)
A very quick test with the two VFR samples showed no frame drops with MPC-HC decoder or CoreAVC (vsync on, FTC off). With the 0.23 release version it barely played at all with MPC-HC decoder and vsync on in EVR-CP. I was going to suggest closing issue 31, but I see you've already done it.
The MS DTV-DVD decoder still has black flashes during the opening song of the first/Gitgub VFR sample on my system, but that is also the case with the MPC-HC splitter, so it must be a MS decoder issue. The other decoders are fine, so I'd say case closed.
With LAV Splitter, my goal is to never need Frame Time Correction again, so please turn it off, and if some movie doesn't play properly with it off (most likely only with one specific decoder), please report that, so i can fix the timestamps, thanks =)
Here's the sample (http://www.multiupload.com/39QG155RJW) I referred to earlier. TS/mpeg2 recorded from DVB-S. Live event from the US transcoded to PAL by the broadcaster. Was originally 10 GB. I used Total Commander's binary splitter to cut off everything after the first 100 MB. The issue remains the same after the cut.
ffdshow + EVR-CP: No FTC needed (symmetrical graphs and 50 fps achieved with either Auto or Force bob flags for hw deint).
MPC-HC libmpeg2 decoder + EVR-CP: FTC needed. If "set interlaced flags" (hw deint) is checked it plays at ~43 fps and with that option off (using software/auto deinterlacing) it plays at ~18 fps. EVR-CP graph is "ugly" with FTC off in both cases. With FTC on it plays fine at 50/25 fps with hw/software deint respectively, and the graph also looks OK.
Someone with a Nvidia GPU also told me FTC is needed for symmetrical EVR-CP graphs with LAV CUVID and this sample, but I don't know for sure.
Next issue:
I haven't seen a wrong MPEG-TS duration with LAV Splitter for a long time now, but MPEG-PS still seems to have some duration issues. This vob (http://www.le-homecinema.com/trailers-dvd/disneyhomeent.vob) should be around 8 seconds, but is shown as over 26 hours.
nevcairiel
23rd April 2011, 21:30
You can try disabling the stream parsing option in the lav splitter config, that should fix it for libmpeg2 - and hopefully not break for other decoders.
It did fix it with LAV CUVID for me, and not break for anything else - i'm going to force-disable the parsing for mpeg2, i guess. (I actually had some .VOB just an hour ago that i had this with, too)
Ger
23rd April 2011, 22:35
Yeah, the ts/mpeg2 sample no longer needs FTC when video stream parsing is off. Quickly tested several other mpeg2/ts streams with ffdshow and MPC-HC decoders and saw no downside to disabling it for mpeg2.
With h264 it was the opposite. Parsing needed to be on to avoid FTC with CoreAVC DXVA.
It's funny to watch some mpeg2 streams (not that sample but some other ones) with the MPC-HC decoder and the stats enabled form the start. The reported frame rate starts high (for a/v sync reasons I guess), then quickly drops to 43 fps, then it realizes that it should be 50 and corrects itself in a couple of seconds, and is stable at 50 after that. Doesn't happen with ffdshow/force bob (drops straight down to 50). Just an observation, nothing wrong with it.
nevcairiel
23rd April 2011, 23:21
I'll disable it for mpeg2 everywhere then, thanks for testing.
SamuriHL
24th April 2011, 02:06
So, Nev. I created a custom "24" resolution with the new driver and set the refresh rate to 23.976 manually. madVR shows me 23.974xx when playing and not a single dropped frame. Audio sync is damn near flawless now. I'm EXTREMELY pleased with the new setup! When I upscaled a 720p59 file up to 1080p59, it was so exact that I'd lose 1 frame every 3 hours according to madVR. LOL! :) That's obviously using the latest (since I built earlier, anyway) LAVF Splitter and your latest 0.4 LAV CUVID with the new nVidia drivers. I really couldn't be more happy with the setup right now. There's only 2 features "missing" that'd make it so I could drop commercial players altogether. One is less urgent...the bitstreaming in the splitter. The other is what's keeping me from completely dropping TMT5....title selection. When watching my wife's Glee discs it's difficult to know which MPLS file is the next episode...you'd THINK it'd be in order. BAHAHA, no. :) This is really awesome!!!!
nevcairiel
24th April 2011, 06:41
Can only hope that they are at least in sequential order on the discs .. i mean, even when you know which titles are available, how are you otherwise going to know which episode is which - all i can tell you is which .mpls file that is, and the duration.
Gleb Egorych
24th April 2011, 07:40
nevcairiel, could you please replace mp1 and mp2 decoders with mp1float and mp2float like you did for mp3?
BTW tested the latest version of the filters, no decoding bugs found (except known). MPEG2-TS video stream name fixed, thanks. There is a small interface bug: if you call LAV Audio Decoder settings window and after that change audio stream or, for example, DVB channel then status tab is not updated correspondingly (codec, number of channels, channel bars, etc).
nevcairiel
24th April 2011, 07:47
The status page is once populated on opening, there is no (easy) way to let it know that the settings changed - that'll have to remain this way.
Carpo
24th April 2011, 10:30
One is less urgent...the bitstreaming in the splitter.
I agree to the bit-streaming, guess we just have to wait :)
CruNcher
24th April 2011, 11:01
Still broken http://forum.doom9.org/showpost.php?p=1494637&postcount=1739
nevcairiel
24th April 2011, 11:30
Still broken http://forum.doom9.org/showpost.php?p=1494637&postcount=1739
Yeah, broken files don't have a tendency to suddenly repair themself.
Next issue:
I haven't seen a wrong MPEG-TS duration with LAV Splitter for a long time now, but MPEG-PS still seems to have some duration issues. This vob (http://www.le-homecinema.com/trailers-dvd/disneyhomeent.vob) should be around 8 seconds, but is shown as over 26 hours.
The video stream of that file does for some reason have a duration of 26 hours, must be something weird about the timestamps in the file - doesn't look like i can do something about it.
SamuriHL
24th April 2011, 13:32
Can only hope that they are at least in sequential order on the discs .. i mean, even when you know which titles are available, how are you otherwise going to know which episode is which - all i can tell you is which .mpls file that is, and the duration.
They aren't. Which sucks.
SamuriHL
24th April 2011, 13:52
Actually, Nev, I have one request when you implement the title set selection code. Can you make it so we can configure a minimum duration to display? For instance, if there's, let's say, 20 titlesets on a disc, maybe I don't want to see any that are shorter than 30 minutes show up in the titleset menu. But that duration would be AWESOME if it were configurable in the properties. Thanks!!
nevcairiel
24th April 2011, 13:59
I need to filter by duration anyway, having that configurable will be easy.
SamuriHL
24th April 2011, 14:20
Sweet. That will make things so much nicer when dealing with BD's. We'll be able to switch between theatrical and extended versions with ease. :) That will be a really nice addition.
mr.duck
24th April 2011, 14:49
There are a couple of things the MKV splitter built into MPC-HC does that would be nice if LAVsplitter could match.
1) LAVsplitter does not show the title tag at all (would you like a sample?)
2) MPC-HC MKV splitter does not lock the file it opens. File can be moved or renamed and it keeps playing. Is quite useful for my setup with accessing files over the network by multiple people.
nevcairiel
24th April 2011, 14:52
How files are opened is out of my hands - either the "File Source (Async)" opens them, or ffmpeg itself does it, nothing i can influence. Besides, i think its silly to expect a video to continue playing when the source file suddenly changes its name.
Plutotype
24th April 2011, 18:54
Hi Nevcairel,
Is it only my setup, that LAVsplitter reports 48k stream when 96k audio stream is present in the m2ts file?
http://www.megaupload.com/?d=7YEBF5XT
Reclock is reporting 96000 Hz, 8 channel(s), 24 bits PCM, but LAVsplitter only 48000Hz. Is this by design, or can we see 96000Hz already at the splitter?
Thanks
Pluto
nevcairiel
24th April 2011, 18:56
Its currently not possible to detect the exact contents of a DTS-HD stream. It'll usually never show more then 48kHz and 6 channels.
Plutotype
24th April 2011, 19:06
Its currently not possible to detect the exact contents of a DTS-HD stream. It'll usually never show more then 48kHz and 6 channels.
Thanks for the answer,
At least I know for now, that everything is ok with the filters setup.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.