View Full Version : LAV Filters - DirectShow Media Splitter and Decoders
yesgrey
15th April 2011, 18:09
It does actually read the duration of 60 frames, not the timestamps, so it has 60 data points to compare.
OK. So my original logic is valid.
The problem with the code is that its not mine, but ffmpegs. Now i have no problem applying a custom patch to my builds, but the way the code works, i cannot simply do as you suggests
Why not proposing a change to ffmpeg? The way I suggest seems much simpler and more error proof...
I can try to outline how it works right now (as good as i understand it), in pseudo code
Can you point me directly to the code? File and function names?
It seems to be much more complicated than needed...
If we can get it close enough to the real value, it'll be a perfect match, we don't have to get it to match 100% - it'll do that afterwards by itself.
The only problem I can see is what is considered close enough?
SamuriHL
15th April 2011, 18:09
That's what I mean. No subs show up in the filter list when playing an EVO. This blows cause I still have a BUNCH of HD DVD's that I don't necessarily want to repurchase. I was hoping converting them to HD DVD would allow me to be done with it. But I do need subs on a couple of them. And since it's a dead format, I'm guessing none of the subtitle developers want to even bother with this. Converting them to actual vobsub has little appeal. I just want to rip them to MKV and call it good. Guess that's not going to happen.
nevcairiel
15th April 2011, 18:15
Why not proposing a change to ffmpeg? The way I suggest seems much simpler and more error proof...
I actually had one file that had its first frame having a double duration, which totally threw the algorithm off, and caused it to end up with a framerate of 23.8-something
If there is some overall good solution, proposing it to ffmpeg is of course the ultimate goal - however they are usually careful with completly rewriting such parts.
Can you point me directly to the code? File and function names?
It seems to be much more complicated than needed...
libavformat/utils.c, av_find_stream_info
The relevant code starts at around line 2300 and is spread all over the place until line 2466 or so.
tb_unreliable() is true for H264, which causes the whole code to activate.
Line numbers from here;
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=1919f61d6aec0dd9758292b51b6fd448e51d1477;hb=HEAD
It does seem overly complicated, also buggy in some places, but i also have much more to do and cannot fix every bug in ffmpeg. I just trust the container provided values now (turned the unreliable check off)
nevcairiel
15th April 2011, 18:16
No subs show up in the filter list when playing an EVO..
What i mean is, they show up in the list, but i don't get any subs on screen, which means the renderer just doesn't like them.
SamuriHL
15th April 2011, 18:20
What i mean is, they show up in the list, but i don't get any subs on screen, which means the renderer just doesn't like them.
For the one disc I'm trying to do right now (Serenity) if I play the EVO file no subs show up in the list. The sub is shown in the list for my MKV, but, no subs ever show up. In either case, it's irrelevant if the sub renderer won't play them. :(
yesgrey
15th April 2011, 18:25
I guess my reply was a bit late...
I looked into it some, and it looks like it won't be easy to do it perfectly. I even rewrote it completely one time, which then caused it to work on some files, but broke on others that had screwed up timestamps in the first 2 frames.
You can always use an offset and ignore some of the first frames, and start counting only after that. Unless all timestamps are screwed it should work, but I see that it might be a problem too, because if any of the timestamps are bad the logic fails, since it assumes that all the timestamps are valid...
I'll just disable the whole guessing logic for H264 and go with the container or header specified frame rate.
That's not a bad solution.
Technically, this would even be correct, since its the frame rate, not the field rate. :P
I don't agree with this. Technically that would be wrong, because the frame rate of a 59.94 interlaced source is 59.94 fps, and not 29.97. The field/frame distinction is not only related with lines positioning, but also with time. If what you call as two consecutive fields were captured at different time positions, then I won't call them fields but frames. Of course it would be frames with half the resolution of a progressive frame, but they will be frames. For me, it only makes sense talking about fields when they were captured at the same time position.
I'll also write to the ffmpeg list and see if they have some smart idea. I found some sample that can easily be used to demo the behaviour.
If you need the matlab code I wrote let me know.
yesgrey
15th April 2011, 18:32
It does seem overly complicated, also buggy in some places, but i also have much more to do and cannot fix every bug in ffmpeg.
Agreed, but if it would be something simple it won't hurt too much... you can propose and then let them decide for themselves. ;)
But I do need subs on a couple of them.
Have you tried looking for the subs in forums that contain subs for a lot of movies? You can then remux your HDDVDs with those files.
tetsuo55
15th April 2011, 18:32
Samurai/Nev: Is the subtitle renderer connecting at all?
I remember something about the actual subtitle overlay surface being limited to a very low bitdepth, it could be that the surface isnt accepting the 8bit images.
Does it work with haali or gabest filters? Same question for the subtitles muxed into MKV?
If it doesn't work with the other solutions either fixing it in the subtitle renderer might be fairly easy, its just images after all. And if its a bitdepth problem Janwillem might be able to fix that.
SamuriHL
15th April 2011, 18:36
Just another FYI, Nev. VC-1 from an HD DVD in an MKV is a real pain in the ass. The pulldown flags don't get removed in MakeMKV, so, it causes the decoder problems. In my case I'm using Cyberlink HAM mode and it's able to handle it. ffdshow with either wmr9 or libavcodec gets out of sync almost immediately cause it's not detecting the proper FPS. (It thinks it's 29.whatever meaning it believes it's 60fps whereas the content is really 23.976). The Cyberlink decoder seems to handle that quite nicely. ffdshow not so much. I was only testing ffdshow to see if its sub renderer could handle the HD DVD subs. It can't. No surprise, just doing my due diligence. In any case I really wish there was an easy, quick way to take the stupid MKV's and remove the pulldown so they show up as 23.976 like they're supposed to. I haven't tried LAVF CUVID to see how it handles this situation yet. ;)
SamuriHL
15th April 2011, 18:37
Have you tried looking for the subs in forums that contain subs for a lot of movies? You can then remux your HDDVDs with those files.
If I wanted to remux manually, I could convert the subs myself. I'm trying to avoid that. I will if I have to, but, what a pain.
SamuriHL
15th April 2011, 18:40
Samurai/Nev: Is the subtitle renderer connecting at all?
I remember something about the actual subtitle overlay surface being limited to a very low bitdepth, it could be that the surface isnt accepting the 8bit images.
Does it work with haali or gabest filters? Same question for the subtitles muxed into MKV?
If it doesn't work with the other solutions either fixing it in the subtitle renderer might be fairly easy, its just images after all. And if its a bitdepth problem Janwillem might be able to fix that.
Gabest filters don't work with it, either. I just now tried that. I don't know how to tell if it's connecting to the sub renderer? Sorry, I'm still learning about a lot of this stuff. If you can tell me how to check that I'll take a look. Thanks!
yesgrey
15th April 2011, 18:42
You can always use an offset and ignore some of the first frames, and start counting only after that. Unless all timestamps are screwed it should work, but I see that it might be a problem too, because if any of the timestamps are bad the logic fails, since it assumes that all the timestamps are valid...
From a quick look into the code ffmpeg seems to be using the offset idea (line 2394), so it seems they would need to use only 24+offset and 60+offset readings. Currently it uses an offset of 4.
madshi
15th April 2011, 18:50
I actually had one file that had its first frame having a double duration, which totally threw the algorithm off, and caused it to end up with a framerate of 23.8-something
IMHO the best solution is to simply trust the container. Of course there are broken files out there, but that's not your fault, so it's also not your problem. If all else fails, you could offer an option somewhere to alternatively overwrite the container framerate with a "guessed" framerate by looking at the timestamps. But IMHO the default should be to trust the container information. If users complain, just tell them: "Your file is broken". Just my 2 cents, of course...
P.S: There are MKV files without any framerate information, though. For those I'd use the current timestamp guessing.
I don't agree with this. Technically that would be wrong, because the frame rate of a 59.94 interlaced source is 59.94 fps, and not 29.97. The field/frame distinction is not only related with lines positioning, but also with time. If what you call as two consecutive fields were captured at different time positions, then I won't call them fields but frames. Of course it would be frames with half the resolution of a progressive frame, but they will be frames. For me, it only makes sense talking about fields when they were captured at the same time position.
IIRC, the h264 video specification always uses a "field rate". For interlaced content that's 59.940. For progressive Blu-Rays it's 47.952. I understand your wish to handle native video content differently to native movie content. But that's not how h264 works. Nor MPEG2 nor VC-1. Nor TS or m2ts transport streams.
There's also a problem with your approach: You want to use a framerate of 59.940 for video content and of 29.970 (or 23.976) for movie content. But what about mixed content? What about movies which have video content drawn over them? Your desired framerate definition is the "framerate after ideal deinterlacing". But the splitter doesn't know what kind of deinterlacing will be performed. E.g. if you use LAV Splitter -> Typical Decoder -> madVR, you'll likely get "weave" deinterlacing, which will actually produce 29.970p. So having LAV Splitter report a framerate of 59.940p would even be wrong in this case. The only correct output for LAV Splitter for interlaced ATSC/NTSC content is IMHO 29.970p.
nevcairiel
15th April 2011, 19:00
Just another FYI, Nev. VC-1 from an HD DVD in an MKV is a real pain in the ass. The pulldown flags don't get removed in MakeMKV, so, it causes the decoder problems. In my case I'm using Cyberlink HAM mode and it's able to handle it. ffdshow with either wmr9 or libavcodec gets out of sync almost immediately cause it's not detecting the proper FPS. (It thinks it's 29.whatever meaning it believes it's 60fps whereas the content is really 23.976). The Cyberlink decoder seems to handle that quite nicely. ffdshow not so much. I was only testing ffdshow to see if its sub renderer could handle the HD DVD subs. It can't. No surprise, just doing my due diligence. In any case I really wish there was an easy, quick way to take the stupid MKV's and remove the pulldown so they show up as 23.976 like they're supposed to. I haven't tried LAVF CUVID to see how it handles this situation yet. ;)
Thats the same when playing the .evo file. ffdshow doesn't understand those flags, but Cyberlink does, so does LAV CUVID.
From a quick look into the code ffmpeg seems to be using the offset idea (line 2394), so it seems they would need to use only 24+offset and 60+offset readings. Currently it uses an offset of 4.
I saw that part, but its not directly used for the framerate guessing. I'm not 100% sure what that value is used for in the end..
Trusting the container is what i'll do for now anyway.
yesgrey
15th April 2011, 19:12
There's also a problem with your approach: You want to use a framerate of 59.940 for video content and of 29.970 (or 23.976) for movie content. But what about mixed content? What about movies which have video content drawn over them?
OK. Now I understand and have to agree why the field concept was extended. It's the difference between the theoretical perfect world and the real world, with all the possibilities in it, like mixing video with film in the same sequences.
The only correct output for LAV Splitter for interlaced ATSC/NTSC content is IMHO 29.970p.
Following the previous logic I have to agree. However, if the decoder then performs the ideal deinterlacing it should set the frame rate accordingly as 59.940, and not simply passing the splitter frame rate to the renderer.
Trusting the container is what i'll do for now anyway.
I'm fine with that too.
SamuriHL
15th April 2011, 19:13
Thats the same when playing the .evo file. ffdshow doesn't understand those flags, but Cyberlink does, so does LAV CUVID.
Ok, well, that's good then. That means in my case all 3 machines will play nice with that file. :) Thanks!
madshi
15th April 2011, 19:51
Following the previous logic I have to agree. However, if the decoder then performs the ideal deinterlacing it should set the frame rate accordingly as 59.940, and not simply passing the splitter frame rate to the renderer.
Agreed.
VipZ
15th April 2011, 20:16
Nev, is there any reason for the latest commits that disable FLAC?
I don't seem to have any issue with my FLAC files and LAV Splitter.
Would I still be able to use the extensions registry to use LAV Splitter for FLAC?
If any one wouldn't mind, could you upload the latest build.
Thanks
nevcairiel
15th April 2011, 20:53
Its just off by default (in the audio decoder), not disabled. The decoder throws out alot of warnings/errors and some people did report A/V sync issues that i could not fix yet, so i decided to change the default.
VipZ
15th April 2011, 21:01
Its just off by default (in the audio decoder), not disabled. The decoder throws out alot of warnings/errors and some people did report A/V sync issues that i could not fix yet, so i decided to turn change the default.
Thanks, guess that's why I didn't notice any issues as I only have FLAC for music.
Mercury_22
15th April 2011, 21:15
Nev, is there any reason for the latest commits that disable FLAC?
I don't seem to have any issue with my FLAC files and LAV Splitter.
Would I still be able to use the extensions registry to use LAV Splitter for FLAC?
If any one wouldn't mind, could you upload the latest build.
Thanks
Nevcairiel-LAVFSplitter-0.22-26-ga6ff28c (http://www.multiupload.com/7SYRHD7CRC)
VipZ
15th April 2011, 22:13
Nevcairiel-LAVFSplitter-0.22-26-ga6ff28c (http://www.multiupload.com/7SYRHD7CRC)
Thanks
hoborg
16th April 2011, 09:42
Hi.
Will be possible to use LAVF splitter with "File Source (URL)" for online streaming FLV/MP4/etc... ?
For example inside MediaPortal Online Videos plugin?
VipZ
16th April 2011, 10:13
Nev, with the build from Mercury, I think there may be a very minor lip sync issue in MKV with H264, at times I feel its fine, and others I question it. If I use the MPC one or official 0.22, I don't feel like I see lip sync issues. Wandering if this is the change regarding H264 in MKV.
Also the OGM, is now perfect in this build, no more 1st frame to key frame corruption on start of playback.
Thunderbolt8
16th April 2011, 13:58
nvm -.-
SamuriHL
16th April 2011, 13:59
Msvc run time.
nevcairiel
16th April 2011, 19:52
Hi.
Will be possible to use LAVF splitter with "File Source (URL)" for online streaming FLV/MP4/etc... ?
For example inside MediaPortal Online Videos plugin?
In theory it should work, the url source uses the same interfaces as the file source, but i probably need to handle some cases that i wont get the duration, and seeking wont work too well.
BatKnight
16th April 2011, 21:36
Nev, with the build from Mercury, I think there may be a very minor lip sync issue in MKV with H264, at times I feel its fine, and others I question it. If I use the MPC one or official 0.22, I don't feel like I see lip sync issues. Wandering if this is the change regarding H264 in MKV.
Also the OGM, is now perfect in this build, no more 1st frame to key frame corruption on start of playback.
It's a known issue of LAV Audio and MKV with FLAC tracks.
Use madFLAC instead, it works flawlessly.
Bat
VipZ
16th April 2011, 22:17
It's a known issue of LAV Audio and MKV with FLAC tracks.
Use madFLAC instead, it works flawlessly.
Bat
This was this AC3 bit streamed, don't have any MKV's with FLAC in it.
nevcairiel
16th April 2011, 23:11
I think there may be a very minor lip sync issue in MKV with H264, at times I feel its fine, and others I question it.
I disabled one of the sync changes, maybe someone can produce some test build for you and you can report if you still feel that you see it. Sadly those very minor things are hard to detect.
ranpha
17th April 2011, 01:12
From my tests, the 'Generate missing timestamps' option only seems to work for .mkv files, but not with *.avi and probably .mp4 too. Can the missing timestamp generation option be also enabled for those two formats?
Mercury_22
17th April 2011, 08:44
I disabled one of the sync changes, maybe someone can produce some test build for you and you can report if you still feel that you see it. Sadly those very minor things are hard to detect.
Nevcairiel-LAVFSplitter-0.22-29-g5ce415f (http://www.multiupload.com/97YOJQ4PUO)
allak
17th April 2011, 18:51
Nevcairiel-LAVFSplitter-0.22-29-g5ce415f (http://www.multiupload.com/97YOJQ4PUO)
Thanks. For what is worth, this has fixed a/v synchro problems with some very old .avi files that I have.
nevcairiel
17th April 2011, 19:20
Thanks. For what is worth, this has fixed a/v synchro problems with some very old .avi files that I have.
Compared to what build? The one he posted before, or official 0.22?
allak
17th April 2011, 23:14
Compared to what build? The one he posted before, or official 0.22?
Official 0.22.
nevcairiel
18th April 2011, 06:56
Great. :)
nlnl
18th April 2011, 15:22
Thanks for the info! And does LAV Splitter play mono LPCM streams in m2ts ?
Probably does. I don't know if i have tested one yet. Don't see why it wouldn't.
But lets not spam madshi's thread, if you have any questions, you can find the appropriate thread in my signature.
MPC HC splitter does not play mono LPCM streams in m2ts :(.
If LAV does that is great!
Can test that only in 5 days.
nevcairiel
18th April 2011, 15:39
I actually found a sample file of this, and it works just fine.
VipZ
18th April 2011, 17:35
Nevcairiel-LAVFSplitter-0.22-29-g5ce415f (http://www.multiupload.com/97YOJQ4PUO)
Thanks
Nev, I will use this build for a few days and report back.
Mercury_22
18th April 2011, 17:42
@nev
VC-1 (i) not smooth again! (Nevcairiel-LAVFSplitter-0.22-34-g260f99c (http://www.multiupload.com/4ESRP70BT3))
But only when some old black and white material it's added in the main "film" ( maybe "video in film" ? :confused: )
I have a sample but I had to make it big 500mb for it to include all this so if you want me to "up it":) let me know
Edit @ Vipz I've build an update see the link above
nevcairiel
18th April 2011, 17:48
Maybe that file is just broken?
The things i changed did actually fix some files for me.
The only things changed are better detection of keyframes and other seeking improvements. And i reverted a stupid change from before that broke some files.
What do you mean with "not smooth" anyway? Is it totally broken, just one short error?
Mercury_22
18th April 2011, 17:59
Maybe that file is just broken?
The things i changed did actually fix some files for me.
The only things changed are better detection of keyframes and other seeking improvements. And i reverted a stupid change from before that broke some files.
What do you mean with "not smooth" anyway? Is it totally broken, just one short error?
I'm sure it's not broken (blu-ray) and also it plays fine with official 0.22 and MPC-HC's internal splitter
By not smooth I mean very choppy the frame rate it's "going nuts"
EDIT look here http://img577.imageshack.us/g/lavofficial022.png/
nevcairiel
18th April 2011, 18:09
Thats directly from the BluRay, and not in MKV?
Can you try again with the latest?
Mercury_22
18th April 2011, 18:25
Thats directly from the BluRay, and not in MKV?
Can you try again with the latest?
Yes from Blu-ray folder and it's "smooth" again with the latest :thanks:
Nevcairiel-LAVFSplitter-0.22-36-g932dc3f (http://www.multiupload.com/ZEKJT01UQO)
nevcairiel
18th April 2011, 18:44
Thanks for testing! :)
Mercury_22
18th April 2011, 18:54
Thanks for testing! :)
Thanks for your work !
P.S. I still think you should have my sample ( if it's not to big) It's from BBC MADAGASCAR UK version
nevcairiel
18th April 2011, 18:55
If it works fine now, its all good.
fastplayer
18th April 2011, 19:31
Typo in common/DSUtilLite/DShowUtil.h, line 62:
// Gennenric... should be // Generic...
nlnl
18th April 2011, 19:36
I actually found a sample file of this, and it works just fine.
Thanks!
Please try that one (no video for small size). Does not work for me. Very slow playback, in jam :). The same with MPC splitter. Haali is OK!
http://www.multiupload.com/HB60BVQ65J
nevcairiel
18th April 2011, 19:41
Thanks!
Please try that one (no video for small size). Does not work for me. Very slow playback, in jam :). The same with MPC splitter. Haali is OK!
http://www.multiupload.com/HB60BVQ65J
Plays fine.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.