LAV Filters - DirectShow Media Splitter and Decoders

[egur]

Lady Gaga clip has been fixed :)
But this one (http://www.mediafire.com/?bp5hqy5sbmsrbmr) fails. The old behavior exists (no PPS for you).

MPC splitter

00 1b 67 4d 40 28 89 99 //SPS
80 f0 08 8b 01 f7 01 01
01 f0 00 00 03 00 10 00
00 03 03 29 40 00 04 68 //PPS
ea 8f 20

LAV splitter 0.51.2 and last test build

00 1b 67 4d 40 28 89 99 //SPS
80 f0 08 8b 01 f7 01 01
01 f0 00 00 03 00 10 00
00 03 03 29 40 //No PPS


Edit I'll went through my entire H264 test suite and the rest are clean.

[nevcairiel]

I added some more NALUs to parse through to the list, which now causes it to find the PPS in that file as well.

I still think however since the SPS/PPS are coming in-band with the stream anyway, the decoder should not completely bail out when they are not present.
I could decide to send the stream untouched as AnnexB, which does not even mandate the presence of the sequence headers in the media type.
As long as the SPS is present, you can already use that to detect the compat with the decoder, the PPS holds no information to that end.

[egur]

I added some more NALUs to parse through to the list, which now causes it to find the PPS in that file as well.

I still think however since the SPS/PPS are coming in-band with the stream anyway, the decoder should not completely bail out when they are not present.
I could decide to send the stream untouched as AnnexB, which does not even mandate the presence of the sequence headers in the media type.
As long as the SPS is present, you can already use that to detect the compat with the decoder, the PPS holds no information to that end.

True, I changed my code not to bail out anymore. For now I take the info from the VIDEOINFORHEADER. I may need to add sequence header parsing... To do this for all codecs is a lot of work.
What about a workaround - change the SPS to a one that's not accompanied by a PPS. Do you thing that will work?

[nevcairiel]

True, I changed my code not to bail out anymore. For now I take the info from the VIDEOINFORHEADER. I may need to add sequence header parsing... To do this for all codecs is a lot of work.

"all codecs"? :)
VC-1 is essentially always hardware compatible.
MPEG-2 only needs to check if its 4:2:2 and refuse in that case.

The only somewhat complicated codec is H264.
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=decoder/LAVVideo/parsers/H264SequenceParser.cpp;hb=HEAD#l70

Not that i particularly care, i already implement my own compat check in LAVs QuickSync wrapper (using the class above)


What about a workaround - change the SPS to a one that's not accompanied by a PPS. Do you thing that will work?
I would not change the data, it needs to match the stream or bad things happen.

[egur]

"all codecs"? :)
VC-1 is essentially always hardware compatible.
MPEG-2 only needs to check if its 4:2:2 and refuse in that case.

The only somewhat complicated codec is H264.
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=blob;f=decoder/LAVVideo/parsers/H264SequenceParser.cpp;hb=HEAD#l70

Not that i particularly care, i already implement my own compat check in LAVs QuickSync wrapper (using the class above)


I would not change the data, it needs to match the stream or bad things happen.

VC1 - you're right today - although last generation of drivers didn't support main/simple profiles.
MPEG2 - check for 4:2:2 and 10bit.
H264 - parse complex SPS header, plenty of reference code to look at (including yours).
Media SDK now supports MJPEG (currently in SW only), who knows what's next...

BTW, I want to implement outputting DXVA surfaces directly.
Maybe I'll add an option to output a copy of the original surface for rendering subtitles directly in GPU space.
The design should not change much except that I'll need to allocate extra surfaces for renderer queues.

Any requests/requirements/suggestions?

[aufkrawall]

nev, what do you think of a WMV3 (not VC-1) "fallback" to DXVA2 CB when using CUVID? :)

[nevcairiel]

nev, what do you think of a WMV3 (not VC-1) "fallback" to DXVA2 CB when using CUVID? :)

In the long term, i'll be trying to do two things:
- An advanced mode which allows you to select one hw accel per codec
- A "automatic" mode which trys to use the best hwaccel available. Try to use DXVA Native, fallback to CB/CUVID, maybe something like that. Not sure how it'll function yet.

I don't plan on any intermediate hidden logic hacks.

[pankov]

nev,
when you design this fallback functionality please allow the user to select the fallback order.
Personally, I have both quicksync and CUVID options and I prefer the quicksync one as a fallback from DXVA native before going to software mode.
I think this could be accomplished by using a user reordable listbox ... or a combobox (dropdown listbox) with small arrow icons in front of each item. I'm using Delphi and there are a lot of nice components for this but I'm not familiar with Visual Studio so I hope it's not much harder

[nevcairiel]

The automatic mode will be fully automatic, no user configuration.
If it detects an Intel GPU as the primary GPU, it will most likely never try anything but QuickSync, because the DXVA implementation just doesn't agree with it in many cases.
If your primary GPU is NVIDIA, and DXVA Native fails, it'll most likely prefer CUVID because its IMHO more stable/reliable then QuickSync (even though not as fast)

How the advanced mode will look and what flexibility it'll offer regarding configuration, i cannot say yet.

[mzso]

If I use LAV video (with cuvid) to decode videos with madVR is it better to have RGB output Levels at PC or Untouched?

Also a noob question what does the (un)checking the output formats do? What even determines which output format is used?

[mr.duck]

Also a noob question what does the (un)checking the output formats do? What even determines which output format is used?
Just leave them all ticked. You could untick some if you wanted to force it to use a specific output format. But that may require some color space conversion.

[nevcairiel]

If I use LAV video (with cuvid) to decode videos with madVR is it better to have RGB output Levels at PC or Untouched?

This option has no effect if you use madVR and don't untick everything but RGB.


Also a noob question what does the (un)checking the output formats do? What even determines which output format is used?
The output format best matching the video is used. Some formats carry exactly the same information in other memory layouts, for compat with other software, thats why its so many.

If you disable some, you may force (lossy) conversions to other formats. In best case it will only be slower, in worst case it has to do a conversion that modifies the data and loses data.

[Jasch]

I have noticed a small "bug" .
I use Lavfilter (Video and audio)in DVBviewer.
Since version 51 when you switch to a channel with dif. Resolution(720p to 1080i, or other way).
Your hear only the new channel audio for 2s(standpicture from old channel) then audio goes off,picture black, and then it plays new stream.
Before 51 this was working, i found out it must be lavaudio.
When i use 51.2 Video and ffdshow audio, then its working.

If you need more infos, tell me what you need.

MFG Alex

[CiNcH]

I have noticed a small "bug" .
I use Lavfilter (Video and audio)in DVBviewer.
Since version 51 when you switch to a channel with dif. Resolution(720p to 1080i, or other way).
Your hear only the new channel audio for 2s(standpicture from old channel) then audio goes off,picture black, and then it plays new stream.
Before 51 this was working, i found out it must be lavaudio.
When i use 51.2 Video and ffdshow audio, then its working.

If you need more infos, tell me what you need.

MFG Alex
I also experienced some problems with LAV Audio in this matter but did not analyze it further. I switched to ffdshow again. I may have a look at that this evening.

[nevcairiel]

Nothing in LAV Audio has changed that would explain any of this, not since 0.50.5 anyway.
Any more details would be appreciated.

It does sound like its receiving Audio for the new channel without proper timestamps, which means it'll continue to output with the old-channels timestamps (or starting from 0, depending on what DVBViewer sends), and then it gets a timestamp and starts from there - causing the gap. I'll try to see if i can reproduce any of this, but my selection of DVB channels is severly limited because i refuse to pay for them (and thus only have a handful of free channels)

[Jasch]

You can try it with on of the ARD/ZDF channels (720p), and switch to Servus TV HD(1080i).
All Free to Air.

MFG Alex

[nevcairiel]

Servus TV HD(1080i) is encrypted.

Anyway, the issue can also be reproduced when switching from a SD to a HD channel, however, i see nothing wrong in LAVs behaviour.

Assuming i'm on the SD channel, and switch to HD, here is what happens:
- DVB Viewer destroys LAV Audio and re-creates it
- LAV Audio starts receiving audio data and happily decodes away
- After around 4.9 seconds of audio, DVB viewer sends a "NewSegment" call
- The NewSegment re-sets timestamps, and causes video to start
- Because of the timestamp re-set, there is the gap in the audio

On my side, everything looks fine, DVBViewer is just behaving rather oddly, it sends audio long before video starts, and then it sends another NewSegment when the video starts running.
You're right however that the problem does not occur with ffdshow for audio, which seems truely odd. Maybe i can find something out.

Edit:
After some looking around, somehow i think DVBViewer behaves differently when it knows its using ffdshow. I added a lot of debug messages to ffdshow, and it doesn't get the audio packets that LAV gets, thus not having the problem.
Maybe talk to the DVBViewer people? From my side, i can only say that DVB Viewer shouldn't be sending audio when its not ready to send video as well, and it appears it doesn't do so when using ffdshow.

[CiNcH]

What I can see is that Queued Video Buffers count up in DVBSource until an overflow occurs. DVBViewer reacts with a graph stop/run to that. On 720p video runs in slow motion afterwards, and Queued Video Buffers always count up again until the buffer overflow occurs. So either DVBSource does not forward the video buffers or LAV does not get them from DVBSource.

[nevcairiel]

But that doesn't make any sense.
I see that LAV Video is getting some video, maybe ~20 packets 8192 bytes each, then it sends about the same amount of audio packets, and then it overflows already.

Any reasons for this i can come up with don't make any sense, because it starts working after the graph reset.

[nevcairiel]

Hm i found the commit that caused the problem, but i am totally puzzled why. I'll look into it.

[CiNcH]

Which one is it?

[nevcairiel]

Which one is it?

This one:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=commit;h=694db46060d6009bcb4d289c37d62178a2dd520b

My guess is that it somehow manages to screw something up in the DVBSource, but why, i cannot say. I read the code 3 times, and it shouldn't have any bad side effects .. in theory anyway.

I isolated it to the part of the code that enumerates over the media types of the DVB Source Filter, something must break inside of it when i try doing that.

[nevcairiel]

Try this version, it hopefully fixes it:
http://files.1f0.de/lavf/LAVFilters-0.51.2-5-g1d249b3.zip

[CiNcH]

Try this version, it hopefully fixes it:
It does :) . Thanks.

[Jasch]

Servus TV HD(1080i) is encrypted.

Sorry, but this is not true.

Die Ausstrahlung von ServusTV via Satellit erfolgt unverschlüsselt. Besondere Voraussetzungen wie z.B. Smart Cards gibt es nicht. Zum Empfang benötigen Sie daher nur eine digitale Satellitenanlage mit entsprechendem Empfänger.

Zusätzlich zur Verbreitung in der gängigen Standardauflösung können Sie ServusTV auch im hochauflösenden HD-Standard empfangen. Dazu benötigen Sie einen HD-tauglichen Satellitenempfänger sowie ein HD-fähiges TV-Gerät (nahezu sämtliche heute erhältlichen Flachbild-Fernseher unterstützen HD).


Big thx, your new Version solved the Problem.

Mfg Alex

[CiNcH]

Sorry, but this is not true.
Guess that nev is talking about DVB-C...

[nevcairiel]

Guess that nev is talking about DVB-C...

Yes, i am. Everything thats not ARD/ZDF/NDR/etc is encrypted. :p
I don't usually watch TV, so why would i have a satellite dish. Can't avoid the cable that comes with the rent :p

[CiNcH]

I don't usually watch TV, so why would i have a satellite dish. Can't avoid the cable that comes with the rent
But you still seem to have a DVB-C card for PC ;) .

[nevcairiel]

But you still seem to have a DVB-C card for PC ;) .

Its some cheap USB thingy i got for testing DVB applications with LAV, actually. :D
Also does DVB-T. :p

[CiNcH]

If you need something concerning DVB for PC, just tell me... Got some connections there...

[nevcairiel]

For the little TV i do watch, i have a T-Entertain box.... :) Other then for testing, i don't use DVB

[mastrboy]

This one:
http://git.1f0.de/gitweb?p=lavfsplitter.git;a=commit;h=694db46060d6009bcb4d289c37d62178a2dd520b
I read the code 3 times, and it shouldn't have any bad side effects .. in theory anyway.


It's not always the codes fault, we once had a issue which only occurred when compiled with a AMD cpu, some issue with the visual studio 2005 compiler and AMD cpu's which was solved by a hotfix from ms, scratched our heads for weeks trying to figure it out. :P

[Jasch]

Oh sorry didint rec. this.
So i take all back.

But maybe you can give me another little Hand.
I have some BD´s which are 24fps(not 23,976fps, mostly german or asian Productions).
Lavsplitter reports them as 23,999Fps which is not really wrong.(MPC splitter reports 24Fps).
But i use a tool which switches my Refreshrate according to the input.
But this can only read integer numbers.
So it would be nice if lavsplitter would output this as 24fps.

MFG Alex

[nevcairiel]

FPS are not reported in that way in DirectShow. What is reported is the average time per frame, which for 24fps should be 1/24, or 41.666666667ms. Since this is such a odd number (the 6 is a period), rounding errors happen quite easily. 41.6667 for example will already result in 23.9999. 41.6667 is the number LAV should report for such files.

[nevcairiel]

LAV Filters 0.51.3

LAV Splitter
- Further improved H264 media type creation

LAV Audio
- Fixed an issue with the initial media types causing graph building failures in some situations
- Fixed a bug with DVBViewer which caused a delay on channel changes


Download: Installer (both x86/x64) (http://files.1f0.de/lavf/LAVFilters-0.51.3.exe) -- Zips: 32-bit (http://files.1f0.de/lavf/LAVFilters-0.51.3.zip) & 64-bit (http://files.1f0.de/lavf/LAVFilters-0.51.3-x64.zip)

If you missed the 0.51 release, here are the release notes again:
http://forum.doom9.org/showthread.php?p=1581869#post1581869

Another set of bug fixes and enhancements. 0.51 seems especially bumpy, it was just too long a break between 0.50 and 0.51, too many small things sneaked in.
Anyway, another regression fixed, and some other enhancements/fixes added.

As always, have fun

[Jasch]

When i play this with MPC-HC und using the internal display.
it is reporting 23.976 = 41.708 ms
and for this type 24.00 = 41.667 ms .

Its only a "beautyerror".(24fps are realy rare)
I also asked the Prog. of the Hz Plugin for Dvbviewer, maybe he can change the reading from 23 24 to 23,97 23,99.

MFG Alex

[magic144]

thankyou nev!

[Sebastiii]

Try this version, it hopefully fixes it:
http://files.1f0.de/lavf/LAVFilters-0.51.2-5-g1d249b3.zip

Hi Nevcairiel :)
I can't test myself, i'm on holiday :P
Do you think it can impact MediaPortal too ?
It seems you look the process to fix it right ?
Thankss for all.

[nevcairiel]

It seems you look the process to fix it right ?


No, the initial fix was without the process name. I just added it afterwards to avoid any other potential issues later on.

[red5goahead]

I'm very impressed about new mixing features. It's usefull the application I'm develping for Italiansubs.net community
(https://sourceforge.net/p/vss-itasa,
a LavAudioSettingsInterface.pas and LavVideoSettingsInterface.pas interfaces files for Delphi are in the trunk).
I would be nice if you add in the next versions a simple volume setup for all channels (5.1, 6.1 and so on) because I should mute all channels except for the center one when I have to extract a peak file to display a showing wave form .
I think could be usefull for all player or mediacenter that use lav codec interactively.
:thanks:

[Sebastiii]

No, the initial fix was without the process name. I just added it afterwards to avoid any other potential issues later on.

Ok thanks :)

[DragonQ]

Looking forward to seeing how people get on with 0.51.3. I've had no issues with 0.51.2 but the TV related issues have prevented me from upgrade on my HTPC so far (still running 0.50.5).

Yes, i am. Everything thats not ARD/ZDF/NDR/etc is encrypted. :p
I don't usually watch TV, so why would i have a satellite dish. Can't avoid the cable that comes with the rent :p
DVB-C cards are essentially useless in the UK and almost no TVs have DVB-C tuners. This is because there is no free cable TV system (unlike satellite and terrestrial) - you have to sign up to Virgin Media to get it, and they provide a box (rental only) and mandate its usage. Even then, all of the channels except the PSB ones are encrypted so a tuner is useless without an appropriate CAM.

Is the system in Germany more similar to the US where you can get free basic cable?

[egur]

Committed r64 of the QuickSync decoder:

v0.37:
* Better handling of incomplete sequence headers.
* Able to recover after multiple initializations. New stream must be from the same codec as the old stream. Calling InitDecoder or SetConfig will reset the decoder. InitiDecoder must be called after SetConfig (same as before).

[nevcairiel]

Is the system in Germany more similar to the US where you can get free basic cable?

Around here a lot of rented apartments come with cable, but its not "free", you just pay for your share of the central line to the building through the rent. The "free" part is also only Analog and the state-funded channels in Digital/HD. If you want everything else in Digital and HD, you need to pay for a decoder card. For me it would be "just" 3€ per month for the digital package (no HD), and 10€ a month for the HD package.

Cable isn't the best source of HD TV around here though, there is a lot of drama between the cable provider and the stations, which results in not all HD channels being available through Cable.

Personally, i have a IPTV box from my ISP, which works quite nice - eventhough i mostly got that contract because it comes with an unlimited 50/10 connection ;)

[sneaker_ger]

Personally, i have a IPTV box from my ISP, which works quite nice - eventhough i mostly got that contract because it comes with an unlimited 50/10 connection ;)

Even in the non-TV contracts the limit is only on paper. Or get a reseller without any limit in the contract. (Just in case you didn't know, but you probably do, don't you?)

[nevcairiel]

Even in the non-TV contracts the limit is only on paper. Or get a reseller without any limit in the contract. (Just in case you didn't know, but you probably do, don't you?)

I don't like the resellers, they are usually known for over-booking their lines and causing problems in peak hours. Heard too many reports from friends and colleagues about those..

Regarding the contract, well, there is a limit in there after which they claim to throttle me, but i never had such a contract, so i cannot say if they actually do it (nor do i know anyone that does). But i'm also pretty happy with the IPTV, not that i use it a lot, but shrug.

[sneaker_ger]

I don't like the resellers, they are usually known for over-booking their lines and causing problems in peak hours. Heard too many reports from friends and colleagues about those..

Resellers are called resellers because they just .. eh ... resell. Exactly the same overbooking as your "premium contract".

Regarding the contract, well, there is a limit in there after which they claim to throttle me, but i never had such a contract, so i cannot say if they actually do it (nor do i know anyone that does). But i'm also pretty happy with the IPTV, not that i use it a lot, but shrug.

They never ever throttled. Last year someone sued them because the throttling was "too hidden" in the contracts and in court Telekom lawyers argued that it wouldn't matter because they never activated the throttle.
(But if you want the IPTV it doesn't really matter for you, of course. New FTTH contracts also have a throttling clause even for IPTV users, btw.)

Ok, enough off-topic:
Could you add mono down-mixing?

[nevcairiel]

Resellers are called resellers because they just .. eh ... resell. Exactly the same overbooking as your "premium contract".

The problem is that they buy a certain amount of bandwidth from the Telekom, and then over-sell that. Has been some years since i looked into that, but i doubt it changed much.
I prefer to trust a ISP with its own infrastructure, over some company making money on someone elses.

But moving on.

Could you add mono down-mixing?
I guess so, not sure what real-world purpose that really serves though.

Have to check if the matrix handling can properly deal with it, not sure if its too happy mixing surrounds into a center.

[robpdotcom]

Hey Nev,

Probably a long shot, but might as well ask: Would you consider adding support for TiVo files to the splitter? Currently, they can be moved from the DVR to the pc, but can only be played through WMP (or by converting to another container).

To play them in WMP, you need TiVo Desktop software (free). I can provide samples if needed

[nevcairiel]

TiVo files are encrypted, supporting this would be kinda hard.