Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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)? >> 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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: PGP signature ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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) mean in the brackets compared to the second SAR >>> 172:121, which is slightly different? >> As far as I know: >> >> 688x 64/45 = 978,49w >> 978,49 x 1575/2752 = 560h --> 978x560 @ bitstream level >> 688x 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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: 688x 64/45 = 978,49w 978,49 x 1575/2752 = 560h --> 978x560 @ bitstream level 688x 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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.00, 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,2 Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s (default) Metadata: DURATION : 00:00:52,21900 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,2 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%
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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, which is slightly different? As far as I know: 688x 64/45 = 978,49w 978,49 x 1575/2752 = 560h --> 978x560 @ bitstream level 688x 172/121 = 977,98w 977,98 x 4235/7396 = 560h --> 977x560 @ container level -- Reino ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
> 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. 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
> 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 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 > 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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
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 ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
