Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th November 2016, 09:10   #21321  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Nev, another issue with LAV Splitter that baffles me ^^;
It has to do with matroska and aspect ratio.
Sample: http://videoff7.free.fr/wrongAR_sample.mkv
Display width of the video track is set to: 704x528 (4/3)
With Haali Splitter, it displays properly at 4/3.
With LAV, it's wrong (16/9) and video resolution is reported as 704x400.
It seems LAV Splitter isn't taking into account the display width that was set for the video track?
Again for this test, only the splitter is altered in the whole decoding chain.
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 28th November 2016, 09:18   #21322  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
There is a difference between two aspect ratio values reported by MediaInfo:

Code:
Width                                    : 704
Width                                    : 704 pixels
Height                                   : 400
Height                                   : 400 pixels
Sampled_Width                            : 704
Sampled_Height                           : 400
Pixel aspect ratio                       : 0.758
Original pixel aspect ratio              : 1.000
Display aspect ratio                     : 1.333
Display aspect ratio                     : 4:3
Original display aspect ratio            : 1.760
Original display aspect ratio            : 16:9
Respecting the "Original ..." flags is not desired here, correct?

Just to check all possible reasons: Is your LAV Filters set up to prefer container or content AR flags? – But the container has no AR flag reported in MediaInfo. So the content AR should be the only relevant.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 28th November 2016 at 09:25.
LigH is offline   Reply With Quote
Old 28th November 2016, 09:31   #21323  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Works fine for me, plays as 704x528. Note that ultimately its up to the video decoder to use an aspect ratio, and if you use other decoders then LAV Video, there is no telling what aspect ratio information they use, so if anything you would have to ask them. LAV Video prefers the container AR when its set and valid.
Haali does some evil hackery and actually overwrites the aspect ratio inside the h264 bitstream so it may work with more video decoders - but i'm not in the business of evil hackery.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 09:34   #21324  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by LigH View Post
There is a difference between two aspect ratio values reported by MediaInfo:

Code:
Width                                    : 704
Width                                    : 704 pixels
Height                                   : 400
Height                                   : 400 pixels
Sampled_Width                            : 704
Sampled_Height                           : 400
Pixel aspect ratio                       : 0.758
Original pixel aspect ratio              : 1.000
Display aspect ratio                     : 1.333
Display aspect ratio                     : 4:3
Original display aspect ratio            : 1.760
Original display aspect ratio            : 16:9
Respecting the "Original ..." flags is not desired here, correct?

Just to check all possible reasons: Is your LAV Filters set up to prefer container or content AR flags? – But the container has no AR flag reported in MediaInfo. So the content AR should be the only relevant.
Yes, the original (encode) ratio isn't desired here.
And I don't see any AR setting in LAV Splitter 0.68.1..
With Haali, the video AR source is reported as 704x528, with LAV it's 704x400..
I'm using ffdshow to decode the video stream (but that shouldn't make any difference?)
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 28th November 2016, 09:41   #21325  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by nevcairiel View Post
Works fine for me, plays as 704x528. Note that ultimately its up to the video decoder to use an aspect ratio, and if you use other decoders then LAV Video, there is no telling what aspect ratio information they use, so if anything you would have to ask them. LAV Video prefers the container AR when its set and valid.
Haali does some evil hackery and actually overwrites the aspect ratio inside the h264 bitstream so it may work with more video decoders - but i'm not in the business of evil hackery.
Ah yes, with LAV Video dec, the AR is correct.
It's still strange, with Haali + ffdshow, ffdshow is indeed using the container AR.
But with LAV + ffdshow, ffdshow doesn't..?
(the stream is divx5 so i don't think Haali does anything evil ^^
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 28th November 2016, 15:32   #21326  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Use LAV Video and everything works fine. Or fix ffdshow. Its the decoders job to pick an appropriate aspect ratio, my decoder does so. There is nothing else to do. And Yes, Haali does quite a bunch of evil things to work around broken things like ffdshow, which was one of the key ideas I started on - not to repeat those.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 15:32   #21327  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by sneaker_ger View Post
Is the latest nightly (.37) supposed to work with HDR from Matroska/WebM? Doesn't seem to be triggering madVR's HDR mode for me.
The next nightly (ie. tomorrows) should support those streams.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 16:43   #21328  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Great, thank you. Will it prefer container or bitstream (e.g. HEVC) or are both passed on and the renderer decides?
sneaker_ger is offline   Reply With Quote
Old 28th November 2016, 16:57   #21329  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Quote:
Originally Posted by nevcairiel View Post
Or fix ffdshow. Its the decoders job to pick an appropriate aspect ratio, my decoder does so.
And so does ffdshow when used with Haali
Haali split + ffdshow: OK
Haali split + LAV dec: OK
LAV split + LAV dec: OK
LAV split + ffdshow: NG
this is.. unexpected, just saying.

Quote:
And Yes, Haali does quite a bunch of evil things to work around broken things like ffdshow, which was one of the key ideas I started on - not to repeat those.
Indeed a wise choice, though I'm not sure it applies here since Haali split + LAV dec is OK.
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 28th November 2016, 16:57   #21330  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by sneaker_ger View Post
Great, thank you. Will it prefer container or bitstream (e.g. HEVC) or are both passed on and the renderer decides?
For basic color info, like colorspace/primaries/range/etc, it will prefer the container, and for HDR info it'll use the bitstream if present, otherwise the container.

I could probably add some more checks if the bitstream only has partial info to switch to the container HDR info, or something, but noone ever specifies how two conflicting sets of information are meant to be interpreted.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 17:00   #21331  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by TheShadowRunner View Post
this is.. unexpected, just saying
No, this is exactly what one would expect to happen. Haali Splitter hacks the new AR into the bitstream so it works with all decoders (including LAV), LAV Splitter relies on the decoder to be smart and do the right thing.
Nothing else about it.

Quote:
Originally Posted by TheShadowRunner View Post
Indeed a wise choice, though I'm not sure it applies here since Haali split + LAV dec is OK.
If you would want to codec AR to be used instead of the stream AR, then you would be screwed with Haali, since it gives you no choice.

LAV Splitter + LAV Video gives you all the choices, and it takes the correct one by default. So thats all thats to it.

ffdshow is dumb and can't use the constainer AR, so Haali does something evil and changes the AR in the codec bitstream to match the container AR, and it magically works everywhere. But its still evil, and you should just use a smarter decoder if you care about this.
In any case, I do not support any usage with ffdshow or Haali anymore, both of those are entirely dead, so if you want to keep using them, you are on your own either way.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 28th November 2016 at 17:06.
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 17:08   #21332  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by nevcairiel View Post
I could probably add some more checks if the bitstream only has partial info to switch to the container HDR info, or something, but noone ever specifies how two conflicting sets of information are meant to be interpreted.
For AR LAV prefers container over bitstream by default, right? I guess doing the same for HDR would at least be consistent. Plus editing MKV container info is easier done than editing the bitstream info. Muxing is last step of production anyways.

(Then again, we have Matroska default values. E.g. matrix must be "unspecified" if element is missing. )

Last edited by sneaker_ger; 28th November 2016 at 17:21.
sneaker_ger is offline   Reply With Quote
Old 28th November 2016, 17:34   #21333  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by sneaker_ger View Post
For AR LAV prefers container over bitstream by default, right? I guess doing the same for HDR would at least be consistent. Plus editing MKV container info is easier done than editing the bitstream info. Muxing is last step of production anyways.
I suppose I can make it prefer container, one wouldn't put it in there if its not supposed to be used, right?

Quote:
Originally Posted by sneaker_ger View Post
(Then again, we have Matroska default values. E.g. matrix must be "unspecified" if element is missing. )
I treat unspecified as unset, and if bitstream is set it'll use that. Thats really the only way to handle those.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 17:37   #21334  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by nevcairiel View Post
I suppose I can make it prefer container, one wouldn't put it in there if its not supposed to be used, right?
Yes, I guess so.
sneaker_ger is offline   Reply With Quote
Old 28th November 2016, 17:38   #21335  |  Link
TheShadowRunner
Registered User
 
TheShadowRunner's Avatar
 
Join Date: Feb 2004
Posts: 399
Roger that, it makes sense now.
Indeed Haali shouldn't alter the codec bitstream AR as a workaround for ffdshow not using container AR, it's bad.
I'm moving slowly to everything LAV so excuse the late discoveries ^^
__________________
XP SP3 / Geforce 8500 / Zoom Player
TheShadowRunner is offline   Reply With Quote
Old 28th November 2016, 20:44   #21336  |  Link
Mercury_22
Registered User
 
Join Date: Dec 2007
Posts: 1,138
Quick question : Why HDR it's not working for MPC-BE + madVR v0.91.3 + LAVFilters-0.68.1-37 but it's working for MPC-BE + madVR v0.91.3 + MPC-BE's internal filters ?
On the same (driver, os, madVR settings, ...) system no other changes (native & copy-back & SW tested )
Do I need to enable / disable something in LAV's default settings ?
Samples : VP9 Profile 2 HDR
__________________
Intel UHD Graphics 750; Win 10 22H2
Mercury_22 is offline   Reply With Quote
Old 28th November 2016, 20:45   #21337  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
I've done some testing to try and narrow down the problem with Dolby II matrix: Seems like the problem exists way back even in version 0.60.1. of LAV filters.

I'm now wondering if it's possible the source is simply strange. Maybe the channels are encoded in 90 degrees phase from each other, which somehow causes cancellation when Dolby combines and phase shifts the signals? Nevcairel, I've got a vid sample I could share with you if you'd be interested to see. For what it's worth, even when I put the down-mixed signal into my 5.1 system that expects to receive 2.0 Dolby Pro Logic II, the audio center is very much moved to the right.
har3inger is offline   Reply With Quote
Old 28th November 2016, 20:49   #21338  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by Mercury_22 View Post
Quick question : Why HDR it's not working for MPC-BE + madVR v0.91.3 + LAVFilters-0.68.1-37 but it's working for MPC-BE + madVR v0.91.3 + MPC-BE's internal filters ?
On the same (driver, os, madVR settings, ...) system no other changes (native & copy-back & SW tested )
Do I need to enable / disable something in LAV's default settings ?
Samples : VP9 Profile 2 HDR
If you would read the last couple posts, you would know that its not supported in -37 yet but will need the next nightly.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 28th November 2016, 20:51   #21339  |  Link
Mercury_22
Registered User
 
Join Date: Dec 2007
Posts: 1,138
Quote:
Originally Posted by nevcairiel View Post
If you would read the last couple posts, you would know that its not supported in -37 yet but will need the next nightly.
Ooooops Sorry !
__________________
Intel UHD Graphics 750; Win 10 22H2
Mercury_22 is offline   Reply With Quote
Old 29th November 2016, 03:24   #21340  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
@nevcairiel

Any idea how to improve this Nvidia Hybrid Decoder situation with Lav DXVA ?

every DXVA implementation shows the same latency problem with it and DXVA copy-back is still sub optimal CUVID Performs the most stable with it on EVR CP but CUVID is not the optimal at playback for the Fixed Function Decoder there DXVA is.

I guess a viable solution to this problem could be using CUVID for the Hybrid Decoder as preferred and DXVA for the Fixed Function Decoder.

The more complex the Bitstream the more problematic this issue becomes here on the GTX 970.


Nvidia Hybrid HEVC Decoder EVR-CP DXVA Native Latency issue

Lav DXVA





Lav CUVID






you see their up to 20 ms render spikes with DXVA it stutters like crazy with CUVID the present is ultra smooth either Windowed or Fullscreen.

PS: i will close this case now as for me finally i can exactly reproduce it and i can be sure that this is the exact issue and have to reevaluate a lot now based on it (First testing different EVR-CP implementations and how they behave with the CUDA Decoder and DXVA).

Especially finding the exact reason now why the CUDA Decoder behaves like that with DXVA and EVR-CP (very unstable) on my System of course it would be rather nice if some LAV DXVA Nvidia Maxwell users could maybe try to reproduce it on their Systems under at least similar properties (Maxwell HEVC Cuda Decoder DXVA and EVR CP presumably on Windows 7) especially if they where surprised why Bitstreams that would rather fall absolutely in the Decoder Specs behave problematic like that with DXVA and spiking like crazy on the present render times.

The major difference is the Core Frequency with CUVID it stays with the sample test above constantly @ 1126 MHz CPU: 23% GPU 22%

DXVA Native want's to go down immediately to 7xx MHz rises up to 1126 but present latency doesn't improve.

And when DXVA Copy Back decides to go as low as Memory 747 MHz and Core 911 MHz it goes totally out of sync.

And becomes a mega present disaster




It seems Nvidia never really tested the CUDA Decoder on something like EVR-CP and it's reliability their with DXVAs Dynamic Frequency Decisions.

It completely fails to understand how to get the playback stable it seems the Frequency decisions taken are totally wrong for the CUDA Decoders stability.

I guess there is really no other way to maintaining stability for the CUDA Decoder then to switch Dynamically to CUVID for this specific Playback Scenario.
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 30th November 2016 at 00:18.
CruNcher is offline   Reply With Quote
Reply

Tags
decoders, directshow, filters, splitter

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.