LAV Filters - DirectShow Media Splitter and Decoders [Archive] - Page 54

Ingram

8th May 2011, 20:09

I'm having an issue with VC-1 content :(

Using PDVD10, I can play VC-1 straight from a BR disc or in a MKV. Problem is that I have a weird video glitch on the very bottom of the frame when doing this. If I use MPC Video Decoder the problem goes away with MKV's but breaks playback from BR disc.

I'm using .25 within Media Portal.

EDIT:

Ok this is odd. I can play VC-1 straight from a bluray using The Dark Knight, but if I try to play a VC-1 extra feature from my Apoclytpo Bluray it doesn't work. Everything loads and seems to be playing, even the disc is spinning, but nothing actually plays.

Glad I tested Dark Knight, now I know it isn't a VC-1 issue but rather a problem with the extra features playing on Apoclypto. But I am confused as to why said feature will work using PDVD10 but not MPCVideoDec?

nevcairiel

8th May 2011, 21:17

I have finally got around to making a plan to compile LAV Filters :)

I see this kind of message when compiling, is this normal? The built files seem to be perfectly fine.

You can ignore those warnings from inside libbluray, all the others are most likely cases where i'm smarter then the compiler and forgot to override it. :p

VipZ

8th May 2011, 21:24

You can ignore those warnings from inside libbluray, all the others are most likely cases where i'm smarter then the compiler and forgot to override it. :p

lol thanks :)

nevcairiel

8th May 2011, 21:34

A wonderful sunday evening, everyone!

I worked on further improving bitstreaming today, and the improvements i made are ready for testing.

http://files.1f0.de/lavf/LAVFilters-0.25-20-g0ee9d6c.zip

Most notable changes:
- Fixed a bug that caused certain audio types to not produce a valid media type, causing connections to fail (most notably 24bit LPCM)
- Using the ffmpeg parser, which should allow bitstreaming to function properly with other splitters (not extensively tested)
- New logic for timestamping bitstreamed (non HD) DTS and AC3, which should resolve some playback issues when not using ReClock.
- Better handling for End Of Stream events, it should no longer "eat" the last audio frame.

I tested all the bitstreaming formats on my HTPC, and did seem all fine, so here goes for you!

SamuriHL

8th May 2011, 22:00

Not sure if I'll get to test it tonight. Should be able to tomorrow for sure. Sounds like a fun improvement. :)

Sebastiii

8th May 2011, 22:38

Massive work again :)
My htpc start to be crasy, i hope that it's because of testing but not my power supply start to be ...... bad.
I didn't made all the test i want :( grrrrr.
Thanks again m8 :)

Xorp

8th May 2011, 22:43

nightfly

9th May 2011, 00:00

Wow this is great, I can finally watch BDs with mono PCM with the LAV audio decoder. That bug has been in MPC-HC for years and the devs seemed incapable of fixing it, but you got it working within few months :)

Yeah, definitely my movie playback experience has jumped forward with using LAV splitter; and simplified setup that LAV audio provides (allowing me to use Reclock is a plus).

Forced subs auto loading I thought I would never get...

Now I can move the dream target to BD menu support as that is the last piece missing from the BD puzzle.

Inspector.Gadget

9th May 2011, 01:06

But I am confused as to why said feature will work using PDVD10 but not MPCVideoDec?

FFMPEG-based Directshow decoders do not yet handle all types of interlaced VC-1 content correctly. PowerDVD's decoder is proprietary and built on a codebase that doesn't have this issue. You can also use the WMVideo Decoder DMO to decode interlaced VC-1 in software or LAVCuvid if you have a supported GPU.

nightfly

9th May 2011, 03:45

Can these updates simply be copied over the existing install without any additional action?

A wonderful sunday evening, everyone!

I worked on further improving bitstreaming today, and the improvements i made are ready for testing.

http://files.1f0.de/lavf/LAVFilters-0.25-20-g0ee9d6c.zip

Most notable changes:
- Fixed a bug that caused certain audio types to not produce a valid media type, causing connections to fail (most notably 24bit LPCM)
- Using the ffmpeg parser, which should allow bitstreaming to function properly with other splitters (not extensively tested)
- New logic for timestamping bitstreamed (non HD) DTS and AC3, which should resolve some playback issues when not using ReClock.
- Better handling for End Of Stream events, it should no longer "eat" the last audio frame.

I tested all the bitstreaming formats on my HTPC, and did seem all fine, so here goes for you!

boyumeow

9th May 2011, 04:22

A reinstall is required if I'm not wrong, suggestion is to uninstall the old ones then install the new ones. Thanks.

nevcairiel

9th May 2011, 07:01

Can these updates simply be copied over the existing install without any additional action?

In general it never hurts to simply run the install script again, but in this case, you could just copy the version over the old one, nothing big changed that would require a new registration. Hints that a new registration is required usually are comments like "Added official support for X", or well, when i directly say to do it. :p

FFMPEG-based Directshow decoders do not yet handle all types of interlaced VC-1 content correctly

To clarify this, ffmpeg does not support VC-1 interlaced *at all*, so the MPC Video Decoder will not output any image for any interlaced VC-1 content.
You can either use ffdshow with VC-1 set to "wmv9", or use the MS decoder directly - or other commercially available decoders.

Ingram

9th May 2011, 07:29

FFMPEG-based Directshow decoders do not yet handle all types of interlaced VC-1 content correctly. PowerDVD's decoder is proprietary and built on a codebase that doesn't have this issue. You can also use the WMVideo Decoder DMO to decode interlaced VC-1 in software or LAVCuvid if you have a supported GPU.

Ah of course now it makes sense! Thanks for clearing that up :)

Andy o

9th May 2011, 08:45

thanks for the updates, nev. Don't think I'm having any troubles nowadays with LAV filters.

Sebastiii

9th May 2011, 09:20

I need power supply, but i have success to start HTPC, so i have make test :) and all is working good :) but i will made more deep test :P

adam777

9th May 2011, 09:26

Hi nevcairiel,
Great seeing the progress being made all the time :thanks:
Unless there are some firm plans for the new version, I would like to kindly remind you the PES streams issue, as discussed here - http://forum.doom9.org/showthread.php?p=1481113#post1481113.
Haven't seen it in the to-do list in the first post.
Thanks again, Adam.

PeQuE

9th May 2011, 10:40

Looking forward to see audio delay feature added to LAV Audio decoder... It's a must in my setup... :(

Thanks!

wo0zy

9th May 2011, 11:55

Hi Nev,

Great work!!! Truly amazing stuff :thanks:

Below is a link to a sample file you might like to test.

http://www.mediafire.com/?1cfjp7h1ao1nwhg

It's a recording of the DVB-T "Radio 5 Live" channel here in the UK made using Mediaportal. As you can see from the attached image it's a 96Kbps, 48KHz, 1-channel stream (whereas most of the DVB-T radio channels here are 192Kbps, 48KHz, 2-channel streams.

Using the Microsoft DTV-DVD decoder the sample plays fine. Using LAV audio decoder the file plays silence (but no error).

A previous version of LAV audio decoder actually played the stream at high speed (chipmunk effect :p) but the latest builds are just silent.

This really is a very minor thing compared to the stuff you've been working on but I thought you might be interested.

All the best,

Wo0zy

nevcairiel

9th May 2011, 12:16

wo0zy

9th May 2011, 12:39

Playback of that file seems fine here. Maybe your audio renderer doesn't like mono tracks? I don't have access to the Microsoft Decoder right now, so i cannot check if it converts it to stereo, but i can do that later when i get home.

Cheers Nev.

I'll have a play in the meantime and see what I can dig up.

All the best,

Wo0zy

Edit: Hmm. Looks like you're right (what a surprise :)). The file works fine if I configure my playback device as 2-channel (stereo) but not when configured as 5.1. This is using analog (I'm testing on a work computer ATM not on an HTPC).

pie1394

9th May 2011, 14:48

Hi nevcairiel,

For the 1440x1080 16:9 MKV content's demuxing, it does not seem compatible with LAVFVideoHelper's handling to setup the video window's target rectangle.

The related code fragments are listed. Can you confirm if this is the root cause why the target window is still 1440x1080 instead of 1920x1080 ? Thanks!

Filter : LAV Splitter - CLSID : {171252A0-8820-4AFE-9DF8-5C92B2D66B04}
Video: MPEG4 Video (H264) 1440x1080 (16:9) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 167

VIDEOINFOHEADER:
rcSource: (0,0)-(1440,1080)
rcTarget: (0,0)-(1440,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

In [demuxer/Demuxers/LAVFVideoHelper.cpp]
VIDEOINFOHEADER *CLAVFVideoHelper::CreateVIH(), I saw this:

pvi->rcTarget.right = pvi->rcSource.right = avstream->codec->width;
pvi->rcTarget.bottom = pvi->rcSource.bottom = avstream->codec->height;

pvi->bmiHeader.biWidth = avstream->codec->width;
pvi->bmiHeader.biHeight = avstream->codec->height;

But in [ffmpeg/libavformat/matroskadec.c] static int matroska_read_header(), I saw this:

if (track->type == MATROSKA_TRACK_TYPE_VIDEO) {
st->codec->codec_type = AVMEDIA_TYPE_VIDEO;
st->codec->codec_tag = track->video.fourcc;
st->codec->width = track->video.pixel_width;
st->codec->height = track->video.pixel_height;

Yet such 1440x1080 16:9 is encoded with:

track->video.display_width = 1920
track->video.display_height = 1080
track->video.pixel_width = 1440
track->video.pixel_height = 1080

nevcairiel

9th May 2011, 14:58

You left out all the important parts..

in ffmpegs matroskadec.c

av_reduce(&st->sample_aspect_ratio.num,
&st->sample_aspect_ratio.den,
st->codec->height * track->video.display_width,
st->codec-> width * track->video.display_height,
255);

which sets stream->sample_aspect_ratio

and LAVFVideoHelper.cpp

// Calculate aspect ratio
AVRational r = avstream->sample_aspect_ratio;
AVRational rc = avstream->codec->sample_aspect_ratio;
int num = vih->bmiHeader.biWidth, den = vih->bmiHeader.biHeight;
if (r.den > 0 && r.num > 0 && (r.den > 1 || r.num > 1)) {
av_reduce(&num, &den, (int64_t)r.num * num, (int64_t)r.den * den, 255);
} else if (rc.den > 0 && rc.num > 0 && (rc.den > 1 || rc.num > 1)) {
av_reduce(&num, &den, (int64_t)rc.num * num, (int64_t)rc.den * den, 255);
}
vih2->dwPictAspectRatioX = num;
vih2->dwPictAspectRatioY = den;

Of course you forgot to post the Aspect Ratio information form your media type....

Anyhow, rcSource/rcTarget are not used like that by video decoders (or renderes, for that matter, they should contain the actual pixels that should be shown) - they should read the aspect ratio flags, and stretch the target rectangle accordingly to match it.

If these flags are set properly (which i think they are), i would bet your video decoder manages to overwrite them, possibly with a value from the bitstream, which is set to something wrong (1:1?). I know that CoreAVC, for example, always overwrites flags provided by the source filter, MPC-HC (i think?), ffdshow and LAV CUVID have options if the AR set in the bitstream should be used. No idea about the commercial decoders, most seem to always use the AR from the source filter..?

Anyhow, please check the AR info in the media type, and check the output media type from your decoder, i bet the decoder somehow manages to "drop" the information along the way - either due to a bug, or just because it thinks reading the AR from stream is better (like CoreAVC does)

Edit:
I just saw the info i was looking for

Video: MPEG4 Video (H264) 1440x1080 (16:9) 23.98fps
There it is. It does set the AR properly, and 1440x1080 at 16:9 is 1920x1080 - i'm 100% sure now that info vanishes after your decoder, resulting in playback at 1440x1080

Ingram

9th May 2011, 17:52

SamuriHL

9th May 2011, 17:56

LAV Audio doesn't connect to the MS DVD navigator right now I believe.

nevcairiel

9th May 2011, 18:49

Here is a new bitstreaming test build.

This build introduces new timing logic for TrueHD and DTS-HD - for one it should resolve a minimal sync issue of about 20ms for TrueHD (not that anyone noticed 20ms, ffdshow suffers from the same problem, btw), and its just more "correct" - dumping the outgoing frames looks actually sane now.
DTS-HD timings should be somewhat independent of the source filters timestamps now, while TrueHD still relys on the sources timestamps, but should deal a bit better with weird timing situations.

Anyhow, i would appreciate if you guys can give this some testing on those two HD formats, and see if something broke, looking at A/V sync and all the usual suspects.

http://files.1f0.de/lavf/LAVFilters-0.25-22-g9f7db6b.zip

Next up is DD+ timings, its still the worst in the lot, playing without ReClock produces terrible clock jitter...

* All comments above only apply to bitstreaming, in case that wasn't clear.

wo0zy

9th May 2011, 18:58

Is LavAudio meant to work with DVDs?

I tell MediaPortal to use LAVAudio for DVD Discs/Images, when I go to play a DVD it will load LAVAudio but ignore it and load FFDShow Audio instead to handle the audio?

Not a huge issue as I've now set MP to use MPC - MPA with bitsreaming configured.

I had the same problem earlier. Went back into MP configuration, reselected LAV audio and now it works. Will find out in the morning if the setting holds.

Wo0zy

nlnl

9th May 2011, 19:16

SamuriHL

9th May 2011, 19:17

DTS-HD MA is smooth as silk, man. Even skipping back and forth between chapters it's like butter. :) I'll test out TrueHD next.

SamuriHL

9th May 2011, 19:23

I'm not sure TrueHD is 100% for me. Only tested on one MKV right now, but, it does something weird. When first making the connection, and sometimes when chapter skipping (dropping/reconnecting), it starts, then quickly drops/reconnects a second or two later. Then it's fine. I don't even really know how to describe this problem correctly other than what I stated. It connects....plays for a second or two....then drops/reconnects and then plays fine if I leave it alone.

nevcairiel

9th May 2011, 19:26

nevcairiel
Thanks once again for the great LAV!

Can not play FLAC in mkv if the chain is LAV audio+ LAV splitter + Reclock, but LAV audio+ LAV splitter + System renderer is OK.

Below is a link to a sample file
http://www.multiupload.com/YY0JADXPOF

Thats weird, it connects FLAC directly to ReClock.. apparently it wants to bitstream it.

Don't know if i can fix it - turn off bitstreaming in reclock. :p

nevcairiel

9th May 2011, 19:28

SamuriHL

9th May 2011, 19:31

The old version didn't do that? Can you double check?

No it didn't. I'm using the same 2 files to test all the bitstreaming stuff for DTS-HD MA and TrueHD. DD+ seems fine. It only happened with TrueHD. Odd. Lemme find another file and see if it happens there. TrueHD is becoming rarer and rarer these days.

SamuriHL

9th May 2011, 19:34

I see what's happening now. Damnit. I need to pay attention. It's happening when madVR switches back to exclusive mode. Seems to slightly interrupt the TrueHD track. Doesn't seem to happen when doing other formats though. Freaking odd. But yea, it's happening on other TrueHD files, as well.

EDIT: No, i'm wrong. It's happening slightly before the transition to exclusive mode. However, it's *EXACTLY* like those little pauses/interruptions I was getting on Dreamworks discs. It's almost imperceptible unless you're looking for it. But it's this tiny little dropout for a split second and then everything's fine. It's happening on 3 of the TrueHD MKV's I have. I haven't checked an actual BD itself. Don't really have time to do that at the very moment but can if you think it's important. Should be noted that the Dreamworks pauses were happening on the disc. These are happening in an MKV. Same symptom though. Very slight drop right after the connection is made.

nevcairiel

9th May 2011, 19:44

It still doesn't happen with the old version, right?
Its still odd, though. There is no real reason for this.

SamuriHL

9th May 2011, 19:45

No. But, you can shoot me if you want. I forgot I had ReClock in the chain. In MPC-HC I don't and it's not happening there. So this seems like an interaction with ReClock. I'm removing ReClock from the chain in MC16 and will retest.

SamuriHL

9th May 2011, 19:47

Yea, that's it. ReClock interaction. Otherwise it's flawless.

nevcairiel

9th May 2011, 19:47

As long as tests on both new and old version are in the same environment, any regressions are worth noting.

SamuriHL

9th May 2011, 19:52

nevcairiel

9th May 2011, 19:55

Sounds like ReClock is repeating an audio frame, for whatever reason.

SamuriHL

9th May 2011, 19:58

Yea it's possible. I'm not too concerned, but, I'm wondering if that's the source of the Dreamworks disc issues, too. I'll have to mess with that when I have time. It sucks cause the *ONLY* reason I'm using ReClock is because I want exclusive mode for PCM. And MC16's exclusive mode doesn't work for me when bitstreaming other audio types. So, I either get everything mostly working or I lose exclusive mode on PCM which means it goes through Windows Audio and potentially botches the channels. LAV Audio really needs to learn to bitstream PCM! ;)

nlnl

9th May 2011, 20:12

Thats weird, it connects FLAC directly to ReClock.. apparently it wants to bitstream it.

Don't know if i can fix it - turn off bitstreaming in reclock. :p

OK Thanks!

High time to start developing LAV Audio Renderer ;) ?

nevcairiel

9th May 2011, 20:19

Yea, it's kinda there in a build from a few days ago. But it's slightly different which is why I missed it before. The new version literally drops the connection at some points when seeking and reconnecting. The old version doesn't ever seem to drop the connection, but, there's still a little pause there. Doesn't happen when ReClock isn't in the chain on either version.

I cannot get it to drop the connection in any case, nor hear any difference - both seem to repeat one sample shortly after connection, must be a ReClock thing or something.

The old version works just like the new .. one repeated sample shortly after connection
Sometimes i don't hear it because it repeats another sample thats not as noisy, but reclock stats say the same.

SamuriHL

9th May 2011, 20:20

I cannot get it to drop the connection in any case, nor hear any difference - both seem to repeat one sample shortly after connection, must be a ReClock thing or something.

The old version works just like the new .. one repeated sample shortly after connection..

I'm not sure why my receiver is treating it differently. Meh. Nothing for you to worry about. Except, like I said, allow me to get ReClock out of my way and we can all move on. :D

nevcairiel

9th May 2011, 20:26

I'm not sure why my receiver is treating it differently. Meh. Nothing for you to worry about. Except, like I said, allow me to get ReClock out of my way and we can all move on. :D

I also always get a reconnection on seeks. I can possibly try to avoid that by not flushing the audio renderer, but not sure if that has any funny side-effects.. (probably does)

Bitstreaming will always have some down sides, i don't feel like recommending it to people when decoding is a viable alternative.
I'm currently only bitstreaming because i'm testing the setup, once i'm convinced it all works fine, i'll switch back to decoding. ;)

SamuriHL

9th May 2011, 20:41

I also always get a reconnection on seeks. I can possibly try to avoid that by not flushing the audio renderer, but not sure if that has any funny side-effects.. (probably does)

Bitstreaming will always have some down sides, i don't feel like recommending it to people when decoding is a viable alternative.
I'm currently only bitstreaming because i'm testing the setup, once i'm convinced it all works fine, i'll switch back to decoding. ;)

Ok, I'll bite. :) That's fine to say you want to decode everything. I have no problem with that at all. However, that makes the problem I'm talking about even worse! :D EVERYTHING becomes PCM, right? So now you've got a multitude of PCM tracks with multiple sample rates, bit depth, and channels. So then you send that through Windows Audio and MAYBE you get untouched sound from that. Or maybe it resamples it based upon the settings you choose. And maybe it decides since you have 5.1 or 7.1 set in Windows Audio that you're always going to get that sent to the receiver. That's not good for some of us. :) Even if we're decoding on the PC side of this equation, we still want the receiver to deal with that decoded track as though it was bitstreamed. The receiver can deal with channel mapping (5.1->7.1, etc). Guaranteed no resampling. My point is, don't pretend that the "simple" act of decoding solves all the problems of bitstreaming. Far from it. It introduces a new set of challenges.

Ok, I'll get off my soapbox now. :D However, I really do want exclusive mode for PCM. I really truly hate Windows Audio.

nevcairiel

9th May 2011, 21:01

No problems i know of using ReClock for WASAPI'ing PCM - remember ReClock was designed for PCM. Even if you don't want ReClock touching the audio and doing its magic, its still good.

Doesn't the MC16 renderer also have an exclusive mode?

WASAPI exclusive mode is basically untouched audio, its the DirectSound mixer that damages it.

SamuriHL

9th May 2011, 21:19

Right, I understand that. Yes, MC16 has exclusive mode, so, if I decided to go exclusively back to decoding I could probably make it work. I might look into it. If I use exclusive mode in MC16 it breaks bitstreaming. Booo. :D Ideally what I've liked in the past, and why ReClock even allows this btw ;), is to use bitstreaming for TrueHD/DTS-HD MA and ReClock exclusive mode for PCM. Best of both worlds.

nevcairiel

9th May 2011, 21:21

I don't understand your problem then. There are solutions for full decoding (DTS(-HD) & E-AC3 with ArcSoft, everything else with LAV Audio), no need for bitstreaming if you want to go that way (even works with the MC16 renderer). Or if you want to bitstream only some formats, ReClock can do this too, while keeping exclusive PCM.

I must be missing something.

SamuriHL

9th May 2011, 21:26

Yea, I could go the decoding route if I wanted to. I personally like letting my receiver do most of the work. However, I have PCM BD's which are where my issue come in. That's the ONLY place I have a problem if I choose to bitstream. Everything else is perfectly fine. However, things like Kill Bill are 5.1 48/16 PCM. So if I have it setup for bitstreaming, clearly I'm using DirectSound renderer to make that work and I don't get exclusive mode for PCM. ReClock solved that issue for me quite a while ago. So that I could bitstream AND get exclusive mode PCM. It still works. Just with that weird issue with TrueHD. Meh. I'm not overly concerned. It works. :) That's why I asked James to implement the bitstreaming passthrough to begin with.