LAV Filters - DirectShow Media Splitter and Decoders

[vad74]

nevcairiel
I nave a problem with my interlased video. This is H.264 stream in m2ts files from my Sony camcoder. I use LAV with DXVA2, and Field Order set in Auto. From my files MediaInfo show info: Interlaced and Top Field First. When I playback video, I see very strobed video. Than, I in LAV set Field Order to Top Field First - video play smoothly! Result : LAV not correct take Field Order from file. Than, I join some m2ts files together to 1 file, without recompress. When I play it, some parts (early was separate m2ts) play smoothly another strobed. May be, when LAV reading new part of video, LAV change Field Order. I can upoad my file to internet for tests, if need.

[cyberbeing]

Nev, can you tell me why this sample (http://www.mediafire.com/?srj92zrjxv8z52w) doesn't show the English subtitles when specified when I have Directvobsub loaded? If Directvobsub is not loaded LAV selects it just fine.

There actually does seem to be a bug in LAV Splitter which is preventing it from correctly reading the language codes of the particular OGM sample ryrynz provided.

The Japanese audio track is not selected when jpn is set.
No subtitle track is selected by LAV Splitter when eng or jpn is set.
Only using * will make LAV Splitter select the subtitle track.

Haali Splitter has no issue with ryrynz's sample, which is detected as follows:
Audio Track 1: eng
Audio Track 2: jpn
Subtitle Track 1: eng
Subtitle Track 2: und

LAV Splitter has no issue with a few other OGM files I tested, so it must be something particular about how the languages in ryrynz's OGM were tagged.

DirectVobSub has no involvement in subtitle selection when LAV Splitter is used. I can only assume that ryrynz's media player is correctly selecting a subtitle track when DirectVobSub is disabled, yet leaves stream selection entirely to LAV Splitter when DirectVobSub is enabled. The problem being that LAV Splitter stream selection by language codes is apparently broken on that OGM, causing no subtitle track to be selected with or without DirectVobSub loaded (with MPC-HC).

[nevcairiel]

nevcairiel
I nave a problem with my interlased video. This is H.264 stream in m2ts files from my Sony camcoder. I use LAV with DXVA2, and Field Order set in Auto. From my files MediaInfo show info: Interlaced and Top Field First. When I playback video, I see very strobed video. Than, I in LAV set Field Order to Top Field First - video play smoothly! Result : LAV not correct take Field Order from file. Than, I join some m2ts files together to 1 file, without recompress. When I play it, some parts (early was separate m2ts) play smoothly another strobed. May be, when LAV reading new part of video, LAV change Field Order. I can upoad my file to internet for tests, if need.

Nothing is wrong with LAV. Your file most likely just has no Field Order flags. Broken files will be broken.

Nev, can you tell me why this sample (http://www.mediafire.com/?srj92zrjxv8z52w) doesn't show the English subtitles when specified when I have Directvobsub loaded? If Directvobsub is not loaded LAV selects it just fine.

Its the typical OGM screwed up language tags.
LAV recognizes language tags in many formats, like just "eng", or just "English", however that particular OGM file contains the info "English[eng]", which is not supported in this format. You can see this yourself if you just look at the stream names LAV produces.

I can probably make it try to look for a "[eng]" tag in the language field and try to identify that, but thats hardly a high-priority issue.

[ice25]

Nev, would it be possible to add a shortcut for the Audio Delay?

[vad74]

nevcairiel
MediaInfo show that video is Top Field First. But LAV play good only when I manualy set Top Field First. I dont assert that LAV is bed. May be video have a problem. But MPC-HC play video very good with built-in DXVA decoder! I only ask help resolve this problem. Letter I try upload file for tests.

[nevcairiel]

An uploaded file won't help anything.

I explained this just a few posts ago. If your file contains NO field order flags, then Media Info assumes that it is TFF, and LAV assumes its BFF. So MediaInfo gets it right by accident, but there are other files which are actually BFF and have no flags, where LAV gets it right by accident, and MediaInfo gets it wrong.

Broken files will be broken. If it works only depends on which field order is assumed to be the default if its not set.

[zipi]

@nevcairiel, just wanted to say a big Thank You for the great work man, all the best to you.

[DragonQ]

Nev, would it be possible to add a shortcut for the Audio Delay?
This'd be cool actually. At the moment if I have a file where the audio is slightly out of sync with the video, I have to use MPC-HC's audio switcher and then use +/- keys to find (roughly) the correct sync so I know what to put in MKVMerge when remuxing.

[nevcairiel]

LAV will not do any shortcuts in the forseeable future.

[vad74]

nevcairiel
OK. Please, tell me right program that show me was set this flag or not. And know you programm that can set-change this flag? Answer me please.

[Reino]

(Hopefully tiny) feature request: Would it be possible to show the audio and video format/bitrate/sample rate when hovering over the tray icons, respectively? Thanks!I second that. FFDShow-style.
+1

[dansrfe]

If I play a file which has a 6 channel, 24-bit, 48Khz truehd track and an identical spec track encoded as dts-hd-ma, which one would LAV Audio Decoder choose automatically, by default?

As of know it's choosing the truehd track (which is audio track #1) over the dts-hd-ma track (which is track #3). I thought it would choose the dts-hd-ma track by default but I guess it doesn't matter too much since the truehd and dts-hd-ma tracks sound the same anyways.

[nevcairiel]

It prefers TrueHD over DTS-HD MA because TrueHD can be decoded losslessly by popular decoders without external help (ie. DTS-HD MA needs LAV Audio with the ArcSoft dtsdecoderdll.dll, and TrueHD works with LAV Audio, ffdshow, MPC-HC decoders, ...)

If all else fails, track order matters, so in a set of identical tracks, the first wins.

[dansrfe]

^ Ah, I see. Thanks!

[dukey]

nevcairiel,
I've got some VC1 files which are marked as copy protected (but they aren't). They play fine, powerdvd plays them.


/* Check TP_extra_header Copy_permission_indicator. If != 0, unit is still encrypted. */
if (buf[0] & 0xc0) {


Using CUDA they work fine.
Using DXVA/non DXVA + DMO they work fine
Using DXVA/non DXVA they fail

just get a black screen

[nevcairiel]

Why would you turn off the DMO? The FFmpeg Software Decoder is just incomplete.
Otherwise I really don't know what you are Asking.

PS: This is why I removed this check in my libbluray.

[wanezhiling]

How about blocking the ffmpeg software vc-1 decoder? then people will always use the efficient DMO decoder.

[nevcairiel]

The DMO is enabled by default, if someone disables it, its their own damn fault. :p

[dukey]

I was just testing different modes and wondering why the behaviour was different with non DMO. I too removed the encrypted check in libluray. I'll try and get it permanently removed because it makes no sense. It gives a warning anyway which should be sufficient enough.

[nevcairiel]

it should probably still fire the event, just not do the return -1

[dukey]

exactly

[filler56789]

How about blocking the ffmpeg software vc-1 decoder? then people will always use the efficient DMO decoder.

Depending on how old/how odd :) the machine is,
the ffmpeg-based VC-1 decoders can be FASTER than the Micro$oftic one. ;)

[nevcairiel]

Faster doesn't help if it doesn't give you any image (for interlaced material), or images not as good as can be, because of missing other features. :p

[filler56789]

or images not as good as can be, because of missing other features. :p

Thanks for the warning, I didn't know ffmpeg/libav sucked that much. :scared: :D

[nevcairiel]

Just the VC-1 decoder, its rather terrible. :p

[DragonQ]

Seems a bit strange - surely VC-1, H.264 and MPEG2 are the "big three" codecs and thus demand high priority in terms of improvements and bug fixes?

[nevcairiel]

That's not how it works. People work on what interests them in most cases and not what is "popular". That's the big difference between open source and commercial work.

But we have the DMO so who cares much. :)

[DragonQ]

Yeah but people are likely to have more VC-1 files themselves than, say, FFV1 files. Would making files they actually have work not be interesting? :p

[paradoxical]

Yeah but people are likely to have more VC-1 files themselves than, say, FFV1 files. Would making files they actually have work not be interesting? :p

Apparently not. Otherwise someone would have made the VC-1 decoder as feature complete as DMO.

[nhakobian]

Yeah but people are likely to have more VC-1 files themselves than, say, FFV1 files. Would making files they actually have work not be interesting? :p

You also have to remember, some of these other formats may be much simpler to implement or maybe had an open source implementation that just needed to be merged in. VC1 also may just be so ugly to deal with that no one has wanted to push for fixing the issues.

(These are all suppositions of course, there could be more technical reasons for this to be the case.)

[ddjmagic]

Nev - I'm sorry you are right, I have made a mistake here.

XBMC does not have any logic different to LAV my tests were incorrect. This is what fooled me -

When I selected one of the problem titles from the library in XBMC, this comes up (Example Hellboy)

Now I presumed (wrongly) that XBMC was telling me that playlist 30 was correct (which it is), kind of how Speedmenus would by listing it at the top.

In reality this was just giving me a list of titles it thinks the main movie might be and it just listed them from low to high.

This is why some from my list worked and some didn't, it just depended on if the correct playlist was a lower number.

So that's why you couldn't find any extra logic in XBMC, it was never there to begin with :o

Sorry for anytime you wasted on this! :scared:


After spending a little more time looking at this, it doesn't seem like XBMC 12 does use the same logic as LAV, I originally thought it was just listing the titles from low to high, but after more testing I've found some BD's that contradict this.

Not sure how its actually determining the order of tracks in the popup menu, buts its definitely different to what LAV/MPC/JRiver chooses.

Nev did you get chance to look into improving selection?
Or are you going to wait for when Slysoft eventually include it in the 'disc.inf' of all discs?

[Schwartz]

0.55.1 can play homecooked AVI created with x264vfw just fine. 0.55.2 will just show a black screen and act like it's an empty file.

I assume this has to do with a change from "Improved support for MP4-style H.264 in AVI".

I realize x264 in AVI is a dirty thing to begin with, but this seems like a clear change from working to not working regardless.

[nevcairiel]

Provide a sample file which is now broken, and i'll look at it.

[Schwartz]

Sample (http://www.filedropper.com/x264vfwtest). Thanks for the quick reply!

Oh also.. the same video stream muxed into MKV will play fine with either version. So it's an AVI thing.

[nevcairiel]

I see why this file stopped working, its one of those i feared that might appear, with a AVC1 FourCC (which usually indicates MP4-style H.264), but actually with an Annex B stream (which usually uses the H264 FourCC).
The good news however is that i already rewrote how this is handled for the next version to make it more future proof (which i'm sure will also break some weirdo files), and the file works with the latest development build.

In fact, here is the latest development version:
http://files.1f0.de/lavf/LAVFilters-0.55.2-4-gf041b60.zip

Since 0.55.2, i mostly focused on removing a bunch of format-specific hacks and coming up with more generic solutions, one of these areas was trying to clean up the handling of AVC1/H264 differences.
I'm quite sure that some weirdo files may stop working properly now, so please report if you find some, and i can try to fix them properly.

I've also been considering removing the Annex B -> MP4-style conversion in the splitter, and output the stream as-is. I've already removed it for a bunch of formats (because it caused some issues), and effectively its only used for MPEG-TS now, but i may remove it there as well, however this may introduce incompatibility with some old or broken decoders. It should however not make any difference at all for LAV Video, except it may result in slightly higher performance because the source packages are not parsed completely in the splitter anymore.

[Schwartz]

That's interesting. I'll set it to H264 from now on, just to be more conform with these encoding settings.

If any odd files pop up, I'll post them.

[dukey]

nevcairiel,
is it safe to call queryaccept downstream to LAV and change the video resolution ? Or will this result in a cataclysmic failure. I've been getting some issues with this.

[nevcairiel]

QueryAccept itself is only a "query" function as the name suggests, so only calling it does nothing except tell you if LAV in general accepts that format or not.
However, LAV should support dynamic changes just fine, you just need to attach a new media type to the first packet of the new stream.

[dukey]

okay thanks

[dukey]

I get crashes like this on format change
Changing type/resolution

Fault Module Name: LAVVideo.ax

I'm not really sure what causes it. The new media type is correctly being attached to first packet of the new type. Originally it called queryaccept whilst the queue of buffers was still sending. I tried waiting until the queue emptied before doing a format change but the result is the same :p

[nevcairiel]

Then you are doing something wrong. :)

[dukey]

Only seems to break when the resolution changes

[bugmen0t]

Subtitles are broken for me for some time now. The first subtitle is always chosen no matter what (using default settings for LAV Splitter subtitles). Is there a setting which causes this and I could have accidently turned on? Trying to change them while playing using madVR, LAV Splitter or MPC-HC menu has weird effects like nothing happens or none is shown if another than the first one is selected or some other seemingly random thing happens. :confused:
Any ideas?

[sneaker_ger]

I had the same phenomenon when I activated MPC-HC's internal subtitle renderer. ("Options">"Playback">"Auto-load subtitles")
Sometimes it also changes depending on whether you had "Enable" ("Play">"Subtitles") or the subtitle track selected or not. Seems to be caused by MPC-HC.

[kasper93]

@bugmen0t @sneaker_ger Use mpc-hc builds older then r6518 (7035e41). It's know issue and we need to wait for the fix ;)

[dukey]

nevcairiel,
Do you plan to support DynamicQueryAccept on your input pins ?
I think this is the problem I've been getting :p Changing video resolution without stopping the graph causes all kinds of pain

[nevcairiel]

Do you plan to support DynamicQueryAccept on your input pins ?
I think this is the problem I've been getting :p Changing video resolution without stopping the graph causes all kinds of pain

Nothing really supports DynamicQueryAccept, so i have no plans for this either.
And other things manage to change resolution just fine. The MediaPortal BD filter for example, or my own tests of dynamic stream switching.

[mkanet]

Hi Nev,

I use VLC to transcode a liveTV RTMP stream into a format that most players can read (mpeg-PS/mp3 audio). I know that VLC doesnt handle RTMP streams to well anyway; but it does manage to get playable streams for any standalone media player or via directshow (as long as LAV splitter is not used). It plays correctly with other splitters too.

For some reason, LAV splitter can't handle these streams properly. The video stream isnt coming through at all. I was hoping you could take a look at the media file below to see if you can get LAV splitter to "tolerate" this type of media file; as bad of a shape that it's in.

http://ge.tt/72xl2JX/v/0?c?c

Thank you so much.

[nevcairiel]

I made some changes for the next version that make especially mpegts/ps probing a bit more tolerant, it helps for your sample, however i can't be sure it works for all these files.

[mkanet]

Wow Nev, thank you. I can't believe you already fixed it. I'll keep a close look for the next beta build.

BTW: I am still enjoying your SageTV VC1 fix you added a little while back!

I made some changes for the next version that make especially mpegts/ps probing a bit more tolerant, it helps for your sample, however i can't be sure it works for all these files.