Hello,
Am 28.12.18 um 01:59 schrieb Nicolas George:
Uwe Freese (2018-12-27):
Good. But then I totally don't understand why that 64:45 is not used and
stored at mkv container level as well.
Since you have not provided the full information necessary to explain,
nobody will be able to.
I think
2018-12-27 22:25 GMT+01:00, Uwe Freese :
> Hello,
>>> Instead, the better solution would then be to give the SAR to whatever
>>> calculates the SAR to store at container level not as a double or int,
>>> but as a "AVRational", which contains the "num" and "den" values (in
>>> this case 64 and 45)?
Uwe Freese (2018-12-27):
> Good. But then I totally don't understand why that 64:45 is not used and
> stored at mkv container level as well.
Since you have not provided the full information necessary to explain,
nobody will be able to.
Regards,
--
Nicolas George
signature.asc
Description:
Hello,
Instead, the better solution would then be to give the SAR to whatever
calculates the SAR to store at container level not as a double or int,
but as a "AVRational", which contains the "num" and "den" values (in
this case 64 and 45)?
This is exactly what FFmpeg does (since forever).
2018-12-27 10:50 GMT+01:00, Uwe Freese :
> Am 26.12.18 um 15:08 schrieb Reino Wijnsma:
>>> Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR
>>> 64:45 DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn,
>>> 100 tbc (default)
>>>
>>> What does SAR (and DAR)
Am 26.12.18 um 15:08 schrieb Reino Wijnsma:
Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR 64:45
DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn, 100 tbc
(default)
What does SAR (and DAR) mean in the brackets compared to the second SAR
172:121,
Hello,
here's the command line output. The "test.mkv" was a part of a TV
recording stored in huffyuv format in this case. The input SAR of 1:1
was not correct (test.mkv created with avidemux), therefore I set it
with the "setdar" filter.
You said that the SAR provided by the container is
On 25-12-2018 20:54, Uwe Freese wrote:
> Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR 64:45
> DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn, 100 tbc
> (default)
>
> What does SAR (and DAR) mean in the brackets compared to the second SAR
> 172:121,
> Am 26.12.2018 um 12:07 schrieb Ulf Zibis :
>
> Hi,
>
>> Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos:
>> SAR is expected to change if you crop.
> I do not agree with. SAR should not change, so the video always shows a
> circle as a correct circle. Only the DAR should change from cropping.
> Am 26.12.2018 um 12:23 schrieb Uwe Freese :
> Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos:
>>> I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and
>>> changes it. Maybe someone can explain why this happens:
>>>
>>> I've a video from TV with original size 720x576
Hello,
Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos:
I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and changes
it. Maybe someone can explain why this happens:
I've a video from TV with original size 720x576 pixels (PAL), which shall be
shown as 16:9 aspect ratio.
The
Hi,
Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos:
> SAR is expected to change if you crop.
I do not agree with. SAR should not change, so the video always shows a
circle as a correct circle. Only the DAR should change from cropping.
> Rounding can be different for different codecs and
Von meinem iPhone gesendet
> Am 25.12.2018 um 20:54 schrieb Uwe Freese :
> I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and
> changes it. Maybe someone can explain why this happens:
>
> I've a video from TV with original size 720x576 pixels (PAL), which shall be
>
Hello,
I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and
changes it. Maybe someone can explain why this happens:
I've a video from TV with original size 720x576 pixels (PAL), which
shall be shown as 16:9 aspect ratio.
The SAR of the input video is correctly shown as
14 matches
Mail list logo
