On Mon, 19 Jan 2015 07:48:24 +0100 Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> On 19.01.2015, at 01:16, compn <te...@mi.rr.com> wrote: > > On Sun, 18 Jan 2015 18:41:09 +0100 > > Reimar Döffinger <reimar.doeffin...@gmx.de> 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] <compn> just let nvidia change aspect, its their crap, let > > them fix it > > > > [08:57] <kierank> compn: the nvidia behaviour is correct > > [08:57] <kierank> so no patches are necessary > > I don't really consider it "correct" if it doesn't do what a user > expects, plus as I understood the discussion neither ffplay nor > MPlayer nor VLC and probably WMP, flash player etc. will not show the > video correctly if encoding e.g. a BluRay to DVD resolution via nvenc > and playing it back. If they do I'll have to reconsider, but if they > don't it isn't working, "correct" or not. 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 transcoding you do after that should preserve the input characteristics - and that means the encoded SAR is based on a 720 pixel width. Why on earth my transcoded file should have a different SAR from the original when doing a digital->digital conversion is beyond me. --phil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel