LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

Developers that steal code from others obviously also have no trouble supporting broken hacks.

Its not a big accomplishment to support that. Its like two lines of code, but its called having principles and design goals instead of littering the code with hacks, or it ends up like an unmaintainable mess like ffdshow or the old mpc-hc decoders.

[NikosD]

There are hacks everywhere.

If literally it's just a few lines of code, then I'm sure you'll find a way to maintain LAV filters and protect them becoming a mess.

[nevcairiel]

Its not the only reason. I will not support such behavior, and as such it will never happen, and hopefully deter people from creating it in the first place.

[VFR maniac]

Strongene's HEVC-in-FLV is stupid.
Strongene abuses CodecIDs of FLV and probably brings about fatal incompatibility with the future supports of FLV.
If we support them, the workaround will be highly complicated and encroach on unrelated regions.
From 2 to 7 CodecIDs are predefined in the official spec (Version 10.1), and Strongene defines from 11 to 14 for HEVC including draft versions.
CodecID is only 4-bit, i.e. CodecIDs are values of the range of 0 to 15.
If we permit Strongene's, the rest is 0, 1, 8, 9, 10 and 15.

[Djfe]

Not possible: P frames are just differences from I frames, you must have I frames to start with.

Perhaps you meant it's all I frames, in which case it would be very close to "motion jpeg".

Whatever the situation, it is up to sources to follow standards, not decoders to allow for every possible variation.

Ok than it has probably I-Frames
but except the artefacts at the beginning it is playing fine


I tested it with ffplay and the video plays fine, it just uses the wrong audio stream on default (dolby e), which it isn't able to play

ffplay output:
[mpeg2video @ 03d74a00] Invalid frame dimensions 0x0. 0B f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframe f=0/0
[mpegts @ 03d73ea0] PES packet size mismatch 0KB sq= 0B f=0/0
Last message repeated 2 times
Input #0, mpegts, from 'Y:\TSD Test\test\02-20_20-33-42_PAOK FC -Benfica_.ts'
:
Duration: 00:00:19.96, start: 32171.787089, bitrate: 20976 kb/s
Program 1
Stream #0:0[0x200]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420
p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], max. 17500 kb/s, 25 fps, 25 tbr, 90k
tbn, 50 tbc
Stream #0:1[0x1010](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, ster
eo, s16p, 373 kb/s
Stream #0:2[0x1020](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, ster
eo, s16p, 373 kb/s
Stream #0:3[0x1030](eng): Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo
, s32, 2304 kb/s
[mpeg2video @ 03d74a00] warning: first frame is no keyframe
[mpeg2video @ 03d74a00] warning: first frame is no keyframeB f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframe f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframeB f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframeB f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframeB f=0/0
[mpeg2video @ 03d74a00] warning: first frame is no keyframeB f=0/0
Last message repeated 1 times
[mpegts @ 03d73ea0] PES packet size mismatch 509KB sq= 0B f=0/0
[s302m @ 03d77680] frame has invalid header 209KB sq= 0B f=0/0
[mpeg2video @ 03d74a00] ac-tex damaged at 84 547KB sq= 0B f=0/0
32193.62 A-V: -0.002 fd= 18 aq= 0KB vq= 0KB sq= 0B f=0/0

first frame is no keyframe is probably the reason for the artefacts at the beginning

since it plays fine, I won't file a bug, yet.

[filler56789]

...
first frame is no keyframe is probably the reason for the artefacts at the beginning

Nope, because I see that warning message "all the time" when using MPlayer with many different types of video.

since it plays fine, I won't file a bug, yet.

ffmpeg is unable to demux/remux the M2V stream, so at least you should post the sample file to their FTP site.

[jkauff]

I don't.

But obviously others do.

Is there officially H.264 in FLV ?
Because if there is, then it will be for H.265, my guess.

The clip is from Strongene's samples and that's why they give an flv splitter along with their decoder.

But once again PotPlayer supports even that!
I don't think there will ever be another version of FLV. All of Adobe's new tools use HTML5.

[Djfe]

Nope, because I see that warning message "all the time" when using MPlayer with many different types of video.



ffmpeg is unable to demux/remux the M2V stream, so at least you should post the sample file to their FTP site.

thx for reminding me of that, will do

I hope the following command was correct:
C:\Users\Siggi\Desktop\ffmpeg-20140824-git-1aa153d-win32-static\bin>ffmpeg -i "Y
:\TSD Test\test\02-20_20-33-42_PAOK FC -Benfica_.ts" -vcodec copy -an -f mpeg
2video "Y:\TSD Test\test\test.m2v"
ffmpeg version N-65860-g1aa153d Copyright (c) 2000-2014 the FFmpeg developers
built on Aug 24 2014 00:08:13 with gcc 4.8.3 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
le-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --
enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-lib
modplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrw
b --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinge
r --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --en
able-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-
libx265 --enable-libxavs --enable-libxvid --enable-decklink --enable-zlib
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 0.101 / 56. 0.101
libavformat 56. 2.100 / 56. 2.100
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 0.103 / 5. 0.103
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 0.100 / 53. 0.100
[mpeg2video @ 03ee4da0] Invalid frame dimensions 0x0.
[mpeg2video @ 03ee4da0] warning: first frame is no keyframe
[mpegts @ 00387ee0] PES packet size mismatch
Last message repeated 2 times
Input #0, mpegts, from 'Y:\TSD Test\test\02-20_20-33-42_PAOK FC -Benfica_.ts'
:
Duration: 00:00:19.96, start: 32171.787089, bitrate: 20976 kb/s
Program 1
Stream #0:0[0x200]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420
p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], max. 17500 kb/s, 25 fps, 25 tbr, 90k
tbn, 50 tbc
Stream #0:1[0x1010](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, ster
eo, s16p, 373 kb/s
Stream #0:2[0x1020](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, ster
eo, s16p, 373 kb/s
Stream #0:3[0x1030](eng): Audio: s302m (BSSD / 0x44535342), 48000 Hz, stereo
, s32, 2304 kb/s
Output #0, mpeg2video, to 'Y:\TSD Test\test\test.m2v':
Metadata:
encoder : Lavf56.2.100
Stream #0:0: Video: mpeg2video ([2][0][0][0] / 0x0002), yuv420p, 1920x1080 [
SAR 1:1 DAR 16:9], q=2-31, max. 17500 kb/s, 25 fps, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame= 0 fps=0.0 q=-1.0 Lsize= 0kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing ove
rhead: unknown


EDIT:
attached full log

EDIT2:
Trac Ticket
https://trac.ffmpeg.org/ticket/3890

[zerowalker]

Am i doing something wrong or is x264 PC range not decoding correctly?
It always assume it's TV range.

[DragonQ]

Am i doing something wrong or is x264 PC range not decoding correctly?
It always assume it's TV range.

Those options only apply if you're outputting RGB. By default LAV will send NV12 or YV12 to the renderer.

[zerowalker]

Ah that explains it.

Hmm, to bad this can't be done with flags to the Renderer, at least not with EVR i guess.

But well, is there any drawback with decoding to RGB vs "Original Format"?

[LigH]

1. conversion takes time and CPU load
2. conversion reduces quality (rounding errors, might even become apparent for only 8 bits per component)
3. result is twice as large (RGB: 24 bit per pixel; YV12: average 12 bits per pixel over 2x2 pixels), takes more time to pass the bus from PC RAM to video card memory

[zerowalker]

2. conversion reduces quality (rounding errors, might even become apparent for only 8 bits per component)

Won't this always occur anyway?

1,3 are something to think of though.

[xabregas]

Can someone be kind enough to explain me file source async. I never used it or saw it in mpc -» filters while watching a video, and now i see, before it was lav splitter source alone and now i have lav splitter and file source async. What is this? Which one is better?

TIA

[nevcairiel]

There should be no difference in playback at all. If there is, its a bug.

[vivan]

Won't this always occur anyway?It will, but at last stage.

Chroma upsampling -> color conversion (yuv -> rgb) -> upscaling.

madVR does all of this with 16 bit precision and dithers to 8 bit at the last stage. But if you force decoder to output rgb, you will get needless precision decrease in the middle.

Probably it would be noticable only at huge upscale factors and with high bit depth source (in form of huge grain size)... but still.

[sneaker_ger]

Hmm, to bad this can't be done with flags to the Renderer, at least not with EVR i guess.

I remember the CCCP team saying that flags including colormatrix (don't know about range) actually could be handled by the MS renderers but that LAV is not sending them because of some blacklist. They had a patch but I don't know what came out of it. nevcairiel must have had his reasons to blacklist them.
Was this problem re-evaluated?

[nevcairiel]

Its sent to EVR now, but it only obeys the matrix to some degree, not the range flags.

[zerowalker]

It will, but at last stage.

Chroma upsampling -> color conversion (yuv -> rgb) -> upscaling.

madVR does all of this with 16 bit precision and dithers to 8 bit at the last stage. But if you force decoder to output rgb, you will get needless precision decrease in the middle.

Probably it would be noticable only at huge upscale factors and with high bit depth source (in form of huge grain size)... but still.


Didn't know 16bit RGB to YUV was possible. Or well i mean it was even useful.

But hmm, well to bad, renders Fullrange pretty worthless as it's not automatic in a good sense. Or well not useless but wanted it to be better;P

[foxyshadis]

Not possible: P frames are just differences from I frames, you must have I frames to start with.

Perhaps you meant it's all I frames, in which case it would be very close to "motion jpeg".

Whatever the situation, it is up to sources to follow standards, not decoders to allow for every possible variation.

This is known as Periodic Intra Refresh, and x264 has had it for nearly 5 years, professional MPEG-2 encoders even longer. It is perfectly cromulent, it's up to ffmpeg to fix their intra-refresh support. It's rare on TV, but common in video-conferencing.

It will, but at last stage.

Chroma upsampling -> color conversion (yuv -> rgb) -> upscaling.

madVR does all of this with 16 bit precision and dithers to 8 bit at the last stage. But if you force decoder to output rgb, you will get needless precision decrease in the middle.

Probably it would be noticable only at huge upscale factors and with high bit depth source (in form of huge grain size)... but still.

All handled in 32-bit floating point, actually; such high precision that even though madvr and shaders convert to and from RGB constantly it never hurts quality. Linear light upscaling and dithering are two more things that benefit from better input; even if you don't use them, the video gets flatter and blotchier if you truncate early, a particular problem on animation.

[zerowalker]

I knew it's used in anything that changes colors or add effects etc. As less rounding errors and then dither down will "ease the issues".

But that YUV to RGB did this is something i didn't know.
I thought it would simply translate the color information, not doing any upsampling or downsampling that would matter, at least for YV24 (as the other has low Chroma).

Hmm, is this something that can be used when using YUV in editing software like After Effects etc, or will i have to decode it manually to RGB48 or something weird for that to be possible?

[nevcairiel]

This is known as Periodic Intra Refresh, and x264 has had it for nearly 5 years, professional MPEG-2 encoders even longer. It is perfectly cromulent, it's up to ffmpeg to fix their intra-refresh support. It's rare on TV, but common in video-conferencing.


While it does technically play when you just assume it has intra refresh, it lacks any metadata to inform the decoder of this fact, and as such the decoder is incapable to determine what to do to get an artifact free image.

[foxyshadis]

While it does technically play when you just assume it has intra refresh, it lacks any metadata to inform the decoder of this fact, and as such the decoder is incapable to determine what to do to get an artifact free image.

I bet it does, but ffmpeg doesn't parse it. There's a ton of user-private, reserved, or "unimplemented" descriptors shown when you run it through dvbsnoop, and I wouldn't be surprised if one of them was it.

[nevcairiel]

I bet it does, but ffmpeg doesn't parse it. There's a ton of user-private, reserved, or "unimplemented" descriptors shown when you run it through dvbsnoop, and I wouldn't be surprised if one of them was it.

kierank looked at it, and he didnt recognize anything indicating it, and I figure he would know. But who knows, a stream with Dolby E is obviously something internal, maybe they use some special encoder that writes its own magic.

[DragonQ]

So I noticed today that when playing a video on my HTPC with a Dolby TrueHD audio track, the audio is really dodgy (constant stutter and popping). If I look at EVR's graph the red line looks like a square wave (rather than a flat line) when it's doing this, plus the "actual fps" is down to like 5-6 instead of 23.796 (see this screenshot (http://www.aotplaza.com/Files/HTPC/Screengrabs/LAV%20-%20Dolby%20TrueHD%20Issue.png)). It's not a dodgy file since it happens with all of them (DTS-HD MA and other formats are fine), and it happens in both MPC-HC with MadVR and MediaPortal with EVR, so I don't think it's a renderer-specific issue. I have LAV Audio set to downmix to 5.1 using standard downmixing values, plus Clipping Protection and Normalise Matrix are enabled. The strange thing is that if I keep watching (with the audio muted because it's hellish to listen to), it'll sometimes go away. Sometimes it'll come back as well, and if I play the video from the start again it'll randomly fix itself and break itself at different points in the video. This suggests to me it that isn't a timecode issue either. Oh, and seeking always seems to break it as well.

Has anyone else noticed a problem with Dolby TrueHD? The files all play fine on my other machines (which all use LAV Filters too), although I don't use HDMI or 5.1 on any of those.

[SeeMoreDigital]

So I noticed today that when playing a video on my HTPC with a Dolby TrueHD audio track, the audio is really dodgy (constant stutter and popping).
Out of interest. What container are these media files stored in, .m2ts or .mkv?

[DragonQ]

Almost all of my HD stuff is MKV. Do you think it could be a muxing issue?

EDIT: It turns out I only have a handful of videos with TrueHD (all 23.976p films in MKVs).

[wanezhiling]

LAV is integrated into KMPlayer 4.0 beta now.

[NikosD]

Does KMPlayer integrates nightly builds, because MPC-HC is far behind latest builds.

[wanezhiling]

No, they only use stable builds.

[sneaker_ger]

About the x264 lossless bug:
I'm sure the FFmpeg developers are open to better auto detection ideas. I wouldn't know how to do something else.
Didn't x264 do some watermarking in otherwise unused bits so the developers can identify x264 encodes even in the absence of the SEI? That was discussed on doom9 some time ago.

[NikosD]

@nevcairiel

When do you think next stable version will be out ? Is there an ETA ?

I think 0.62 is too old now.

[nevcairiel]

Luckily, what you think is of no importance to LAV. :)
Releases come when they are deemed ready, not when you would like them to be.

[NikosD]

Being impolite is your forte, undoubtedly your most strong characteristic, but the whole thing it's not about me or even you (!) - yes there are things in this world that are not around you, but unfortunately they are dependent of you :cool:

It seems that the only way for LAV filters to be updated inside various players that use them, is to release a next stable version.

A lot of people is struggling with slow HEVC decoders and latest nightly build of LAV video, certainly has a serious improvement on that.

It would be useful for the community, not me.

I use nightly builds and don't wait for stable releases.

[nevcairiel]

You know why the latest nightly is so much faster? Because I worked on making it so. It didn't magically happen over night just by itself, you know.

But anyone that thinks he knows whats best, its all open-source, feel free to create your own project!
I'll keep running my project the way I see fit. It works quite well for me.

PS:
MPC-HC doesn't limit itself to release versions.

[fairchild]

Out of curiousity, what is the link to the Lav Filters nightly so I can bookmark it and never ask this again? I know the one for the MPC-HC nightlies is http://nightly.mpc-hc.org/

I usually stick to the stable releases unless some new features are coming, but would be nice to know when I'm feeling frisky and would like to be on the bleeding edge.

Thanks for all your hard work Nev!

[filler56789]

Out of curiousity, what is the link to the Lav Filters nightly so I can bookmark it and never ask this again?

Currently there are ZERO :( sites hosting "the freshest" revisions of LAV.
The last one to die was betaking's VDISK,
last-updated on 2014-June-20:

http://www.vdisk.cn/betaking

[wanezhiling]

The last one to die was betaking's VDISK,
last-updated on 2014-June-20
Betaking is updating his builds here (http://pan.baidu.com/s/1gd1its3#dir/path=%2F%E8%87%AA%E7%BC%96%E8%AF%91%E8%BD%AF%E4%BB%B6).

[filler56789]

Betaking is updating his builds here (http://pan.baidu.com/s/1gd1its3#dir/path=%2F%E8%87%AA%E7%BC%96%E8%AF%91%E8%BD%AF%E4%BB%B6).

Thanks for the up-to-date info :thanks: ---

--- the old bookmark (http://pan.baidu.com/share/link?uk=2214911777&shareid=497331#dir/path=%2F%E8%87%AA%E7%BC%96%E8%AF%91%E8%BD%AF%E4%BB%B6) now leads to a different page.

[NikosD]

You know why the latest nightly is so much faster? Because I worked on making it so. It didn't magically happen over night just by itself, you know.


You worked on something that others did.

You just embedded some code from OpenHEVC project into the LAV filters.

You didn't steal it of course, because it's an open-source fork of FFMpeg, but you didn't write anything.

You just ported to LAV filters, OK that's a job too.

Also it was me that I insisted on that Strongene's decoder was so much faster than LAV video in HEVC due to vectorized code that you took from OpenHEVC.


But anyone that thinks he knows whats best, its all open-source, feel free to create your own project!
I'll keep running my project the way I see fit. It works quite well for me.


That's the main and biggest problem of LAV filters project.
It's on you and only on you.


PS:
MPC-HC doesn't limit itself to release versions.

Which is the last version of nightly LAV filters inside the latest nightly MPC-HC and how long ago that nightly LAV filters version was released ?

[nevcairiel]

You just ported to LAV filters, OK that's a job too.

If you think thats just copy-pasting and done, then you're mistaken. It took the better part of a afternoon doing that, making sure it works and ensuring that the decoder still outputs proper images. The OpenHEVC code does not get merged to main FFmpeg for a reason, because their code doesn't necessarily work in all cases, so it needs a lot of testing to make sure this part works for the cases I need in LAV.


That's the main and biggest problem of LAV filters project.
It's on you and only on you.

You're free to use something else, developed by a whole team, because there are so many developers eager to work for free on DirectShow stuff. Oh wait.


Which is the last version of nightly LAV filters inside the latest nightly MPC-HC and how long ago that nightly LAV filters version was released ?

You'll have to ask them, I don't keep track which versions they use, or for any other project for that matter.


In general you're one of those users that need to realize that I do this in my freetime, and everytime your entitled comments manage to annoy me, I'll go do something else instead, and no development is happening. You should be happy that I work on this for free, in my spare time, instead of demanding and complaining everytime you post.

But of course, you'll just take this as another chance to call me impolite.

[e-t172]

That's the main and biggest problem of LAV filters project.
It's on you and only on you.

LAV is free software. There's nothing stopping you from forking it if you are not pleased with its current leadership.

[NikosD]

I only asked you if there is an ETA for the next stable release.

And yes you' ve been impolite in your answer.

[clsid]

Which is the last version of nightly LAV filters inside the latest nightly MPC-HC and how long ago that nightly LAV filters version was released ?MPC-HC is updated with latest LAV whenever there have been important fixes. This month has been a bit slow because some of the devs have been on vacation! You can see upcoming MPC-HC changes on the personal GitHub pages of the devs. Here is the one that updates to very latest LAV:
https://github.com/Underground78/mpc-hc/commit/4afb5bc9df30f62e658b9a90fbc53555058d9be7

If you want the latest and greatest all the time, you should compile the stuff yourself. It is easy to do.

Hendrik does a great job providing us with high quality software. He gets too many complaints, and too little gratitude.

[jmone]

Hi Nikos,
I've followed the development of LAV with great interest from the very beginning, and to me it is one of the better example of the selflessness that exists in the open source community.

As the project grew so did his skills and reputation in this area... so it was of no surprise when he officially become part of JRiver. They say a "lucky" man, is one whose hobby and job is the same! Good on Hendrik, that he now gets paid to work in the industry he has so passionately supported (and still does) for free.

For me I saw the development of LAV Filters rise from the "complexity" and sporadic development with FFDSHOW, and we now have another (and I think much better) alternative. I'm sure as time passes there will be new efforts that are similarly born to provide an alternative to LAV for (whatever) reason. Maybe you could be such a catalyst for such a new start and run your project as it suits you?

So from me I say "Thanks" to Hendrik for all his work and what he has done over the years. I really appreciate it.....even if at times I may have been also too assertive in championing my pet requirements :)

Kind Regards
Nathan

[foxyshadis]

Removed several off-topic/pointless posts.

[NikosD]

I have more than 20 samples of HEVC .ts files that seem to be recognized as MPEG-2 (!) by LAV Video in DXVA Checker.

They decode fine, though.

A small sample here:
https://www.sendspace.com/file/7c5700

[nevcairiel]

LAV Splitter identifies this as a HEVC stream, otherwise it also wouldn't decode.
I do not know how DXVA Checker works, I suggest asking its author how it determines this wrong information.

[NikosD]

Thanks.

I have already done that and I'm waiting for his reply with more interest, now that I'm sure it's not LAV filters.

You were faster ;)

[ddjmagic]

Is it possible to setup LAV Splitter to only deliver subtitles for a certain language to the player? (so no other subs are shown/selectable in the player)