Why is format=rgb24 required after maskedmerge?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
66 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Why is format=rgb24 required after maskedmerge?

Michael Koch
Hello all,

I have a question about this script:

rem  Create red and yellow videos 300x300

c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
yellow.mp4

rem  Create a mergemap file 600x300

c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
"format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
-frames 1 -y mergemap.png

rem  Stitch two fisheye videos together to an equirectangular video,
with merging at the border

c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
"[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
-y out.mp4


This works fine and the output video looks as expected. My question is
why "format=rgb24" is required between "maskedmerge" and
"format=yuv422p". Normally two consecutive format conversions should be
unnecessary. But it doesn't work when I omit "format=rgb24". The colors
become wrong.

The console output is copied below. After I pasted the console output to
this mail, I did make a test with the latest download from Zeranoe, but
it's the same problem.

Thanks,
Michael



C:\Users\astro\Desktop\Ricoh_Theta>rem  Create red and yellow videos

C:\Users\astro\Desktop\Ricoh_Theta>c:\ffmpeg\ffmpeg -f lavfi -i
color=red:size=300x300:duration=5 -y red.mp4
ffmpeg version git-2020-06-20-29ea4e1 Copyright (c) 2000-2020 the FFmpeg
developers
   built with gcc 9.3.1 (GCC) 20200523
   configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libdav1d --enable-libbluray --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt
--enable-libtheora --enable-libtwolame --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-libgsm --disable-w32threads
--enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth --enable-libopenmpt --enable-amf
   libavutil      56. 55.100 / 56. 55.100
   libavcodec     58. 93.100 / 58. 93.100
   libavformat    58. 47.100 / 58. 47.100
   libavdevice    58. 11.100 / 58. 11.100
   libavfilter     7. 86.100 /  7. 86.100
   libswscale      5.  8.100 /  5.  8.100
   libswresample   3.  8.100 /  3.  8.100
   libpostproc    55.  8.100 / 55.  8.100
Input #0, lavfi, from 'color=red:size=300x300:duration=5':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 300x300
[SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0000011f173614c0] using SAR=1/1
[libx264 @ 0000011f173614c0] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0000011f173614c0] profile High, level 1.3, 4:2:0, 8-bit
[libx264 @ 0000011f173614c0] 264 - core 160 - H.264/MPEG-4 AVC codec -
Copyleft 2003-2020 - 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=9
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, mp4, to 'red.mp4':
   Metadata:
     encoder         : Lavf58.47.100
     Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p,
300x300 [SAR 1:1 DAR 1:1], q=-1--1, 25 fps, 12800 tbn, 25 tbc
     Metadata:
       encoder         : Lavc58.93.100 libx264
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
[Parsed_color_0 @ 0000011f17310b40] EOF timestamp not reliable
frame=  125 fps=0.0 q=-1.0 Lsize=       5kB time=00:00:04.88 bitrate=  
8.5kbits/s speed=91.2x
video:3kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 83.759773%
[libx264 @ 0000011f173614c0] frame I:1     Avg QP: 9.00  size:    71
[libx264 @ 0000011f173614c0] frame P:31    Avg QP: 9.23  size:    23
[libx264 @ 0000011f173614c0] frame B:93    Avg QP:12.67  size:    15
[libx264 @ 0000011f173614c0] consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
[libx264 @ 0000011f173614c0] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 0000011f173614c0] mb P  I16..4:  0.0%  0.0%  0.0% P16..4: 
0.0%  0.0%  0.0%  0.0%  0.0%    skip:100.0%
[libx264 @ 0000011f173614c0] mb B  I16..4:  0.0%  0.0%  0.0% B16..8: 
0.0%  0.0%  0.0%  direct: 0.0%  skip:100.0%
[libx264 @ 0000011f173614c0] 8x8 transform intra:0.0%
[libx264 @ 0000011f173614c0] coded y,uvDC,uvAC intra: 0.0% 0.3% 0.0%
inter: 0.0% 0.0% 0.0%
[libx264 @ 0000011f173614c0] i16 v,h,dc,p: 95%  0%  5%  0%
[libx264 @ 0000011f173614c0] i8c dc,h,v,p: 100%  0%  0%  0%
[libx264 @ 0000011f173614c0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000011f173614c0] kb/s:3.42

C:\Users\astro\Desktop\Ricoh_Theta>c:\ffmpeg\ffmpeg -f lavfi -i
color=yellow:size=300x300:duration=5 -y yellow.mp4
ffmpeg version git-2020-06-20-29ea4e1 Copyright (c) 2000-2020 the FFmpeg
developers
   built with gcc 9.3.1 (GCC) 20200523
   configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libdav1d --enable-libbluray --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt
--enable-libtheora --enable-libtwolame --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-libgsm --disable-w32threads
--enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth --enable-libopenmpt --enable-amf
   libavutil      56. 55.100 / 56. 55.100
   libavcodec     58. 93.100 / 58. 93.100
   libavformat    58. 47.100 / 58. 47.100
   libavdevice    58. 11.100 / 58. 11.100
   libavfilter     7. 86.100 /  7. 86.100
   libswscale      5.  8.100 /  5.  8.100
   libswresample   3.  8.100 /  3.  8.100
   libpostproc    55.  8.100 / 55.  8.100
Input #0, lavfi, from 'color=yellow:size=300x300:duration=5':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 300x300
[SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 000002d239aa1500] using SAR=1/1
[libx264 @ 000002d239aa1500] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 000002d239aa1500] profile High, level 1.3, 4:2:0, 8-bit
[libx264 @ 000002d239aa1500] 264 - core 160 - H.264/MPEG-4 AVC codec -
Copyleft 2003-2020 - 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=9
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, mp4, to 'yellow.mp4':
   Metadata:
     encoder         : Lavf58.47.100
     Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv420p,
300x300 [SAR 1:1 DAR 1:1], q=-1--1, 25 fps, 12800 tbn, 25 tbc
     Metadata:
       encoder         : Lavc58.93.100 libx264
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
[Parsed_color_0 @ 000002d239a50b80] EOF timestamp not reliable
frame=  125 fps=0.0 q=-1.0 Lsize=       5kB time=00:00:04.88 bitrate=  
8.5kbits/s speed=96.7x
video:3kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 83.759773%
[libx264 @ 000002d239aa1500] frame I:1     Avg QP: 9.00  size:    71
[libx264 @ 000002d239aa1500] frame P:31    Avg QP: 9.23  size:    23
[libx264 @ 000002d239aa1500] frame B:93    Avg QP:12.67  size:    15
[libx264 @ 000002d239aa1500] consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
[libx264 @ 000002d239aa1500] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264 @ 000002d239aa1500] mb P  I16..4:  0.0%  0.0%  0.0% P16..4: 
0.0%  0.0%  0.0%  0.0%  0.0%    skip:100.0%
[libx264 @ 000002d239aa1500] mb B  I16..4:  0.0%  0.0%  0.0% B16..8: 
0.0%  0.0%  0.0%  direct: 0.0%  skip:100.0%
[libx264 @ 000002d239aa1500] 8x8 transform intra:0.0%
[libx264 @ 000002d239aa1500] coded y,uvDC,uvAC intra: 0.0% 0.3% 0.0%
inter: 0.0% 0.0% 0.0%
[libx264 @ 000002d239aa1500] i16 v,h,dc,p: 95%  0%  5%  0%
[libx264 @ 000002d239aa1500] i8c dc,h,v,p: 100%  0%  0%  0%
[libx264 @ 000002d239aa1500] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 000002d239aa1500] kb/s:3.42

C:\Users\astro\Desktop\Ricoh_Theta>rem  Create the mergemap file

C:\Users\astro\Desktop\Ricoh_Theta>c:\ffmpeg\ffmpeg -f lavfi -i
nullsrc=size=300x300 -vf
"format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
-frames 1 -y mergemap.png
ffmpeg version git-2020-06-20-29ea4e1 Copyright (c) 2000-2020 the FFmpeg
developers
   built with gcc 9.3.1 (GCC) 20200523
   configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libdav1d --enable-libbluray --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt
--enable-libtheora --enable-libtwolame --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-libgsm --disable-w32threads
--enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth --enable-libopenmpt --enable-amf
   libavutil      56. 55.100 / 56. 55.100
   libavcodec     58. 93.100 / 58. 93.100
   libavformat    58. 47.100 / 58. 47.100
   libavdevice    58. 11.100 / 58. 11.100
   libavfilter     7. 86.100 /  7. 86.100
   libswscale      5.  8.100 /  5.  8.100
   libswresample   3.  8.100 /  3.  8.100
   libpostproc    55.  8.100 / 55.  8.100
Input #0, lavfi, from 'nullsrc=size=300x300':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 300x300
[SAR 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
   Stream #0:0 -> #0:0 (rawvideo (native) -> png (native))
Press [q] to stop, [?] for help
[swscaler @ 00000146112000c0] Warning: data is not aligned! This can
lead to a speed loss
Output #0, image2, to 'mergemap.png':
   Metadata:
     encoder         : Lavf58.47.100
     Stream #0:0: Video: png, rgb24, 600x300 [SAR 1:1 DAR 2:1], q=2-31,
200 kb/s, 25 fps, 25 tbn, 25 tbc
     Metadata:
       encoder         : Lavc58.93.100 png
frame=    1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=0.867x
video:37kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown

C:\Users\astro\Desktop\Ricoh_Theta>rem  Stitch two fisheye videos
together to an equirectangular video, with merging at the border

C:\Users\astro\Desktop\Ricoh_Theta>c:\ffmpeg\ffmpeg -i red.mp4 -i
yellow.mp4 -i mergemap.png -lavfi
"[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
-y out.mp4
ffmpeg version git-2020-06-20-29ea4e1 Copyright (c) 2000-2020 the FFmpeg
developers
   built with gcc 9.3.1 (GCC) 20200523
   configuration: --enable-gpl --enable-version3 --enable-sdl2
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass
--enable-libdav1d --enable-libbluray --enable-libfreetype
--enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt
--enable-libtheora --enable-libtwolame --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib
--enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex
--enable-libxvid --enable-libaom --enable-libgsm --disable-w32threads
--enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid
--enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2
--enable-avisynth --enable-libopenmpt --enable-amf
   libavutil      56. 55.100 / 56. 55.100
   libavcodec     58. 93.100 / 58. 93.100
   libavformat    58. 47.100 / 58. 47.100
   libavdevice    58. 11.100 / 58. 11.100
   libavfilter     7. 86.100 /  7. 86.100
   libswscale      5.  8.100 /  5.  8.100
   libswresample   3.  8.100 /  3.  8.100
   libpostproc    55.  8.100 / 55.  8.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'red.mp4':
   Metadata:
     major_brand     : isom
     minor_version   : 512
     compatible_brands: isomiso2avc1mp41
     encoder         : Lavf58.47.100
   Duration: 00:00:05.00, start: 0.000000, bitrate: 8 kb/s
     Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
300x300 [SAR 1:1 DAR 1:1], 4 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc
(default)
     Metadata:
       handler_name    : VideoHandler
Input #1, mov,mp4,m4a,3gp,3g2,mj2, from 'yellow.mp4':
   Metadata:
     major_brand     : isom
     minor_version   : 512
     compatible_brands: isomiso2avc1mp41
     encoder         : Lavf58.47.100
   Duration: 00:00:05.00, start: 0.000000, bitrate: 8 kb/s
     Stream #1:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
300x300 [SAR 1:1 DAR 1:1], 4 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc
(default)
     Metadata:
       handler_name    : VideoHandler
Input #2, png_pipe, from 'mergemap.png':
   Duration: N/A, bitrate: N/A
     Stream #2:0: Video: png, rgb24(pc), 600x300 [SAR 1:1 DAR 2:1], 25
tbr, 25 tbn, 25 tbc
Stream mapping:
   Stream #0:0 (h264) -> format
   Stream #1:0 (h264) -> format
   Stream #2:0 (png) -> maskedmerge:mask
   format -> Stream #0:0 (libx264)
Press [q] to stop, [?] for help
[libx264 @ 00000214ec828ac0] using SAR=1/1
[libx264 @ 00000214ec828ac0] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 00000214ec828ac0] profile High 4:2:2, level 2.1, 4:2:2, 8-bit
[libx264 @ 00000214ec828ac0] 264 - core 160 - H.264/MPEG-4 AVC codec -
Copyleft 2003-2020 - 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=9
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, mp4, to 'out.mp4':
   Metadata:
     major_brand     : isom
     minor_version   : 512
     compatible_brands: isomiso2avc1mp41
     encoder         : Lavf58.47.100
     Stream #0:0: Video: h264 (libx264) (avc1 / 0x31637661), yuv422p,
600x300 [SAR 1:1 DAR 2:1], q=-1--1, 25 fps, 12800 tbn, 25 tbc (default)
     Metadata:
       encoder         : Lavc58.93.100 libx264
     Side data:
       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame=  125 fps=0.0 q=-1.0 Lsize=       9kB time=00:00:04.88 bitrate= 
15.2kbits/s speed=11.4x
video:7kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 34.114582%
[libx264 @ 00000214ec828ac0] frame I:1     Avg QP:17.94  size:  3053
[libx264 @ 00000214ec828ac0] frame P:31    Avg QP:23.72  size:    33
[libx264 @ 00000214ec828ac0] frame B:93    Avg QP:30.33  size:    23
[libx264 @ 00000214ec828ac0] consecutive B-frames:  0.8%  0.0%  0.0% 99.2%
[libx264 @ 00000214ec828ac0] mb I  I16..4:  6.5% 92.5%  1.0%
[libx264 @ 00000214ec828ac0] mb P  I16..4:  0.0%  0.0%  0.0% P16..4: 
0.5%  0.0%  0.0%  0.0%  0.0%    skip:99.4%
[libx264 @ 00000214ec828ac0] mb B  I16..4:  0.0%  0.0%  0.0% B16..8: 
0.7%  0.0%  0.0%  direct: 0.0%  skip:99.3%  L0:43.5% L1:56.5% BI: 0.0%
[libx264 @ 00000214ec828ac0] 8x8 transform intra:92.3% inter:100.0%
[libx264 @ 00000214ec828ac0] coded y,uvDC,uvAC intra: 17.4% 24.7% 22.1%
inter: 0.0% 0.1% 0.0%
[libx264 @ 00000214ec828ac0] i16 v,h,dc,p: 27% 71%  2%  0%
[libx264 @ 00000214ec828ac0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 59% 30% 6% 
1%  1%  1%  1%  1%  1%
[libx264 @ 00000214ec828ac0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 57% 1% 
4%  3%  0%  4%  0%  3%
[libx264 @ 00000214ec828ac0] i8c dc,h,v,p: 72% 13% 12%  3%
[libx264 @ 00000214ec828ac0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 00000214ec828ac0] ref P L0: 88.1%  3.5%  6.5%  1.9%
[libx264 @ 00000214ec828ac0] ref B L0: 69.0% 31.0%
[libx264 @ 00000214ec828ac0] ref B L1: 97.3%  2.7%
[libx264 @ 00000214ec828ac0] kb/s:9.98


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Michael Koch
Am 18.08.2020 um 14:35 schrieb Michael Koch:

> Hello all,
>
> I have a question about this script:
>
> rem  Create red and yellow videos 300x300
>
> c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
> c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
> yellow.mp4
>
> rem  Create a mergemap file 600x300
>
> c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
> "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
> -frames 1 -y mergemap.png
>
> rem  Stitch two fisheye videos together to an equirectangular video,
> with merging at the border
>
> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
> -y out.mp4
>
>
> This works fine and the output video looks as expected. My question is
> why "format=rgb24" is required between "maskedmerge" and
> "format=yuv422p". Normally two consecutive format conversions should
> be unnecessary. But it doesn't work when I omit "format=rgb24". The
> colors become wrong.

It seems that v360 and maskedmerge change the pixel format from rgb24 to
the planar gbrp pixel format.
But why isn't it possible to convert gbrp directly to yuv422p, without
an intermediate conversion to rgb24? Is this a bug?

I suggest to add to the documentation that v360 and maskedmerge (and
possibly also other filters) change the pixel format to gbrp. As a user
I was assuming that the pixel format remains the same, unless noted
otherwise in the documentation.

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Paul B Mahol
On 8/19/20, Michael Koch <[hidden email]> wrote:

> Am 18.08.2020 um 14:35 schrieb Michael Koch:
>> Hello all,
>>
>> I have a question about this script:
>>
>> rem  Create red and yellow videos 300x300
>>
>> c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
>> c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
>> yellow.mp4
>>
>> rem  Create a mergemap file 600x300
>>
>> c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
>> "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
>>
>> -frames 1 -y mergemap.png
>>
>> rem  Stitch two fisheye videos together to an equirectangular video,
>> with merging at the border
>>
>> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
>> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
>>
>> -y out.mp4
>>
>>
>> This works fine and the output video looks as expected. My question is
>> why "format=rgb24" is required between "maskedmerge" and
>> "format=yuv422p". Normally two consecutive format conversions should
>> be unnecessary. But it doesn't work when I omit "format=rgb24". The
>> colors become wrong.
>
> It seems that v360 and maskedmerge change the pixel format from rgb24 to
> the planar gbrp pixel format.
> But why isn't it possible to convert gbrp directly to yuv422p, without
> an intermediate conversion to rgb24? Is this a bug?
>
> I suggest to add to the documentation that v360 and maskedmerge (and
> possibly also other filters) change the pixel format to gbrp. As a user
> I was assuming that the pixel format remains the same, unless noted
> otherwise in the documentation.

You are deeply confused about our filters.
Any filter can change pixel formats to one that they accepts thus gbrp
is picked instead of packed rgb, this is already documented
implicitly.
Your mergemap is produced in rgb24 pixel format and it only work with
rgb pixel formats otherwise you get wrong output from maskedmerge.
If it does not work with yuv444p pixel formats either than you have
bigger problem, otherwise it is giving bad output as yuv422p is
subsampled pixel format and thus you need to create different mergemap
equation per plane. As for 3rd and 2nd plane of yuv422p pixel format
have half of width and same height as first plane.

>
> Michael
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Michael Koch
Am 19.08.2020 um 16:34 schrieb Paul B Mahol:

> On 8/19/20, Michael Koch <[hidden email]> wrote:
>> Am 18.08.2020 um 14:35 schrieb Michael Koch:
>>> Hello all,
>>>
>>> I have a question about this script:
>>>
>>> rem  Create red and yellow videos 300x300
>>>
>>> c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y red.mp4
>>> c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
>>> yellow.mp4
>>>
>>> rem  Create a mergemap file 600x300
>>>
>>> c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
>>> "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
>>>
>>> -frames 1 -y mergemap.png
>>>
>>> rem  Stitch two fisheye videos together to an equirectangular video,
>>> with merging at the border
>>>
>>> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
>>> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
>>>
>>> -y out.mp4
>>>
>>>
>>> This works fine and the output video looks as expected. My question is
>>> why "format=rgb24" is required between "maskedmerge" and
>>> "format=yuv422p". Normally two consecutive format conversions should
>>> be unnecessary. But it doesn't work when I omit "format=rgb24". The
>>> colors become wrong.
>> It seems that v360 and maskedmerge change the pixel format from rgb24 to
>> the planar gbrp pixel format.
>> But why isn't it possible to convert gbrp directly to yuv422p, without
>> an intermediate conversion to rgb24? Is this a bug?
>>
>> I suggest to add to the documentation that v360 and maskedmerge (and
>> possibly also other filters) change the pixel format to gbrp. As a user
>> I was assuming that the pixel format remains the same, unless noted
>> otherwise in the documentation.
> You are deeply confused about our filters.
> Any filter can change pixel formats to one that they accepts thus gbrp
> is picked instead of packed rgb, this is already documented
> implicitly.

It would be very helpful to find in the documentation for each filter a
list of the accepted input pixel formats, and it's also a useful
information if a filter is capable of changing the pixel format. Or can
all filters change the pixel format?

> Your mergemap is produced in rgb24 pixel format and it only work with
> rgb pixel formats otherwise you get wrong output from maskedmerge.

OK, understood. I converted the mergemap to gbrp and now it works fine.
In my opinion the whole thing is badly documented.
On one hand, the filter does automatically change the first two inputs
to a format that it accepts, in this case gbrp.
On the other hand, the filter is unable to automatically change the
third input to the same pixel format, which is the only pixel format
that works.

Do you agree that this is the correct workflow?
1. Insert a showinfo filter after maskedmerge and check the pixel format.
2. Insert a format conversion in the filter chain that converts the
mergemap to the same pixel format as found in step 1.

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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
|

"documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Jim DeLaHunt-2
In reply to this post by Paul B Mahol
On 2020-08-19 07:34, Paul B Mahol wrote:
> You are deeply confused about our filters.
> Any filter can change pixel formats to one that they accepts thus gbrp
> is picked instead of packed rgb, this is already documented
> implicitly.

Wow, "documented implicitly". This is such a classic FFmpeg project
statement. The role of documentation is to explain, explicitly, at a
suitable level of detail. What does "documented implicitly" even mean?

I think this thread points out is that FFmpeg documentation is
inadequate. It is hard to prove a negative, but I suspect that the term
"pixel format" is not actually defined in the FFmpeg documentation. I
suspect that the statement, "Any filter can change pixel formats" is not
stated either. Certainly the maskedmerge filter documentation[1] doesn't
mention pixel formats at all, much less say what pixel formats the
filter sets for its output.

I have attempted to improve the documentation, to make it explain
explicitly instead of fail to document. I encountered a great deal of
resistance to those patches, because they make the documentation more
explicit, because they have more words, and because documentation has so
little value in this project relative to executable code.

And yet "You are deeply confused about our filters". In other words, the
documentation has failed to explain to you what FFmpeg does, the project
has failed to write or welcome improved documentation, you do not
understand how FFmpeg works — and somehow this is your fault.

[1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Paul B Mahol
On 8/19/20, Jim DeLaHunt <[hidden email]> wrote:

> On 2020-08-19 07:34, Paul B Mahol wrote:
>> You are deeply confused about our filters.
>> Any filter can change pixel formats to one that they accepts thus gbrp
>> is picked instead of packed rgb, this is already documented
>> implicitly.
>
> Wow, "documented implicitly". This is such a classic FFmpeg project
> statement. The role of documentation is to explain, explicitly, at a
> suitable level of detail. What does "documented implicitly" even mean?
>
> I think this thread points out is that FFmpeg documentation is
> inadequate. It is hard to prove a negative, but I suspect that the term
> "pixel format" is not actually defined in the FFmpeg documentation. I
> suspect that the statement, "Any filter can change pixel formats" is not
> stated either. Certainly the maskedmerge filter documentation[1] doesn't
> mention pixel formats at all, much less say what pixel formats the
> filter sets for its output.
>
> I have attempted to improve the documentation, to make it explain
> explicitly instead of fail to document. I encountered a great deal of
> resistance to those patches, because they make the documentation more
> explicit, because they have more words, and because documentation has so
> little value in this project relative to executable code.
>
> And yet "You are deeply confused about our filters". In other words, the
> documentation has failed to explain to you what FFmpeg does, the project
> has failed to write or welcome improved documentation, you do not
> understand how FFmpeg works — and somehow this is your fault.

http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1

mention it explicitly:

Libavfilter will automatically insert scale filters where format
conversion is required. It is possible to specify swscale flags for
those automatically inserted scalers by prepending sws_flags=flags; to
the filtergraph description.

>
> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Carl Eugen Hoyos-2
In reply to this post by Michael Koch
Am Di., 18. Aug. 2020 um 14:44 Uhr schrieb Michael Koch
<[hidden email]>:

> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
> -y out.mp4
>
>
> This works fine and the output video looks as expected. My
> question is why "format=rgb24" is required

I believe it was already explained why it really is required in this case.

Also important to mention imo is that in general, the automatic pix_fmt
conversion cannot always succeed, the system as a whole is not and
cannot be clairvoyant.
Therefore, for a sufficiently complex filter-chain, you have to force
conversions with format because without it, the conversion decisions
may be wrong (or at least not optimal).

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Paul B Mahol
In reply to this post by Michael Koch
On 8/19/20, Michael Koch <[hidden email]> wrote:

> Am 19.08.2020 um 16:34 schrieb Paul B Mahol:
>> On 8/19/20, Michael Koch <[hidden email]> wrote:
>>> Am 18.08.2020 um 14:35 schrieb Michael Koch:
>>>> Hello all,
>>>>
>>>> I have a question about this script:
>>>>
>>>> rem  Create red and yellow videos 300x300
>>>>
>>>> c:\ffmpeg\ffmpeg -f lavfi -i color=red:size=300x300:duration=5 -y
>>>> red.mp4
>>>> c:\ffmpeg\ffmpeg -f lavfi -i color=yellow:size=300x300:duration=5 -y
>>>> yellow.mp4
>>>>
>>>> rem  Create a mergemap file 600x300
>>>>
>>>> c:\ffmpeg\ffmpeg -f lavfi -i nullsrc=size=300x300 -vf
>>>> "format=gray8,geq='clip(128-128/10*(180-200/150*hypot(X-150,Y-150)),0,255)',v360=input=fisheye:output=e:ih_fov=200:iv_fov=200,format=rgb24"
>>>>
>>>> -frames 1 -y mergemap.png
>>>>
>>>> rem  Stitch two fisheye videos together to an equirectangular video,
>>>> with merging at the border
>>>>
>>>> c:\ffmpeg\ffmpeg -i red.mp4 -i yellow.mp4 -i mergemap.png -lavfi
>>>> "[0]format=rgb24,v360=input=fisheye:output=e:ih_fov=200:iv_fov=200[a];[1]format=rgb24,v360=input=fisheye:output=e:yaw=180:ih_fov=200:iv_fov=200[b];[a][b][2]maskedmerge,format=rgb24,format=yuv422p"
>>>>
>>>> -y out.mp4
>>>>
>>>>
>>>> This works fine and the output video looks as expected. My question is
>>>> why "format=rgb24" is required between "maskedmerge" and
>>>> "format=yuv422p". Normally two consecutive format conversions should
>>>> be unnecessary. But it doesn't work when I omit "format=rgb24". The
>>>> colors become wrong.
>>> It seems that v360 and maskedmerge change the pixel format from rgb24 to
>>> the planar gbrp pixel format.
>>> But why isn't it possible to convert gbrp directly to yuv422p, without
>>> an intermediate conversion to rgb24? Is this a bug?
>>>
>>> I suggest to add to the documentation that v360 and maskedmerge (and
>>> possibly also other filters) change the pixel format to gbrp. As a user
>>> I was assuming that the pixel format remains the same, unless noted
>>> otherwise in the documentation.
>> You are deeply confused about our filters.
>> Any filter can change pixel formats to one that they accepts thus gbrp
>> is picked instead of packed rgb, this is already documented
>> implicitly.
>
> It would be very helpful to find in the documentation for each filter a
> list of the accepted input pixel formats, and it's also a useful
> information if a filter is capable of changing the pixel format. Or can
> all filters change the pixel format?
>
>> Your mergemap is produced in rgb24 pixel format and it only work with
>> rgb pixel formats otherwise you get wrong output from maskedmerge.
>
> OK, understood. I converted the mergemap to gbrp and now it works fine.
> In my opinion the whole thing is badly documented.

If input is in yuv422p that you want to be filtered than mergemap
needs to be in yuv422p too.

> On one hand, the filter does automatically change the first two inputs
> to a format that it accepts, in this case gbrp.
> On the other hand, the filter is unable to automatically change the
> third input to the same pixel format, which is the only pixel format
> that works.
>
> Do you agree that this is the correct workflow?
> 1. Insert a showinfo filter after maskedmerge and check the pixel format.

Just use -v debug, it will show whenever scale/format filter is auto inserted.
It may be to spammy with unrelated messages from other components.

There is patch in preparation to disable all auto conversions in filtergraph,
than you are on your own to fix any issues if you enable such flag.

> 2. Insert a format conversion in the filter chain that converts the
> mergemap to the same pixel format as found in step 1.

That is useful only when you disable auto conversion with flag that
gonna be added (I hope soon) to lavfi.

>
> Michael
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Carl Eugen Hoyos-2
Am Mi., 19. Aug. 2020 um 19:59 Uhr schrieb Paul B Mahol <[hidden email]>:

> > 1. Insert a showinfo filter after maskedmerge and check the pixel format.
>
> Just use -v debug, it will show whenever scale/format filter is auto inserted.

Luckily, -v verbose is sufficient.

(I'd like to add that the extremely important information about automatic
scale filter insertion was originally shown with default verbosity, I always
wanted to restore this behaviour and wonder now who changed it...)

Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Jim DeLaHunt-2
In reply to this post by Paul B Mahol
On 2020-08-19 10:53, Paul B Mahol wrote:

> On 8/19/20, Jim DeLaHunt <[hidden email]> wrote:
>> On 2020-08-19 07:34, Paul B Mahol wrote:
>>> You are deeply confused about our filters.
>>> Any filter can change pixel formats to one that they accepts thus gbrp
>>> is picked instead of packed rgb, this is already documented
>>> implicitly.
>> Wow, "documented implicitly". This is such a classic FFmpeg project
>> statement. The role of documentation is to explain, explicitly, at a
>> suitable level of detail. What does "documented implicitly" even mean?
>>
>> I think this thread points out is that FFmpeg documentation is
>> inadequate. It is hard to prove a negative, but I suspect that the term
>> "pixel format" is not actually defined in the FFmpeg documentation. I
>> suspect that the statement, "Any filter can change pixel formats" is not
>> stated either. Certainly the maskedmerge filter documentation[1] doesn't
>> mention pixel formats at all, much less say what pixel formats the
>> filter sets for its output.
>>
>> …And yet "You are deeply confused about our filters". In other words, the
>> documentation has failed to explain to you what FFmpeg does, the project
>> has failed to write or welcome improved documentation, you do not
>> understand how FFmpeg works — and somehow this is your fault.
> http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1
>
> mention it explicitly:
>
> Libavfilter will automatically insert scale filters where format
> conversion is required. It is possible to specify swscale flags for
> those automatically inserted scalers by prepending sws_flags=flags; to
> the filtergraph description.


This continues to be a great example of the FFmpeg project's approach to
documentation.

1. A sentence about a library adding functional processing steps ("scale
filters") in buried in a section entitled "syntax", amid paragraphs
about syntax.

2. the "scale filters" name alludes to changing pixel counts, and the
linked-to filter documentation[2] talks about "(resize) the input video"
and about "the input image format" (without defining that term); it does
not have a parameter for pixel formats or document the pixel formats it
uses or sets or changes.

3. this reference to "scale filters" is supposed to be responsive to a
thread about pixel formats.

4. no acknowledgement that the documentation might actually be less than
perfect. Is it so hard to concede, "you have a point, the docs could be
better here"?

[1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
[2] http://ffmpeg.org/ffmpeg-filters.html#scale


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Paul B Mahol
On 8/19/20, Jim DeLaHunt <[hidden email]> wrote:

> On 2020-08-19 10:53, Paul B Mahol wrote:
>> On 8/19/20, Jim DeLaHunt <[hidden email]> wrote:
>>> On 2020-08-19 07:34, Paul B Mahol wrote:
>>>> You are deeply confused about our filters.
>>>> Any filter can change pixel formats to one that they accepts thus gbrp
>>>> is picked instead of packed rgb, this is already documented
>>>> implicitly.
>>> Wow, "documented implicitly". This is such a classic FFmpeg project
>>> statement. The role of documentation is to explain, explicitly, at a
>>> suitable level of detail. What does "documented implicitly" even mean?
>>>
>>> I think this thread points out is that FFmpeg documentation is
>>> inadequate. It is hard to prove a negative, but I suspect that the term
>>> "pixel format" is not actually defined in the FFmpeg documentation. I
>>> suspect that the statement, "Any filter can change pixel formats" is not
>>> stated either. Certainly the maskedmerge filter documentation[1] doesn't
>>> mention pixel formats at all, much less say what pixel formats the
>>> filter sets for its output.
>>>
>>> …And yet "You are deeply confused about our filters". In other words, the
>>> documentation has failed to explain to you what FFmpeg does, the project
>>> has failed to write or welcome improved documentation, you do not
>>> understand how FFmpeg works — and somehow this is your fault.
>> http://ffmpeg.org/ffmpeg-filters.html#toc-Filtergraph-syntax-1
>>
>> mention it explicitly:
>>
>> Libavfilter will automatically insert scale filters where format
>> conversion is required. It is possible to specify swscale flags for
>> those automatically inserted scalers by prepending sws_flags=flags; to
>> the filtergraph description.
>
>
> This continues to be a great example of the FFmpeg project's approach to
> documentation.
>
> 1. A sentence about a library adding functional processing steps ("scale
> filters") in buried in a section entitled "syntax", amid paragraphs
> about syntax.
>
> 2. the "scale filters" name alludes to changing pixel counts, and the
> linked-to filter documentation[2] talks about "(resize) the input video"
> and about "the input image format" (without defining that term); it does
> not have a parameter for pixel formats or document the pixel formats it
> uses or sets or changes.
>
> 3. this reference to "scale filters" is supposed to be responsive to a
> thread about pixel formats.
>
> 4. no acknowledgement that the documentation might actually be less than
> perfect. Is it so hard to concede, "you have a point, the docs could be
> better here"?
>
> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
> [2] http://ffmpeg.org/ffmpeg-filters.html#scale


Well than sentence needs to be completely rewritten since we have
audio support too.

>
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Nicolas George
In reply to this post by Carl Eugen Hoyos-2
Carl Eugen Hoyos (12020-08-19):
> (I'd like to add that the extremely important information about automatic
> scale filter insertion was originally shown with default verbosity, I always
> wanted to restore this behaviour and wonder now who changed it...)

commit 1a49a169eb74a978eb7b2a4f2caf3520b7741ee5
Author: Anton Khirnov <[hidden email]>
Date:   2012-06-25 06:31:38 +0200

    lavfi: make filters less verbose.

[...]
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index b550169468..dc828153f9 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -101,7 +101,7 @@ int avfilter_insert_filter(AVFilterLink *link, AVFilterContext *filt,
     int ret;
     unsigned dstpad_idx = link->dstpad - link->dst->input_pads;
 
-    av_log(link->dst, AV_LOG_INFO, "auto-inserting filter '%s' "
+    av_log(link->dst, AV_LOG_VERBOSE, "auto-inserting filter '%s' "
            "between the filter '%s' and the filter '%s'\n",
            filt->name, link->src->name, link->dst->name);
 
Restoring the verbosity would probably be a good idea. You may want to
review the rest of the changes in this patch.

Regards,

--
  Nicolas George

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: Why is format=rgb24 required after maskedmerge?

Carl Eugen Hoyos-2
Am Mi., 19. Aug. 2020 um 22:48 Uhr schrieb Nicolas George <[hidden email]>:

>
> Carl Eugen Hoyos (12020-08-19):
> > (I'd like to add that the extremely important information about automatic
> > scale filter insertion was originally shown with default verbosity, I always
> > wanted to restore this behaviour and wonder now who changed it...)
>
> commit 1a49a169eb74a978eb7b2a4f2caf3520b7741ee5
> Author: Anton Khirnov <[hidden email]>
> Date:   2012-06-25 06:31:38 +0200
>
>     lavfi: make filters less verbose.
>
> [...]
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index b550169468..dc828153f9 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -101,7 +101,7 @@ int avfilter_insert_filter(AVFilterLink *link, AVFilterContext *filt,
>      int ret;
>      unsigned dstpad_idx = link->dstpad - link->dst->input_pads;
>
> -    av_log(link->dst, AV_LOG_INFO, "auto-inserting filter '%s' "
> +    av_log(link->dst, AV_LOG_VERBOSE, "auto-inserting filter '%s' "
>             "between the filter '%s' and the filter '%s'\n",
>             filt->name, link->src->name, link->dst->name);

How unsurprising.

Sorry for being right, Carl Eugen
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Mark Filipak
In reply to this post by Jim DeLaHunt-2
On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:

> On 2020-08-19 07:34, Paul B Mahol wrote:
>> You are deeply confused about our filters.
>> Any filter can change pixel formats to one that they accepts thus gbrp
>> is picked instead of packed rgb, this is already documented
>> implicitly.
>
> Wow, "documented implicitly". This is such a classic FFmpeg project statement. The role of
> documentation is to explain, explicitly, at a suitable level of detail. What does "documented
> implicitly" even mean?
>
> I think this thread points out is that FFmpeg documentation is inadequate. It is hard to prove a
> negative, but I suspect that the term "pixel format" is not actually defined in the FFmpeg
> documentation. I suspect that the statement, "Any filter can change pixel formats" is not stated
> either. Certainly the maskedmerge filter documentation[1] doesn't mention pixel formats at all, much
> less say what pixel formats the filter sets for its output.
>
> I have attempted to improve the documentation, to make it explain explicitly instead of fail to
> document. I encountered a great deal of resistance to those patches, because they make the
> documentation more explicit, because they have more words, and because documentation has so little
> value in this project relative to executable code.
>
> And yet "You are deeply confused about our filters". In other words, the documentation has failed to
> explain to you what FFmpeg does, the project has failed to write or welcome improved documentation,
> you do not understand how FFmpeg works — and somehow this is your fault.
>
> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge

I have a theory, Jim. I think the developers don't document things (or comment their code) for 2
reasons: 1, They want to be able to change methods and behaviors without having to maintain
documentation, and 2, They want to make money doing consulting jobs for people who commit ffmpeg for
their projects, then give up trying to write ffmpeg command lines.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Paul B Mahol
On 8/20/20, Mark Filipak <[hidden email]> wrote:

> On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
>> On 2020-08-19 07:34, Paul B Mahol wrote:
>>> You are deeply confused about our filters.
>>> Any filter can change pixel formats to one that they accepts thus gbrp
>>> is picked instead of packed rgb, this is already documented
>>> implicitly.
>>
>> Wow, "documented implicitly". This is such a classic FFmpeg project
>> statement. The role of
>> documentation is to explain, explicitly, at a suitable level of detail.
>> What does "documented
>> implicitly" even mean?
>>
>> I think this thread points out is that FFmpeg documentation is inadequate.
>> It is hard to prove a
>> negative, but I suspect that the term "pixel format" is not actually
>> defined in the FFmpeg
>> documentation. I suspect that the statement, "Any filter can change pixel
>> formats" is not stated
>> either. Certainly the maskedmerge filter documentation[1] doesn't mention
>> pixel formats at all, much
>> less say what pixel formats the filter sets for its output.
>>
>> I have attempted to improve the documentation, to make it explain
>> explicitly instead of fail to
>> document. I encountered a great deal of resistance to those patches,
>> because they make the
>> documentation more explicit, because they have more words, and because
>> documentation has so little
>> value in this project relative to executable code.
>>
>> And yet "You are deeply confused about our filters". In other words, the
>> documentation has failed to
>> explain to you what FFmpeg does, the project has failed to write or
>> welcome improved documentation,
>> you do not understand how FFmpeg works — and somehow this is your fault.
>>
>> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
>
> I have a theory, Jim. I think the developers don't document things (or
> comment their code) for 2
> reasons: 1, They want to be able to change methods and behaviors without
> having to maintain
> documentation, and 2, They want to make money doing consulting jobs for
> people who commit ffmpeg for
> their projects, then give up trying to write ffmpeg command lines.

Your both theories are fully correct. They want to make money for living.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

FFmpeg-users mailing list
 > Your both theories are fully correct. They want to make money for living.
That's perfectly fine, but at least admit it, and stop trying to defend the indefensible (and then claim it's all about open source egalitarianism, when it emphatically isn't.)
For what it's worth this has been obvious for years.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".  
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Mark Filipak
In reply to this post by Paul B Mahol
On 08/20/2020 02:59 AM, Paul B Mahol wrote:

> On 8/20/20, Mark Filipak <[hidden email]> wrote:
>> On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
>>> On 2020-08-19 07:34, Paul B Mahol wrote:
>>>> You are deeply confused about our filters.
>>>> Any filter can change pixel formats to one that they accepts thus gbrp
>>>> is picked instead of packed rgb, this is already documented
>>>> implicitly.
>>>
>>> Wow, "documented implicitly". This is such a classic FFmpeg project
>>> statement. The role of
>>> documentation is to explain, explicitly, at a suitable level of detail.
>>> What does "documented
>>> implicitly" even mean?
>>>
>>> I think this thread points out is that FFmpeg documentation is inadequate.
>>> It is hard to prove a
>>> negative, but I suspect that the term "pixel format" is not actually
>>> defined in the FFmpeg
>>> documentation. I suspect that the statement, "Any filter can change pixel
>>> formats" is not stated
>>> either. Certainly the maskedmerge filter documentation[1] doesn't mention
>>> pixel formats at all, much
>>> less say what pixel formats the filter sets for its output.
>>>
>>> I have attempted to improve the documentation, to make it explain
>>> explicitly instead of fail to
>>> document. I encountered a great deal of resistance to those patches,
>>> because they make the
>>> documentation more explicit, because they have more words, and because
>>> documentation has so little
>>> value in this project relative to executable code.
>>>
>>> And yet "You are deeply confused about our filters". In other words, the
>>> documentation has failed to
>>> explain to you what FFmpeg does, the project has failed to write or
>>> welcome improved documentation,
>>> you do not understand how FFmpeg works — and somehow this is your fault.
>>>
>>> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
>>
>> I have a theory, Jim. I think the developers don't document things (or
>> comment their code) for 2
>> reasons: 1, They want to be able to change methods and behaviors without
>> having to maintain
>> documentation, and 2, They want to make money doing consulting jobs for
>> people who commit ffmpeg for
>> their projects, then give up trying to write ffmpeg command lines.
>
> Your both theories are fully correct. They want to make money for living.

Of course. You all need to make a living. But is frustrating users, including potential clients, the
way to do it? Before I retired, I ran quite a few projects in many companies. We never minded
spending money. Meeting schedules and objectives were always more important than saving money by
doing jobs in-house. What we wanted most was smooth project development with predictable costs and
reliable results. Cooperative, forthcoming people are worth their weights in Gold and usually result
in follow-on jobs and recommendations to others. But what's going on here just sours potential
clients. How wants to hire a consultant who jerks people around?

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Nicolas George
Mark Filipak (12020-08-20):
> Of course. You all need to make a living.

Some of us make a living completely differently and contribute to FFmpeg
on a purely voluntary basis.

> But is frustrating users, including potential clients,

FFmpeg has no clients.

> Before I retired, I ran quite a few projects in many companies. We
> never minded spending money. Meeting schedules and objectives were
> always more important than saving money by doing jobs in-house.

For us, the most important is code quality.

Your conspiracy theories about the motivation for poor documentation are
ridiculous. The reasons for it are straightforward: documentation is
boring, and when we already know stuff it is hard to guess what people
need to be told.

If you want to help improve the documentation, learn how to properly use
the project and then write it as you would have wanted it to be
explained.

--
  Nicolas George

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Alexander Strasser
In reply to this post by Mark Filipak
On 2020-08-19 22:14 -0400, Mark Filipak wrote:

> On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
> > On 2020-08-19 07:34, Paul B Mahol wrote:
> > > You are deeply confused about our filters.
> > > Any filter can change pixel formats to one that they accepts thus gbrp
> > > is picked instead of packed rgb, this is already documented
> > > implicitly.
> >
> > Wow, "documented implicitly". This is such a classic FFmpeg project
> > statement. The role of documentation is to explain, explicitly, at a
> > suitable level of detail. What does "documented implicitly" even mean?
> >
> > I think this thread points out is that FFmpeg documentation is
> > inadequate. It is hard to prove a negative, but I suspect that the term
> > "pixel format" is not actually defined in the FFmpeg documentation. I
> > suspect that the statement, "Any filter can change pixel formats" is not
> > stated either. Certainly the maskedmerge filter documentation[1] doesn't
> > mention pixel formats at all, much less say what pixel formats the
> > filter sets for its output.
> >
> > I have attempted to improve the documentation, to make it explain
> > explicitly instead of fail to document. I encountered a great deal of
> > resistance to those patches, because they make the documentation more
> > explicit, because they have more words, and because documentation has so
> > little value in this project relative to executable code.
> >
> > And yet "You are deeply confused about our filters". In other words, the
> > documentation has failed to explain to you what FFmpeg does, the project
> > has failed to write or welcome improved documentation, you do not
> > understand how FFmpeg works — and somehow this is your fault.
> >
> > [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge

There are some good points mentioned above.


> I have a theory, Jim. I think the developers don't document things (or
> comment their code) for 2 reasons: 1, They want to be able to change methods
> and behaviors without having to maintain documentation, and 2, They want to
> make money doing consulting jobs for people who commit ffmpeg for their
> projects, then give up trying to write ffmpeg command lines.

This conclusion however is way to unbalanced.

I will bring up a point that has become clear to me.

Good documentation in general and especially for software is
incredibly hard to write and get right!

In general you have to be a good writer and have sufficient
insight into the tech you are documenting. And this means for
FFmpeg you need to understand C enough, so you can roughly
read the code and are able to ask the right questions.

You need to have enough multimedia knowledge and experience
so you can try things yourself and write things in sufficiently
understood language.

You need to cope with (gradual and sometimes sweeping) change and
especially for projects like FFmpeg that means big restructurings
in the documentation every so often.


  Alexander
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://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: "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

Mark Filipak
On 08/20/2020 12:03 PM, Alexander Strasser wrote:

> On 2020-08-19 22:14 -0400, Mark Filipak wrote:
>> On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
>>> On 2020-08-19 07:34, Paul B Mahol wrote:
>>>> You are deeply confused about our filters.
>>>> Any filter can change pixel formats to one that they accepts thus gbrp
>>>> is picked instead of packed rgb, this is already documented
>>>> implicitly.
>>>
>>> Wow, "documented implicitly". This is such a classic FFmpeg project
>>> statement. The role of documentation is to explain, explicitly, at a
>>> suitable level of detail. What does "documented implicitly" even mean?
>>>
>>> I think this thread points out is that FFmpeg documentation is
>>> inadequate. It is hard to prove a negative, but I suspect that the term
>>> "pixel format" is not actually defined in the FFmpeg documentation. I
>>> suspect that the statement, "Any filter can change pixel formats" is not
>>> stated either. Certainly the maskedmerge filter documentation[1] doesn't
>>> mention pixel formats at all, much less say what pixel formats the
>>> filter sets for its output.
>>>
>>> I have attempted to improve the documentation, to make it explain
>>> explicitly instead of fail to document. I encountered a great deal of
>>> resistance to those patches, because they make the documentation more
>>> explicit, because they have more words, and because documentation has so
>>> little value in this project relative to executable code.
>>>
>>> And yet "You are deeply confused about our filters". In other words, the
>>> documentation has failed to explain to you what FFmpeg does, the project
>>> has failed to write or welcome improved documentation, you do not
>>> understand how FFmpeg works — and somehow this is your fault.
>>>
>>> [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge
>
> There are some good points mentioned above.
>
>
>> I have a theory, Jim. I think the developers don't document things (or
>> comment their code) for 2 reasons: 1, They want to be able to change methods
>> and behaviors without having to maintain documentation, and 2, They want to
>> make money doing consulting jobs for people who commit ffmpeg for their
>> projects, then give up trying to write ffmpeg command lines.
>
> This conclusion however is way to unbalanced.
>
> I will bring up a point that has become clear to me.
>
> Good documentation in general and especially for software is
> incredibly hard to write and get right!

No, it's not. Or rather, it shouldn't be.

> In general you have to be a good writer and have sufficient
> insight into the tech you are documenting. And this means for
> FFmpeg you need to understand C enough, so you can roughly
> read the code and are able to ask the right questions.

Coders should not write documentation. Coders should write comments in their code. Documentarians
should write the documentation.

Software engineering teachers drum into their students the importance of top-down design for a
reason. Anything else is just code hacking: The coder punches into a problem at the point where
he/she knows the most or has the kernel of an idea, and then builds the code out from there. That's
not good practice, but it's what's done all too often. Code hackers don't write documentation
because they don't know where they're headed.

Top-down design begins with documentation: A description of the intended structures and processing.
For the coders who worked for me, I wrote the initial documentation which they followed as they
implemented the code.

For example, the comments in a routine that parses macroblocks shouldn't teach people about the care
and feeding of macroblocks. It should simply make plain-language statements about what it does, what
it looks for, what 'states' it enters/leaves, and why.

Coders don't need to be good writers. They just need to comment their code to detail the logic in
plain language. Documentarians do need to be good writers, but they don't need to be coders (or, at
least, they don't need to be coders in the target language -- though that does help). Most of all,
they do need to be logicians. And they need to have access to the coders and they need to take the
lead in design reviews. That assumes that there are design reviews, but that's often not the case in
informal organizations like ffmpeg.

> You need to have enough multimedia knowledge and experience
> so you can try things yourself and write things in sufficiently
> understood language.

The documentarian must have thorough knowledge of the subject. That is true. There's no alternative.
For video, the documentarian must be a video expert.

> You need to cope with (gradual and sometimes sweeping) change and
> especially for projects like FFmpeg that means big restructurings
> in the documentation every so often.

Complete rewrites are very rare. Even if a project is a complete rewrite, the steps are the same.
There should be no mysteries.

Coders should not write documentation.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

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