On Fri, 16 Jan 2015 22:17:56 +0100 Nicolas George <geo...@nsup.org> wrote:
> Le septidi 27 nivôse, an CCXXIII, Philip Langdale a écrit : > > Right. It is display aspect ratio, not sample aspect ratio. And then > > you have the 45/44 problem, unless that's somehow just affecting me. > > IIRC, the tests you ran were not accurate enough to know for sure. I > suggest the following test case: > > - start with a 832 × 448 input (testsrc=s=832x448 should do the > trick); > > - force darWidth / darHeight = 19 / 17 (patching the source directly > seems like the simplest way of doing it for this kind of tests); > > - encode to H.265 elementary stream; > > - check the output file with the ffmpeg summary AND ffprobe > -show_stream AND ffmpeg -vf showinfo -f null -. > > The numbers are selected with unambiguous prime factors. > > I do not have access to nvidia hardware, so I can not run the tests. Ok. I did this test and it produces correct results - SAR 133:221 which yields the correct final aspect ratio, but if I try and do a real world case, like my PAL DVD, it goes wrong - and Timo's patch goes wrong too, with this same weird 1.02 (45/44) scale factor. It's making my head hurt. So I feed in this input: Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576 [SAR 64:45 DAR 16:9], 25 tbr, 25 tbn, 25 tbc With libx264, I get the same SAR and DAR out. With nvenc, I get: sample_aspect_ratio=16:11 display_aspect_ratio=20:11 which is everything off by ~1.02. That's with Timo's patch and with hard-coding the darWidth and darHeight to 1024x576. Same result. --phil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
