LAV Filters - DirectShow Media Splitter and Decoders

[Ger]

Works in Graphstudio, so it's probably just not registered for audio-only types (yet). I think Nev mentioned something about that once, but I've forgotten the details.

[nevcairiel]

Originally Posted by mindbomb

no, it doesnt appear to be a flac source filter.

It can be, though!
Do flac ES files have a typical byte marker to detect them?
Thats usually a problem with those elementary stream files..

Edit:
It appears they do, can someone with such a file confirm that the first 4 bytes say "fLaC"?

[Ger]

Checked three files. All start with "fLaC".

[madshi]

http://flac.sourceforge.net/format.html#stream

[nevcairiel]

Thanks, i found that too. I was actually looking into adding support for alot more raw audio streams, but not all seem to have an accurate byte marker, so i'll probably hook them up based on extensions. While i'm at it, i'll probably do it for all file types. With MPC-HC, that doesn't really change any behaviour, as extension hookups are not directly prioritized, for other players it could however mean that LAV Splitter gets the priority .. not that it bothers me. =)

[madshi]

Hopefully you won't overwrite madFlac, though?

[nevcairiel]

With any sane player, it should come down to what the user configured, or if anything, merit. Now i dunno what the merit of the madFlac source filter is, but LAV Splitter is pretty high.

Edit:
I checked, and the merit of madFlac Source is pretty low (just MERIT_NORMAL), so unless the user configures something, LAV Splitter would be used instead.

Edit2:
It actually looks like you _ONLY_ do extension hookups? no byte markers?
Then it will be overwritten, unless i feel like developing some fancy installer first that could deal with all of this.

[madshi]

It should be possible somehow to continue using madFlac. If "prefering" madFlac in MPC-HC does the trick, that should be good enough.

[nevcairiel]

Only you can tell me if it actually registers for the byte markers - i didn't see it in the registry. Of course people can still use the decoder in any case.

Every extension can only have one source filter, while the byte markers are really alot more flexible and every source filter can let DirectShow know that it supports this marker and the merits decide. Thats why i really preferred them until now, and containers typically are easy to detect .. not so much all raw streams.

[madshi]

So if people install the LAV Splitter first and madFlac after that, madFlac "wins", because madFlac will overwrite the extension registration? I think that would be good enough. There just needs to be a way to use the LAV Splitter and madFlac at the same time. And yes, madFlac must be "allowed" to work as a source filter, too.

I don't think I register for "byte markers", didn't even know that I could... But then I've written madFlac quite a while ago, so I don't remember all the dirty details.

[nevcairiel]

Yes, registering it after LAV Splitter would work.

[madshi]

Ok, that's good enough for me. Of course before you automatically register (= overwrite) *hundreds* of new extensions it might make sense to write some kind of installer... You can't know for sure that LAV Splitter will match (or beat) every existing DirectShow source filter out there. So maybe it would make sense to cherry pick extensions for now. Just my 2 cents, of course.

[v0lt]

@nevcairiel
http://www.multiupload.com/PYBILYB30E
MPC-HC 1.5.2.3010 + LAVFSplitter 0.19 + Microsoft DTV-DVD Video Decoder = wrong speed of video
(internal, ffdshow and ArcSoft decoders are buggy with this video stream)

PS: I do not have enough CPU power to play in VLC media player, but sync is better in VLC.

[CruNcher]

Wow v0lt that stream crashed Cyberlinks Decoder to be exactly it caused a crash in the sse3 part :P
AppName: mpc-hc.exe AppVer: 1.5.2.2994 ModName: 264dsse3.dll
something is strange with that stream DXVA mode is giving all kind of nice effects with different Decoder :P
Though currently Halli parse it
Hmm i could swear it uses either intra refresh or a very low keyframe cycle at least visual error wise (it pulses between errors) it looks like it and 6 slices
The internal MPC-HC parser doesn't detect the Video stream @ all

[nevcairiel]

Broken streams are just that, broken.

[CruNcher]

Not sure if the stream is broken Haali + CoreAVC (CPU) decode it perfect, also via Nvcuvid no problems
Complete Lav Cuvid Framework has also no issues + Haali Splitter
It would make sense if v0lt used DXVA with Microsofts decoder that it's yet another DXVA problem though its different then what you visually see from the to much reference decoding problem

Cyberlin DXVA Decoder + Lav Splitter + Lav Audio + VMR7 windowed = Frame Freeze audio plays
CoreAVC DXVA + Arcsoft Demuxer + Lav Audio + VMR7 windowed = Black Screen audio plays
Cyberlink DXVA + Arcsoft Demuxer + Lav Audio + VMR7/9 windowed/Renderless = Perfect
Cyberlink DXVA + Haali Splitter + Lav Audio + VMR7/9 windowed/Renderless = Crash in Cyberlinks Decoder
CoreAVC DXVA + Haali Splitter + LAV Audio + VMR7/9 windowed/Renderless = Playbacks Video and Audio but with some Visual Errors (slice borders and intra refresh visible)
CoreAVC DXVA + MPC-HC Splitter + LAV Audio + VMR7/9 windowed/Renderless = Audio Plays Video Stream PID not found

I love these Transport Stream Parser issues, especialy in combination with DXVA they can give funny results

So in v0lt case most probably the problem is indeed Lav Splitter in combination with Microsofts Decoder and DXVA, though Cyberlinks Demuxer 2.0 and Arcsofts MPEG Demuxer are more robust they work different (they seem to work directly @ the bitstream level for TS streams and take only some information into account so they can cope welll with corrupt streams, which for Satellite transmission you have no other chance for) then MPC-HC or Gabest Lav Splitter it could be that the muxed ts file here is corrupt

So the CoreAVC DXVA + Haali Splitter result is not bad, especialy as you lose most controll with Arcsoft and Cyberlinks Demuxer in MPC-HC

[v0lt]

Originally Posted by nevcairiel

Broken streams are just that, broken.

Maybe, but MediaInfo shows this:

Video
ID                               : 4113 (0x1011)
Menu ID                          : 1 (0x1)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Duration                         : 1mn 58s
Bit rate                         : 11.6 Mbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Resolution                       : 8 bits
Colorimetry                      : 4:2:0
Scan type                        : MBAFF
Bits/(Pixel*Frame)               : 0.224
Stream size                      : 164 MiB (81%)
Color primaries                  : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics         : BT.709-5, BT.1361
Matrix coefficients              : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Here we see 25 fps. But LAVFSplitter shows AvgTimePerFrame = 1778. This is equivalent to 5624 fps
(25 fps -> AvgTimePerFrame = 400000)

[CruNcher]

Was this directly a sat transmission or transcoded could be maybe a Ateme Stream ?

[v0lt]

Originally Posted by CruNcher

Was this directly a sat transmission or transcoded could be maybe a Ateme Stream ?

I do not know.

Hilary.0000.ts
LAV Splitter not play. But WMP is playing.

[CruNcher]

The CoreAVC issue seems to be a Render bug on Nvidia Hardware via DXVA on their side, almost any .m2ts stream borks visually out with CoreAVC DXVA and VP2

A new Playback feeling