Question about handling / unwanted changes of SAR in ffmpeg

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about handling / unwanted changes of SAR in ffmpeg

Uwe Freese
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 64:45 (resulting in
720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio).

When I crop black borders and encode this video using x264 codec and mkv
format, ffprobe shows about the result:

     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, which is slightly different?
Why isn't the second one also telling the same SAR 64:45 (which would be
the correct one)?

It gets stranger when I convert the video a second time using "ffmpeg -i
video_encode_x264.mkv test.mkv". ffmpeg seems to use the second (wrong)
SAR and shows:

     Output:
     Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p,
688x560 [SAR 172:121 DAR 7396:4235], q=-1--1, 50 fps, 1k tbn, 50 tbc
(default)

Why is ffmpeg now using the second (wrong) SAR?

Regards,
Uwe

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Carl Eugen Hoyos-2


Von meinem iPhone gesendet

> Am 25.12.2018 um 20:54 schrieb Uwe Freese <[hidden email]>:

> 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 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio).
>
> When I crop black borders

SAR is expected to change if you crop.
Rounding can be different for different codecs and containers.

Merry Christmas, Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

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.

> Rounding can be different for different codecs and containers.

This may be a reason, but one should be able to work around.

-Ulf

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Uwe Freese
In reply to this post by Carl Eugen Hoyos-2
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 SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio).
>>
>> When I crop black borders
> SAR is expected to change if you crop.
> Rounding can be different for different codecs and containers.

Why? The DAR, yes. But the SAR should stay the same. And it does
regarding the first output from ffmpeg in the brackets.

My questions remain: What does SAR (and DAR) mean in the brackets
compared to the second SAR 172:121, which is slightly different?

     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)

Why isn't the second one also telling the same SAR 64:45 (which would be
the correct one)? I don't see how 64:45 is rounded to 172:121. :)

Regards,
Uwe

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Carl Eugen Hoyos-2
In reply to this post by Ulf Zibis


> Am 26.12.2018 um 12:07 schrieb Ulf Zibis <[hidden email]>:
>
> 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.

That is correct, sorry!

>> Rounding can be different for different codecs and containers.
>
> This may be a reason, but one should be able to work around.

The work-around is part of FFmpeg and cannot be disabled.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Carl Eugen Hoyos-2
In reply to this post by Uwe Freese



> Am 26.12.2018 um 12:23 schrieb Uwe Freese <[hidden email]>:

> 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 SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio).
>>>
>>> When I crop black borders
>> SAR is expected to change if you crop.
>> Rounding can be different for different codecs and containers.
>
> Why? The DAR, yes. But the SAR should stay the same. And it does regarding the first output from ffmpeg in the brackets.

Yes.
Please provide the command line you tested together with the complete, uncut console output.

If your question was „why are there two SARs/DARs?“, the answer is that container and codec may contain different information: Although it is common to trust the container, this is just an arbitrary decision.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Reino Wijnsma
In reply to this post by Uwe Freese
On 25-12-2018 20:54, Uwe Freese <[hidden email]> 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, which is slightly different?
As far as I know:

688    x 64/45     = 978,49w
978,49 x 1575/2752 = 560h     --> 978x560 @ bitstream level
688    x 172/121 =   977,98w
977,98 x 4235/7396 = 560h     --> 977x560 @ container level

-- Reino
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Uwe Freese
In reply to this post by Carl Eugen Hoyos-2
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 more trusted by
default. This explains that the SAR defined in the container is used
when reencoding again (second call below).

But for the first call, I don't understand why the SAR in the container
is not also set to 64:45.

$ ffmpeg -i test.mkv -an -filter:v "crop=688:560:16:16,setsar=sar=64/45"
result.mkv
ffmpeg version 3.2.12-1~deb9u1 Copyright (c) 2000-2018 the FFmpeg developers
   built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
   configuration: --prefix=/usr --extra-version='1~deb9u1'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libebur128 --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libpulse
--enable-librubberband --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-omx --enable-openal
--enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883
--enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264
--enable-shared
   libavutil      55. 34.101 / 55. 34.101
   libavcodec     57. 64.101 / 57. 64.101
   libavformat    57. 56.101 / 57. 56.101
   libavdevice    57.  1.100 / 57.  1.100
   libavfilter     6. 65.100 /  6. 65.100
   libavresample   3.  1.  0 /  3.  1.  0
   libswscale      4.  2.100 /  4.  2.100
   libswresample   2.  3.100 /  2.  3.100
   libpostproc    54.  1.100 / 54.  1.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, matroska,webm, from 'test.mkv':
   Metadata:
     ENCODER         : Lavf57.25.100
   Duration: 00:00:52.22, start: 0.000000, bitrate: 65478 kb/s
     Stream #0:0: Video: huffyuv (HFYU / 0x55594648), yuv422p, 720x576,
SAR 1:1 DAR 5:4, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
     Metadata:
       DURATION        : 00:00:52,200000000
     Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
(default)
     Metadata:
       DURATION        : 00:00:52,219000000
No pixel format specified, yuv422p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x558ea30b3180] using SAR=64/45
[libx264 @ 0x558ea30b3180] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX
[libx264 @ 0x558ea30b3180] profile High 4:2:2, level 3.0, 4:2:2 8-bit
[libx264 @ 0x558ea30b3180] 264 - core 148 r2748 97eaef2 - H.264/MPEG-4
AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html -
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6
lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0
bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250
keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf
mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40
aq=1:1.00
Output #0, matroska, to 'result.mkv':
   Metadata:
     encoder         : Lavf57.56.101
     Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv422p,
688x560 [SAR 64:45 DAR 2752:1575], q=-1--1, 25 fps, 1k tbn, 25 tbc (default)
     Metadata:
       DURATION        : 00:00:52,200000000
       encoder         : Lavc57.64.101 libx264
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream mapping:
   Stream #0:0 -> #0:0 (huffyuv (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame= 1302 fps= 88 q=-1.0 Lsize=    4963kB time=00:00:52.08 bitrate=
780.6kbits/s speed=3.54x
video:4952kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.206868%
[libx264 @ 0x558ea30b3180] frame I:13    Avg QP:18.85  size: 39046
[libx264 @ 0x558ea30b3180] frame P:407   Avg QP:21.45  size:  7822
[libx264 @ 0x558ea30b3180] frame B:882   Avg QP:24.19  size:  1564
[libx264 @ 0x558ea30b3180] consecutive B-frames:  2.8%  7.8% 38.7% 50.7%
[libx264 @ 0x558ea30b3180] mb I  I16..4: 17.1% 75.3%  7.6%
[libx264 @ 0x558ea30b3180] mb P  I16..4:  4.4% 11.4%  0.8% P16..4: 36.4%
10.0%  6.2%  0.0%  0.0%    skip:30.7%
[libx264 @ 0x558ea30b3180] mb B  I16..4:  0.3%  0.7%  0.0% B16..8:
25.9%  2.1%  0.3%  direct: 4.3%  skip:66.3%  L0:39.4% L1:49.5% BI:11.2%
[libx264 @ 0x558ea30b3180] 8x8 transform intra:69.5% inter:86.3%
[libx264 @ 0x558ea30b3180] coded y,uvDC,uvAC intra: 46.8% 68.5% 26.0%
inter: 8.8% 20.6% 1.6%
[libx264 @ 0x558ea30b3180] i16 v,h,dc,p: 50% 18%  8% 24%
[libx264 @ 0x558ea30b3180] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 14% 30% 
3%  3%  5%  2%  6%  3%
[libx264 @ 0x558ea30b3180] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 41% 16% 13% 
4%  5%  8%  4%  6%  3%
[libx264 @ 0x558ea30b3180] i8c dc,h,v,p: 40% 17% 36%  8%
[libx264 @ 0x558ea30b3180] Weighted P-Frames: Y:1.2% UV:1.2%
[libx264 @ 0x558ea30b3180] ref P L0: 60.5% 10.6% 18.8%  9.8%  0.4%
[libx264 @ 0x558ea30b3180] ref B L0: 87.0% 10.6%  2.4%
[libx264 @ 0x558ea30b3180] ref B L1: 97.2%  2.8%
[libx264 @ 0x558ea30b3180] kb/s:778.90
$ ffmpeg -i result.mkv result2.mkv
ffmpeg version 3.2.12-1~deb9u1 Copyright (c) 2000-2018 the FFmpeg developers
   built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
   configuration: --prefix=/usr --extra-version='1~deb9u1'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libebur128 --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libpulse
--enable-librubberband --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-omx --enable-openal
--enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883
--enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264
--enable-shared
   libavutil      55. 34.101 / 55. 34.101
   libavcodec     57. 64.101 / 57. 64.101
   libavformat    57. 56.101 / 57. 56.101
   libavdevice    57.  1.100 / 57.  1.100
   libavfilter     6. 65.100 /  6. 65.100
   libavresample   3.  1.  0 /  3.  1.  0
   libswscale      4.  2.100 /  4.  2.100
   libswresample   2.  3.100 /  2.  3.100
   libpostproc    54.  1.100 / 54.  1.100
Input #0, matroska,webm, from 'result.mkv':
   Metadata:
     ENCODER         : Lavf57.56.101
   Duration: 00:00:52.20, start: 0.120000, bitrate: 778 kb/s
     Stream #0:0: Video: h264 (High 4:2:2), yuv422p(progressive),
688x560 [SAR 64:45 DAR 2752:1575], SAR 172:121 DAR 7396:4235, 25 fps, 25
tbr, 1k tbn, 50 tbc (default)
     Metadata:
       ENCODER         : Lavc57.64.101 libx264
       DURATION        : 00:00:52.200000000
No pixel format specified, yuv422p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x55bf2ce415c0] using SAR=172/121
[libx264 @ 0x55bf2ce415c0] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX
[libx264 @ 0x55bf2ce415c0] profile High 4:2:2, level 3.0, 4:2:2 8-bit
[libx264 @ 0x55bf2ce415c0] 264 - core 148 r2748 97eaef2 - H.264/MPEG-4
AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html -
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7
psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6
lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0
bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250
keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf
mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40
aq=1:1.00
Output #0, matroska, to 'result2.mkv':
   Metadata:
     encoder         : Lavf57.56.101
     Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv422p,
688x560 [SAR 172:121 DAR 7396:4235], q=-1--1, 25 fps, 1k tbn, 25 tbc
(default)
     Metadata:
       DURATION        : 00:00:52.200000000
       encoder         : Lavc57.64.101 libx264
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream mapping:
   Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame= 1302 fps= 97 q=-1.0 Lsize=    4513kB time=00:00:51.96 bitrate=
711.5kbits/s speed=3.88x
video:4503kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.227170%
[libx264 @ 0x55bf2ce415c0] frame I:13    Avg QP:18.64  size: 38084
[libx264 @ 0x55bf2ce415c0] frame P:418   Avg QP:21.26  size:  6943
[libx264 @ 0x55bf2ce415c0] frame B:871   Avg QP:23.77  size:  1392
[libx264 @ 0x55bf2ce415c0] consecutive B-frames:  3.1% 13.2% 30.0% 53.8%
[libx264 @ 0x55bf2ce415c0] mb I  I16..4: 16.9% 75.5%  7.6%
[libx264 @ 0x55bf2ce415c0] mb P  I16..4:  3.9% 10.9%  0.8% P16..4:
37.1%  9.6%  5.0%  0.0%  0.0%    skip:32.7%
[libx264 @ 0x55bf2ce415c0] mb B  I16..4:  0.3%  0.6%  0.0% B16..8:
24.1%  2.0%  0.3%  direct: 4.3%  skip:68.3%  L0:40.1% L1:50.3% BI: 9.6%
[libx264 @ 0x55bf2ce415c0] 8x8 transform intra:70.3% inter:86.6%
[libx264 @ 0x55bf2ce415c0] coded y,uvDC,uvAC intra: 43.7% 69.7% 24.5%
inter: 7.3% 19.5% 1.1%
[libx264 @ 0x55bf2ce415c0] i16 v,h,dc,p: 51% 19%  8% 23%
[libx264 @ 0x55bf2ce415c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 14% 26% 
3%  3%  5%  3%  6%  3%
[libx264 @ 0x55bf2ce415c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 16% 12% 
4%  5%  7%  4%  6%  3%
[libx264 @ 0x55bf2ce415c0] i8c dc,h,v,p: 39% 17% 36%  8%
[libx264 @ 0x55bf2ce415c0] Weighted P-Frames: Y:0.7% UV:0.7%
[libx264 @ 0x55bf2ce415c0] ref P L0: 63.2% 10.5% 16.7%  9.5%  0.1%
[libx264 @ 0x55bf2ce415c0] ref B L0: 87.8%  9.4%  2.7%
[libx264 @ 0x55bf2ce415c0] ref B L1: 97.8%  2.2%
[libx264 @ 0x55bf2ce415c0] kb/s:708.14

Regards, Uwe

Am 26.12.18 um 12:44 schrieb Carl Eugen Hoyos:

>
>
>> Am 26.12.2018 um 12:23 schrieb Uwe Freese <[hidden email]>:
>> 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 SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio).
>>>>
>>>> When I crop black borders
>>> SAR is expected to change if you crop.
>>> Rounding can be different for different codecs and containers.
>> Why? The DAR, yes. But the SAR should stay the same. And it does regarding the first output from ffmpeg in the brackets.
> Yes.
> Please provide the command line you tested together with the complete, uncut console output.
>
> If your question was „why are there two SARs/DARs?“, the answer is that container and codec may contain different information: Although it is common to trust the container, this is just an arbitrary decision.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Uwe Freese
In reply to this post by Reino Wijnsma
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, which is slightly different?
> As far as I know:
>
> 688    x 64/45     = 978,49w
> 978,49 x 1575/2752 = 560h     --> 978x560 @ bitstream level
> 688    x 172/121 =   977,98w
> 977,98 x 4235/7396 = 560h     --> 977x560 @ container level

So when I understand correctly, it could be that somewhere in ffmpeg,
the 64/45 is rounded to 978, given to another function / class
calculating the SAR for the container level, and this calculates to
172/121, which is best matching for 978?

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)?

Could this be done, or is there a reason not to do that?

Regards,
Uwe

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Carl Eugen Hoyos-2
2018-12-27 10:50 GMT+01:00, Uwe Freese <[hidden email]>:

> 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, which is slightly different?
>> As far as I know:
>>
>> 688    x 64/45     = 978,49w
>> 978,49 x 1575/2752 = 560h     --> 978x560 @ bitstream level
>> 688    x 172/121 =   977,98w
>> 977,98 x 4235/7396 = 560h     --> 977x560 @ container level
>
> So when I understand correctly, it could be that somewhere in ffmpeg,
> the 64/45 is rounded to 978, given to another function / class
> calculating the SAR for the container level, and this calculates to
> 172/121, which is best matching for 978?

> 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).

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

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)?
> This is exactly what FFmpeg does (since forever).

Good. But then I totally don't understand why that 64:45 is not used and
stored at mkv container level as well.

Regards,
Uwe
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

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.

Regards,

--
  Nicolas George

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Carl Eugen Hoyos-2
In reply to this post by Uwe Freese
2018-12-27 22:25 GMT+01:00, Uwe Freese <[hidden email]>:
> 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).
>
> Good. But then I totally don't understand why that 64:45 is not used
> and stored at mkv container level as well.

Because matroska files do not store SAR.

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Question about handling / unwanted changes of SAR in ffmpeg

Uwe Freese
In reply to this post by Nicolas George
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 the answer from Carl Eugen (about MKV doesn't store SAR) covers
it already.

But what info didn't I give? I was asked for the command line and a
complete console output, which I sent (26.12. 15:13), and am not aware
of some other missing info, sorry.

Regards,
Uwe

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".