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 30th November 2012, 12:40   #13221  |  Link
Weirdo
Registered User
 
Join Date: Aug 2005
Posts: 226
Quote:
Originally Posted by nevcairiel View Post
It plays fine, and then without doing anything it would suddenly crash?
In Live TV only, in MC18 too? Or also file playback?
I've noticed it on live tv only, on both players. Yes, a sudden crash. I'll have to reinstall 0.54 for more info, 0.53 seems to work fine.
Weirdo is offline   Reply With Quote
Old 30th November 2012, 16:56   #13222  |  Link
mindbomb
Registered User
 
Join Date: Aug 2010
Posts: 578
i have a question about intel and hardware acceleration:
which gpus support quicksync?
which support dxva?
and which support the clearvideo thing only?
And what decoders support that?
mindbomb is offline   Reply With Quote
Old 30th November 2012, 22:20   #13223  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 930
Quote:
Originally Posted by mindbomb View Post
which gpus support quicksync?
Sandy Bridge (Core ix-2xxx or equivalent Celeron/Pentium) or newer.

Quote:
Originally Posted by mindbomb View Post
which support dxva?
Any of them with an IGP, AFAIK.
__________________
HTPC Hardware: Intel Celeron G530; nVidia GT 430
HTPC Software: Windows 7; MediaPortal 1.19.0; Kodi DSPlayer 17.6; LAV Filters (DXVA2); MadVR
TV Setup: LG OLED55B7V; Onkyo TX-NR515; Minix U9-H
DragonQ is offline   Reply With Quote
Old 30th November 2012, 22:24   #13224  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
The first Intel with DXVA was the G35/G965 chipset, plenty old.
Anything before Sandy Bridge only supports Intels special "ClearVideo" mode (except possibly for MPEG-2). Sandy Bridge and above add support for standard H.264 DXVA, but not for VC-1 (VC-1 only runs through QuickSync)
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 1st December 2012, 12:59   #13225  |  Link
wanezhiling
Registered User
 
Join Date: Apr 2011
Posts: 1,169
About ClearVideo and QuickSync, you could click the link:http://en.wikipedia.org/wiki/Compari...fth_generation

Note1: All Clarkdale and above GPUs support QuickSync decoding, Celeron and Pentium just dont support QuickSync encoding.
Note2: Egur's QuickSync decoder blocked Clarkdale, so you need a SNB CPU @ least.




About DXVA, click the link above again.http://en.wikipedia.org/wiki/Compari...ocessing_units

Start from G33(third generation), MPEG2 has been fully supported, but no H.264 and VC-1.
Start from G45(fourth generation), H.264 and VC-1 are fully supported too, which is a "milestone" for Intel HD technology.
Note: Clarkdale/SNB/IVB(fifth/sixth/seventh generation) GPUs' VC-1 is a bit strange. Only CyberLink and ArcSoft have access to VC-1_VLD(full acceleration), other players/decoders stay VC-1_IDCT(partial acceleration).

Last edited by wanezhiling; 1st December 2012 at 13:02.
wanezhiling is offline   Reply With Quote
Old 1st December 2012, 13:30   #13226  |  Link
Warlock
Registered User
 
Join Date: Mar 2012
Posts: 29
Guys, how dxva native has incompatibility problem with the xy-VSFilter? I did a test, every time I select the dxva native mode, I open any video, falls in software mode. The only format that works in dxva native when the xy-VSFilter is enabled, it is .MP4. I turned off the xy-VSFilter and activated the subtitle renderer of mpc-hc. After that, all videos began to be recognized by the dxva native mode, with the exception of 10-bit videos. How can I solve this problem between dxva native and xy-VSFilter?
Warlock is offline   Reply With Quote
Old 1st December 2012, 13:52   #13227  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by Warlock View Post
Guys, how dxva native has incompatibility problem with the xy-VSFilter? I did a test, every time I select the dxva native mode, I open any video, falls in software mode. The only format that works in dxva native when the xy-VSFilter is enabled, it is .MP4. I turned off the xy-VSFilter and activated the subtitle renderer of mpc-hc. After that, all videos began to be recognized by the dxva native mode, with the exception of 10-bit videos. How can I solve this problem between dxva native and xy-VSFilter?
dxva native is not supposed to work if you use any additional filters, be it xy-vsfilter or anything else. if something tells you that it works, you likely misunderstood something or its just wrong. internal renderer and vsfilter is a different things, don't compare them.

Last edited by Keiyakusha; 1st December 2012 at 13:54.
Keiyakusha is offline   Reply With Quote
Old 1st December 2012, 14:17   #13228  |  Link
andybkma
Registered User
 
Join Date: Sep 2006
Posts: 183
Win 7 64 bit, Zoom Player

nev, seemed to have stumbled upon a bug using LAV Splitter 54.1 where certain widescreen .mp4 or .m4v/avc vids don't display properly as they should (in widescreen format) but instead as a square fullscreen. Using a different mp4 splitter such as AVSplitter fixes the problem so can only assume the problem is with LAV Splitter. I went back four or five LAV versions to see if the problem persisted and it did so it seems this is not a new problem.

Sample link: http://filestay.com/p1ercgk44qcx/mp4_displays_in_fullscreen.m4v.html
andybkma is offline   Reply With Quote
Old 1st December 2012, 14:58   #13229  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
The file is working as intended, its just muxed wrong.
The MP4 file specifies a AR of 3:2, and the H264 stream an AR of 16:9. Which should be used for playback?

LAV Splitter will always output the 3:2 AR, because its a splitter, it reads the container values, not the stream values.
LAV Video (by default) trusts the AR from the Splitter in MP4 files, because most people do the muxing correct and the encoding wrong. The muxed value is also easier to fix then the encoded value in the video stream. There is an option to control how Stream AR is handled in the LAV Video options if you don't like it behaving correctly.

PS:
Please use better file hosts, that page is just horrible. Took about 5 minutes until the download started, and took like 40 minutes to download that 67mb file. Whats wrong with mediafire?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 1st December 2012, 15:21   #13230  |  Link
wanezhiling
Registered User
 
Join Date: Apr 2011
Posts: 1,169
How will Haali work in that condition?



Quote:
Originally Posted by nevcairiel View Post
There is an option to control how Stream AR is handled in the LAV Video options if you don't like it behaving correctly.
That option should be checked by default. I think 99% people want to watch 16:9 not 3:2/4:3

Last edited by wanezhiling; 1st December 2012 at 16:37.
wanezhiling is offline   Reply With Quote
Old 1st December 2012, 16:38   #13231  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Never understood why container AR should take preference. The option to chose between them should be of course, as you not always can fix already broken files. But default should read stream info only. User should be forced to do one of the following: a) fix the existing stream b) reencode stream with correct settings c) temporarily change setting in LAV to read container ar d) temporarily redefine ar in player's playback settings
Plenty of options! And by using container AR they'll just never learn how to produce correct files. User should see that what they did is not correct. There is no way to make a warning in x264 or something as it have no idea what ar should be in which situation.
Personally I always use ar info only. BTW half-checked ar setting in LAV decoder fails with this file. But obviously works with reading ar from stream. There is no more correct way to produce this file, so why should broken files work and normal not?

Last edited by Keiyakusha; 1st December 2012 at 16:45.
Keiyakusha is offline   Reply With Quote
Old 1st December 2012, 16:44   #13232  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
It doesn't "fail", you just produced a broken file, with conflicting information. In my experience (from users complaining and files i have seen), its far more common for the container AR to either: not be set at all (which is fine, and stream AR is used), or the container AR be set correctly, sometimes with a non-existant or broken stream AR, and the users expect it to be used for playback. Note that this only applies to MKV and MP4.

Using the container AR is perfectly valid, because not all video formats even have a stream AR.

If you think anything else is better, the option lets you configure it however you want.

Quote:
Originally Posted by wanezhiling View Post
That option should be checked by default. I think 99% people want to watch 16:9 not 3:2/4:3
For this sample, sure, i probably have a list of samples which only work properly with the current mode.
There have been plenty complains to other decoder authors for not adding an option to ignore stream AR, because they didn't want it to be used.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 1st December 2012 at 16:46.
nevcairiel is offline   Reply With Quote
Old 1st December 2012, 16:47   #13233  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,495
Quote:
Originally Posted by Keiyakusha View Post
And by using container AR they'll just never learn how to produce correct files. User should see that what they did is not correct.
Then people will start producing files with wrong container AR. There is no right or wrong here.

Quote:
Originally Posted by Keiyakusha View Post
BTW half-checked ar setting in LAV decoder fails with this file. But obviously works with reading ar from stream.
Yes, it does exactly what it is supposed to do. I think changing AR is not allowed in Matroska anyways. (Or was it changing resolution?)

Last edited by sneaker_ger; 1st December 2012 at 16:49.
sneaker_ger is offline   Reply With Quote
Old 1st December 2012, 16:50   #13234  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by nevcairiel View Post
It doesn't "fail", you just produced a broken file, with conflicting information.
Since when variable ar is broken? Any two valid appended h264 streams give us valid h264 stream. Stream not breaks mkv and will be spitted by any compliant splitter. Decoder is the one who fails here.

Quote:
Originally Posted by nevcairiel View Post
the container AR be set correctly, sometimes with a non-existant or broken stream AR, and the users expect it to be used for playback
I gave 4 options to deal with this case. There is no reason to hide an issue instead of making them fix it.

Quote:
Originally Posted by sneaker_ger View Post
hen people will start producing files with wrong container AR. There is no right or wrong here.
I don't really understand why. Lets assume that now the do it right, why would they stop doing it?

Quote:
Originally Posted by sneaker_ger View Post
Yes, it does exactly what it is supposed to do. I think changing AR is not allowed in Matroska anyways. (Or was it changing resolution?)
Resolution is constant, ar is different. It doesn't needs to be supported. ar info exists in stream, martoska ar perfectly fine to be used as fallback.

Last edited by Keiyakusha; 1st December 2012 at 16:57.
Keiyakusha is offline   Reply With Quote
Old 1st December 2012, 16:54   #13235  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
It doesn't matter what you think is the correct way to produce files anyway. The defaults in LAV are choosen to be correct with as many files as possible, based on empirecal evidence based on user complaints and sample files i gathered over the years. A correctly encoded and muxed file would usually work, broken in any direction needs some kind of compromise.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 1st December 2012, 16:58   #13236  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,495
Quote:
Originally Posted by Keiyakusha View Post
I don't really understand why. Lets assume that now the do it right, why would they stop doing it?
Currently: LAV uses container AR by default and people make broken files without using the correct bitstream AR
Your solution: LAV uses bitstream AR by default and people will make files without using the correct container AR

Whatever LAV does, people will produce broken files.

And who is to define that bitstream AR takes preference over container AR anyways?
sneaker_ger is offline   Reply With Quote
Old 1st December 2012, 17:01   #13237  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by nevcairiel View Post
The defaults in LAV are choosen to be correct with as many files as possible
I see. Next step would be to add denoising, edge enchancing and various other things that makes files better than they are. Just like in every second crappy payware out there.

Quote:
Originally Posted by sneaker_ger View Post
Your solution: LAV uses bitstream AR by default and people will make files without using the correct container AR
There is no way to produce incorrect container ar unless you explicitly set it incorrectly. These users just need to RTFM. On the other hand by not setting stream ar it produces incorrect result.

Last edited by Keiyakusha; 1st December 2012 at 17:03.
Keiyakusha is offline   Reply With Quote
Old 1st December 2012, 17:07   #13238  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
There is also no way to set a wrong stream ar unless you explictly set a wrong one. I fail to see the point of the argument.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 1st December 2012, 17:10   #13239  |  Link
wanezhiling
Registered User
 
Join Date: Apr 2011
Posts: 1,169
Quote:
Originally Posted by nevcairiel View Post
For this sample, sure, i probably have a list of samples which only work properly with the current mode.
There have been plenty complains to other decoder authors for not adding an option to ignore stream AR, because they didn't want it to be used.
Adding an option for users is pretty nice, but what the default setting should be annoys me. Is LAV video decoder the first one to do that?

Last edited by wanezhiling; 1st December 2012 at 17:12.
wanezhiling is offline   Reply With Quote
Old 1st December 2012, 17:12   #13240  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,576
Quote:
Originally Posted by nevcairiel View Post
There is also no way to set a wrong stream ar unless you explictly set a wrong one. I fail to see the point of the argument.
What I mean is setting container ar is the step that you can't skip. It is mandatory element. But it is possible to skip setting stream ar, which is what often happens. In case of anamorphic encode not setting stream ar equals to setting it wrong. Edit: but this was just answer to sneaker_ger, it wasn't meant to support my previous posts about ar.

Last edited by Keiyakusha; 1st December 2012 at 17:17.
Keiyakusha 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 17:55.


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