There is a long sad story behind all this, but it's somewhat ambiguous as to
whether DVD content should be treated as 720 pixels wide or 704 pixels, with
16 pixels cut off. If you decide is should be 704 pixels wide, you need to
adjust the sample aspect ratio to keep the final display aspect ratio
There is a long sad story behind all this, but it's somewhat ambiguous as to
whether DVD content should be treated as 720 pixels wide or 704 pixels, with
16 pixels cut off. If you decide is should be 704 pixels wide, you need to
adjust the sample aspect ratio to keep the final display aspect ratio
L'octidi 28 nivôse, an CCXXIII, Philip Langdale a écrit :
> There is a long sad story behind all this, but it's somewhat ambiguous as to
> whether DVD content should be treated as 720 pixels wide or 704 pixels, with
> 16 pixels cut off. If you decide is should be 704 pixels wide, you need to
> adju
On 17 January 2015 at 20:01, Philip Langdale wrote:
> There is a long sad story behind all this, but it's somewhat ambiguous as to
> whether DVD content should be treated as 720 pixels wide or 704 pixels, with
> 16 pixels cut off. If you decide is should be 704 pixels wide, you need to
> adjust th
L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> BT601 makes this very clear. The active picture is 702 pixels.
There are two fundamental flaws with your reasoning:
First, BT601 only applies to a some kind of videos. Wikipedia tells me it
applies to "encoding interlaced analog video sign
On 17 January 2015 at 20:42, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> BT601 makes this very clear. The active picture is 702 pixels.
>
> There are two fundamental flaws with your reasoning:
>
> First, BT601 only applies to a some kind of videos. Wikipedia
L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> I don't make the standards and frankly whether you dislike them is
> your problem but they exist and need to work correctly.
> Instead you wish to break things based off an artificial test pattern
> and your own beliefs.
I do not wish to br
On 17 January 2015 at 23:00, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> I don't make the standards and frankly whether you dislike them is
>> your problem but they exist and need to work correctly.
>> Instead you wish to break things based off an artificial
L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> The behaviour of the Nvidia code I believe is correct.
> As far as I understand it corrects SAR for 720-width content to comply
> with BT601.
That is just not true.
Basic principle: THE COMPETENT USER IS RIGHT.
If someone knows BT601, and
On 17 January 2015 at 23:38, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> The behaviour of the Nvidia code I believe is correct.
>> As far as I understand it corrects SAR for 720-width content to comply
>> with BT601.
>
> That is just not true.
>
> Basic princ
On 17 January 2015 at 23:46, Kieran Kunhya wrote:
> On 17 January 2015 at 23:38, Nicolas George wrote:
>> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>>> The behaviour of the Nvidia code I believe is correct.
>>> As far as I understand it corrects SAR for 720-width content to comply
>
L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> > There is a very simple way of flagging content that is supposed to comply
> > with BT601: the SAR is 512/351. If SAR is 64/45, that means someone before
> > nvenc decided that the video is not expected to conform with BT601, and
> > nvenc
L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> Oops I misunderstood, you mean the software must comply with the users wishes.
Yes.
> Anyway my argument is that BT601 should be the default for the these
> resolutions.
If you want, but that must happen immediately when the contents ente
On Sun, Jan 18, 2015 at 1:02 AM, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> > Oops I misunderstood, you mean the software must comply with the users
> wishes.
>
> Yes.
>
> > Anyway my argument is that BT601 should be the default for the these
> > resolutions
Le nonidi 29 nivôse, an CCXXIII, Hendrik Leppkes a écrit :
> nvenc should behave the same as libx264, or any other video encoder, if
> this patch makes it do that, then it should be applied.
>
> If bt601 needs special handling not yet present in avcodec, it should be
> implemented in such a way th
On 18 January 2015 at 09:40, Nicolas George wrote:
> Le nonidi 29 nivôse, an CCXXIII, Hendrik Leppkes a écrit :
>> nvenc should behave the same as libx264, or any other video encoder, if
>> this patch makes it do that, then it should be applied.
>>
>> If bt601 needs special handling not yet presen
On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
> On Sun, Jan 18, 2015 at 1:02 AM, Nicolas George wrote:
>
> > L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
> > > Oops I misunderstood, you mean the software must comply with the users
> > wishes.
> >
> > Yes.
> >
> > > A
On Sun, Jan 18, 2015 at 11:16:04AM +, Kieran Kunhya wrote:
> On 18 January 2015 at 09:40, Nicolas George wrote:
> > Le nonidi 29 nivôse, an CCXXIII, Hendrik Leppkes a écrit :
> >> nvenc should behave the same as libx264, or any other video encoder, if
> >> this patch makes it do that, then it
On 18 January 2015 at 12:22, Michael Niedermayer wrote:
> On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
>> On Sun, Jan 18, 2015 at 1:02 AM, Nicolas George wrote:
>>
>> > L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>> > > Oops I misunderstood, you mean the software m
On Sun, 18 Jan 2015 10:40:24 +0100
Nicolas George wrote:
> I have downloaded BT.601 from http://www.itu.int/rec/R-REC-BT.601/ >, both the most recent and the
> oldest versions, and I did not find any explicit reference of this
> 702 business, nor could I decipher indirect references, so I still
>
On Sun, Jan 18, 2015 at 01:28:36PM +, Kieran Kunhya wrote:
> On 18 January 2015 at 12:22, Michael Niedermayer wrote:
> > On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
> >> On Sun, Jan 18, 2015 at 1:02 AM, Nicolas George wrote:
> >>
> >> > L'octidi 28 nivôse, an CCXXIII, Kie
On 18 January 2015 at 13:55, Michael Niedermayer wrote:
> On Sun, Jan 18, 2015 at 01:28:36PM +, Kieran Kunhya wrote:
>> On 18 January 2015 at 12:22, Michael Niedermayer wrote:
>> > On Sun, Jan 18, 2015 at 02:52:59AM +0100, Hendrik Leppkes wrote:
>> >> On Sun, Jan 18, 2015 at 1:02 AM, Nicolas
On Sat, Jan 17, 2015 at 11:35:41AM -0800, Philip Langdale wrote:
> There is a long sad story behind all this, but it's somewhat ambiguous as to
> whether DVD content should be treated as 720 pixels wide or 704 pixels, with
> 16 pixels cut off. If you decide is should be 704 pixels wide, you need to
On Sun, 18 Jan 2015 18:41:09 +0100
Reimar Döffinger wrote:
> Oh my god, this is so horribly broken I vote for doing a "return
> -EBROKENAPI" and tell them we'll enable this when NVidia fixes their
> stuff.
> IMHO some features are not worth the hacks necessary.
[08:51] just let nvidia change asp
On 19.01.2015, at 01:16, compn wrote:
> On Sun, 18 Jan 2015 18:41:09 +0100
> Reimar Döffinger wrote:
>> Oh my god, this is so horribly broken I vote for doing a "return
>> -EBROKENAPI" and tell them we'll enable this when NVidia fixes their
>> stuff.
>> IMHO some features are not worth the hacks
On Mon, 19 Jan 2015 07:48:24 +0100
Reimar Döffinger wrote:
> On 19.01.2015, at 01:16, compn wrote:
> > On Sun, 18 Jan 2015 18:41:09 +0100
> > Reimar Döffinger wrote:
> >> Oh my god, this is so horribly broken I vote for doing a "return
> >> -EBROKENAPI" and tell them we'll enable this when NVid
Le nonidi 29 nivôse, an CCXXIII, compn a écrit :
> [08:57] compn: the nvidia behaviour is correct
It would help a lot if he had the courtesy of actually explaining why he
considers the behaviour to be correct. After all, a lot of people in this
thread, possibly not as smart and knowledgeable as h
Le nonidi 29 nivôse, an CCXXIII, Philip Langdale a écrit :
> Right. And it's obviously wrong if you consider that trying to encode
> any square pixel content at this size results in non-square output.
>
> I'd also argue that bt.601 semantics come into play when you're
> authoring the DVD, and any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17/01/15 23:52, Nicolas George wrote:
> L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
>>> There is a very simple way of flagging content that is supposed to comply
>>> with BT601: the SAR is 512/351. If SAR is 64/45, that means someone b
Le decadi 30 nivôse, an CCXXIII, tim nicholson a écrit :
> I am struggling to follow some of the arguments, which seem far to
> heated to be as useful as they could be.
Please see my other mail, I summarize it more extensively.
> I am not sure what is currently wrong, and where, but please let us
> Taking the Sample/pixel aspect ratio (SAR) calculated above and feeding
> that back into calculating a display aspect ratio *for the whole frame*
> leads to a value that is not 16:9 (or 4:3), and it appears to be this
> figure which is then reported as the DAR, rather than that of the active
> pi
On 2015/1/18 4:01, Philip Langdale wrote:
There is a long sad story behind all this, but it's somewhat ambiguous as to
whether DVD content should be treated as 720 pixels wide or 704 pixels, with
16 pixels cut off. If you decide is should be 704 pixels wide, you need to
adjust the sample aspect r
On 21.01.2015, at 07:17, Agatha Hu wrote:
> On 2015/1/18 4:01, Philip Langdale wrote:
>> There is a long sad story behind all this, but it's somewhat ambiguous as to
>> whether DVD content should be treated as 720 pixels wide or 704 pixels, with
>> 16 pixels cut off. If you decide is should be 704
On 2015/1/21 16:00, Reimar Döffinger wrote:
On 21.01.2015, at 07:17, Agatha Hu wrote:
On 2015/1/18 4:01, Philip Langdale wrote:
Here's the reply from NVENC engineers
It is not same thing as SAR. It is the display aspect ratio i.e width/height =
DAR/SAR
The calculation below should be li
On Thu, 22 Jan 2015 12:15:44 +0800
Agatha Hu wrote:
> We will fix the issue in driver, overscan compensation will be
> applied to input DAR *only* if the DAR is 4:3 or 16:9, otherwise
> won't unnecessarily modify the aspect ratio for resolutions like
> 720x480 and 720x576.
> The fix will be on fu
On 22.01.2015, at 05:15, Agatha Hu wrote:
> On 2015/1/21 16:00, Reimar Döffinger wrote:
>> On 21.01.2015, at 07:17, Agatha Hu wrote:
>>> On 2015/1/18 4:01, Philip Langdale wrote:
>
>>>
>>> Here's the reply from NVENC engineers
>>> It is not same thing as SAR. It is the display aspect rati
在 2015/1/22 12:29, Philip Langdale 写道:
On Thu, 22 Jan 2015 12:15:44 +0800
Agatha Hu wrote:
We will fix the issue in driver, overscan compensation will be
applied to input DAR *only* if the DAR is 4:3 or 16:9, otherwise
won't unnecessarily modify the aspect ratio for resolutions like
720x480 an
On Thu, 22 Jan 2015 13:12:59 +0800
Agatha Hu wrote:
> Disabling compensation is the best result, adding a flag is
> acceptable, but NVENC5.0 has just released, such option won't be
> available until 6.0 is available, so...
> Still waiting for nvenc teams feedback, the worst case is adding the
>
38 matches
Mail list logo
