LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Both "XVID" and "xvid" are in the list of supported FourCCs, fwiw.

[leeperry]

Oh OK thanks, I had to enable it in ffdshow otherwise PotP refused to play it.

[Pat357]

That would mean that lav-video is not configured properly in PotPlayer to decode xvid format.

[max79]

Is it possible to add MEDIASUBTYPE_Vorbis with GUID={CDDCA2D5-6D75-4F98-840E-737BEDD5C63B} in LAVAudioDecoder ?

Any feedback would be appreciated.

[nevcairiel]

Originally Posted by max79

Is it possible to add MEDIASUBTYPE_Vorbis with GUID={CDDCA2D5-6D75-4F98-840E-737BEDD5C63B} in LAVAudioDecoder ?

No. The Vorbis Decoder requires decoder initialization data, which is not provided in the MEDIASUBTYPE_Vorbis type. Instead, you should use MEDIASUBTYPE_Vorbis2 and FORMAT_VorbisFormat2/VORBISFORMAT2 format structures, which is already supported by LAV Audio (and output by LAV Splitter)

[max79]

Originally Posted by nevcairiel

Please test these streams with ffmpeg, if it outputs 5.1 there, then you should report the problem there.

If you tell me how to do it and to what address I can send bug request I'll do it.

[max79]

to nevcairiel:
Thanks! If i'm understand you properly it's not ffmpeg(LAVAudioDecoder) limitation but by the VORBIS format structures? We always need to use MEDIASUBTYPE_Vorbis with MEDIASUBTYPE_Vorbis2 and not separately, right ?

[clsid]

Originally Posted by max79

If you tell me how to do it and to what address I can send bug request I'll do it.

http://ffmpeg.zeranoe.com/builds/
Create a new ticket here:
http://trac.ffmpeg.org/
FFmpeg output:

ffmpeg version N-86310-g220b24c Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.1.0 (GCC)
  configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib
  libavutil      55. 63.100 / 55. 63.100
  libavcodec     57. 96.101 / 57. 96.101
  libavformat    57. 72.101 / 57. 72.101
  libavdevice    57.  7.100 / 57.  7.100
  libavfilter     6. 90.100 /  6. 90.100
  libswscale      4.  7.101 /  4.  7.101
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
Input #0, matroska,webm, from 'dolby_digital_plus_channel_check_lossless-DWEU.mkv':
  Metadata:
    encoder         : libebml v1.3.0 + libmatroska v1.4.1
    creation_time   : 2015-04-06T16:08:55.000000Z
  Duration: 00:01:34.50, start: 0.000000, bitrate: 4842 kb/s
    Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
    Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default)
[eac3 @ 00000000032767e0] Dependent substream decoding is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.

[nevcairiel]

eac3 dependent substreams not working is a known limitation either way, so there is already tickets for that.

[nevcairiel]

Just as a FYI, the next official release of LAV Filters (and any nightlies as of now) will require a SSE2 capable CPU. SSE2 has been available for 15 years, and performance tests have shown up to 10% differences in some workloads (although more typical are 2-5% for common decoders).
Even though the 64-bit build has always used SSE2 (since every 64-bit CPU supports SSE2), many people still use 32-bit - often because not all other components are available in 64-bit, and at this point I feel its a better choice to offer better performance to users of more recent hardware, then cater to over 15 year old CPUs instead.

There is no strict limitations that require this in the code, so anyone could still do custom builds simply removing the flags that instruct the compilers to use SSE2, if someone desperately needs to.

[NikosD]

Have you done any speed comparisons of the current version vs the new "SSE2" ?

Because I can see that SSE2 is faster, but your current version already contains a SSE2 path, right ?

So, why the "fatter" older version supporting both older than SSE2 code and SSE2 or newer code and a new SSE2 code and better version should have any difference ?

Those questions are out of curiosity, no complaints regarding your decision.

[nevcairiel]

The manually optimized assembly code is not affected, as those indeed already used SSE2 (and newer things) - the difference is in the parts of the code that are not manually optimized in assembly, ie. the code thats in C/C++, and which the compiler optimizes. Now the compiler is allowed to use SSE2 for this, resulting in a performance improvement. The compiler can't very easily generate "two paths" automatically, like we can do for the manually optimized assembly functions, which often not only support two but even more, so it needs to be told the level of optimizations it can use - which is now SSE2.

The numbers I mentioned above where tested on the current Git version, with SSE2 on and off. It varies a lot based on the files and codecs used, but generally there was always a measurable improvement.

[NikosD]

So, the C/C++ compiled code affects that much (~15%) the performance, even though the manually optimised assembly parts are in full use.

Interesting, thanks.

[nevcairiel]

Originally Posted by NikosD

So, the C/C++ compiled code affects that much (~15%) the performance, even though the manually optimised assembly parts are in full use.

There is a lot more C code then assembly code. Many things are very hard to fully write in assembly, but the compiler can do small optimizations in those functions using SSE/SSE2, so it helps.

[max79]

Problem with LAV Splitter Source. Why it can't play this stream:
mms://online.svitle.org/Emmanuel
As workaround i must change URL like this:
mmst://online.svitle.org/Emmanuel

Any feedback would be appreciated.

p.s. Thank you for quick response clsid!

[max79]

Problem with LAV Splitter Source. Why it can't play this remote file:
http://trailers.divx.com/hevc/SHANE_...VC_10Mbits.mkv
As workaround i must change URL like this:
http://trailers.divx.com/hevc/SHANE_...VC_10Mbits.mkv

Any feedback would be appreciated.

[max79]

If i use "FileSource(URL)+LAVSpltter" in GraphEdit sometimes i have error message about "....TIMEOUT: ..." for this remote file:
http://trailers.divx.com/hevc/SHANE_...VC_10Mbits.mkv
And in other cases if graph builds I noticed another problem with wrong video duration. Have a look-
https://forum.doom9.org/attachment.p...1&d=1496421383

Any feedback would be appreciated.

[nevcairiel]

Originally Posted by max79

Why it can't play this stream:
mms://online.svitle.org/Emmanuel
As workaround i must change URL like this:
mmst://online.svitle.org/Emmanuel

Thats just how mms streams work. mms:// is for HTTP transport, mmst:// is for TCP transport, it depends what kind that server is offering and you need to use the correct URL.

Originally Posted by max79

Why it can't play this remote file:
http://trailers.divx.com/hevc/SHANE_...VC_10Mbits.mkv
As workaround i must change URL like this:
http://trailers.divx.com/hevc/SHANE_...VC_10Mbits.mkv

Spaces in URLs always have to be encoded, thats just how URLs work. If anyone gives you a URL with a space in it, they are doing it wrong.

[max79]

Originally Posted by nevcairiel

Thats just how mms streams work. mms:// is for HTTP transport, mmst:// is for TCP transport, it depends what kind that server is offering and you need to use the correct URL.

Spaces in URLs always have to be encoded, thats just how URLs work. If anyone gives you a URL with a space in it, they are doing it wrong.

Ok, but why LAVfilter doesn't use this order of connection?:
https://en.wikipedia.org/wiki/Microsoft_Media_Server
Enduser have no idea about correct URL or not. I've got live stream URL from radio station site. All my ten other players which is not use LAV playback stream from my example without any changes in URL name!

DIVX.COM site administrator doing it wrong. JFI- such URLs work without problems through FileSource(URL)...

Thank you!

[nevcairiel]

Its just how MMS works in ffmpeg, you are always free to not use LAV for it. In general, I would recommend to use dedicated streaming filters for streaming sources, as LAV is not very optimized for it. Its optimized for local file playback, and thats what it does well.