lagfun misunderstanding?

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

lagfun misunderstanding?

Zedsquared
Hi Folks,
     I'm exploring the lagfun filter and think I may have some fundamental
misunderstanding as I'm not getting the results I expect.

I have a video of green lasers on glassware in the dark and wish to make the
laser flashes persist.
My attempts so far seem to result in the green flashes persisting as white,
however.

I tried this command which I think  should do this:
Take the YUV input video, split it into RGB, run lagfun on only the green
content, save resulting output.

ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2 -filter:v
format=pix_fmts=rgb24,lagfun=decay=0.999 greenlagtest.mp4

Input file is here: http://www.robinbussell.co.uk/mov/IMG_1685.MOV  (far too
much camera movement, I know!)
Output here: http://www.robinbussell.co.uk/mov/greenlagtest.mp4

Console output is:

ffmpeg version 4.2.2-1build1~18.04.sav0 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
  configuration: --prefix=/usr --extra-version='1build1~18.04.sav0'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl
--disable-stripping --enable-avresample --disable-filter=resample
--enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig
--enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame
--enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal
--enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r
--enable-libx264 --enable-shared
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'IMG_1685.MOV':
  Metadata:
    major_brand     : qt
    minor_version   : 0
    compatible_brands: qt
    creation_time   : 2020-03-28T12:20:59.000000Z
  Duration: 00:00:18.53, start: 0.000000, bitrate: 3829 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv,
bt709), 1280x720, 3823 kb/s, 60.01 fps, 60 tbr, 600 tbn, 1200 tbc (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Video
      encoder         : H.264
    Stream #0:1(und): Data: none (mebx / 0x7862656D), 0 kb/s (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Metadata
    Stream #0:2(und): Data: none (mebx / 0x7862656D), 0 kb/s (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Metadata
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x55a16881aec0] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x55a16881aec0] profile High 4:4:4 Predictive, level 3.2, 4:4:4
8-bit
[libx264 @ 0x55a16881aec0] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC
codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options:
cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1
psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0
cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12
lookahead_threads=2 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 'greenlagtest.mp4':
  Metadata:
    major_brand     : qt
    minor_version   : 0
    compatible_brands: qt
    encoder         : Lavf58.29.100
    Stream #0:0(und): Video: h264 (libx264) (avc1 / 0x31637661), yuv444p,
1280x720, q=-1--1, 60 fps, 15360 tbn, 60 tbc (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Video
      encoder         : Lavc58.54.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame= 1112 fps= 50 q=-1.0 Lsize=    6912kB time=00:00:18.48
bitrate=3063.4kbits/s speed=0.833x
video:6905kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.101704%
[libx264 @ 0x55a16881aec0] frame I:5     Avg QP:22.29  size: 50576
[libx264 @ 0x55a16881aec0] frame P:968   Avg QP:25.09  size:  6873
[libx264 @ 0x55a16881aec0] frame B:139   Avg QP:24.68  size:  1178
[libx264 @ 0x55a16881aec0] consecutive B-frames: 81.5%  4.1%  4.3% 10.1%
[libx264 @ 0x55a16881aec0] mb I  I16..4: 54.6%  0.0% 45.4%
[libx264 @ 0x55a16881aec0] mb P  I16..4:  4.5%  0.0%  0.7%  P16..4: 36.1%
6.4%  5.3%  0.0%  0.0%    skip:46.9%
[libx264 @ 0x55a16881aec0] mb B  I16..4:  0.6%  0.0%  0.0%  B16..8: 25.8%
0.6%  0.2%  direct: 0.3%  skip:72.4%  L0:29.9% L1:69.0% BI: 1.1%
[libx264 @ 0x55a16881aec0] coded y,u,v intra: 12.4% 1.8% 1.2% inter: 7.0%
1.6% 0.7%
[libx264 @ 0x55a16881aec0] i16 v,h,dc,p: 51% 26% 18%  5%
[libx264 @ 0x55a16881aec0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 19% 32%  5%
6%  5%  6%  4%  5%
[libx264 @ 0x55a16881aec0] Weighted P-Frames: Y:2.9% UV:0.7%
[libx264 @ 0x55a16881aec0] ref P L0: 39.8% 52.2%  5.6%  2.3%  0.1%
[libx264 @ 0x55a16881aec0] ref B L0: 88.5%  9.1%  2.4%
[libx264 @ 0x55a16881aec0] ref B L1: 97.8%  2.2%
[libx264 @ 0x55a16881aec0] kb/s:3051.71



I can cheat by putting a colorbalance section afterwards:

  ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
-filter:v
format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1,colorlevels=romax=0.6:bomax=0.6
greenlag2.mp4

which leads to this output http://www.robinbussell.co.uk/mov/greenlag2.mp4 
but that feels like cheating!

Can anyone help explain what's going on? I was expecting green trails but
got white. There are Blue trails too, however, from the blue LEDs in the
scene, am I getting the concept of planes mixed up somewhere? maybe
something to do with the very high contrast input?


Many thanks,
      Robin.




--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
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: lagfun misunderstanding?

Zedsquared
I do apologise, the example I just posted omitted the planes argument to
lagfun, here's the command I was using and resulting output

 ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2 -filter:v
format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1  greenlagtest2.mp4

input http://www.robinbussell.co.uk/mov/IMG_1685.MOV

output http://www.robinbussell.co.uk/mov/greenlagtest2.mp4

console:
ffmpeg version 4.2.2-1build1~18.04.sav0 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
  configuration: --prefix=/usr --extra-version='1build1~18.04.sav0'
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl
--disable-stripping --enable-avresample --disable-filter=resample
--enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig
--enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr
--enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame
--enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack
--enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal
--enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r
--enable-libx264 --enable-shared
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'IMG_1685.MOV':
  Metadata:
    major_brand     : qt
    minor_version   : 0
    compatible_brands: qt
    creation_time   : 2020-03-28T12:20:59.000000Z
  Duration: 00:00:18.53, start: 0.000000, bitrate: 3829 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv,
bt709), 1280x720, 3823 kb/s, 60.01 fps, 60 tbr, 600 tbn, 1200 tbc (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Video
      encoder         : H.264
    Stream #0:1(und): Data: none (mebx / 0x7862656D), 0 kb/s (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Metadata
    Stream #0:2(und): Data: none (mebx / 0x7862656D), 0 kb/s (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Metadata
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x558c4e532ec0] using cpu capabilities: MMX2 SSE2Fast SSSE3
SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x558c4e532ec0] profile High 4:4:4 Predictive, level 3.2, 4:4:4
8-bit
[libx264 @ 0x558c4e532ec0] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC
codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options:
cabac=1 ref=3 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1
psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0
cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12
lookahead_threads=2 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 'greenlagtest2.mp4':
  Metadata:
    major_brand     : qt
    minor_version   : 0
    compatible_brands: qt
    encoder         : Lavf58.29.100
    Stream #0:0(und): Video: h264 (libx264) (avc1 / 0x31637661), yuv444p,
1280x720, q=-1--1, 60 fps, 15360 tbn, 60 tbc (default)
    Metadata:
      creation_time   : 2020-03-28T12:20:59.000000Z
      handler_name    : Core Media Video
      encoder         : Lavc58.54.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame= 1112 fps= 52 q=-1.0 Lsize=    7458kB time=00:00:18.48
bitrate=3305.4kbits/s speed=0.857x
video:7451kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.094460%
[libx264 @ 0x558c4e532ec0] frame I:5     Avg QP:22.30  size: 50875
[libx264 @ 0x558c4e532ec0] frame P:968   Avg QP:25.04  size:  7422
[libx264 @ 0x558c4e532ec0] frame B:139   Avg QP:24.96  size:  1367
[libx264 @ 0x558c4e532ec0] consecutive B-frames: 81.5%  4.1%  4.3% 10.1%
[libx264 @ 0x558c4e532ec0] mb I  I16..4: 54.6%  0.0% 45.4%
[libx264 @ 0x558c4e532ec0] mb P  I16..4:  4.9%  0.0%  0.8%  P16..4: 36.4%
6.5%  5.2%  0.0%  0.0%    skip:46.1%
[libx264 @ 0x558c4e532ec0] mb B  I16..4:  0.6%  0.0%  0.0%  B16..8: 26.0%
0.7%  0.2%  direct: 0.4%  skip:72.1%  L0:29.8% L1:69.0% BI: 1.2%
[libx264 @ 0x558c4e532ec0] coded y,u,v intra: 12.9% 3.0% 3.8% inter: 6.9%
2.2% 1.6%
[libx264 @ 0x558c4e532ec0] i16 v,h,dc,p: 51% 26% 18%  6%
[libx264 @ 0x558c4e532ec0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 20% 31%  5%
6%  5%  6%  4%  5%
[libx264 @ 0x558c4e532ec0] Weighted P-Frames: Y:2.9% UV:0.4%
[libx264 @ 0x558c4e532ec0] ref P L0: 39.3% 52.0%  6.1%  2.5%  0.1%
[libx264 @ 0x558c4e532ec0] ref B L0: 87.8%  9.8%  2.4%
[libx264 @ 0x558c4e532ec0] ref B L1: 97.7%  2.3%
[libx264 @ 0x558c4e532ec0] kb/s:3293.09


Thanks again,
  Robin.






--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
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: lagfun misunderstanding?

Michael Koch
Am 29.03.2020 um 15:13 schrieb Zedsquared:
> I do apologise, the example I just posted omitted the planes argument to
> lagfun, here's the command I was using and resulting output
>
>   ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2 -filter:v
> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1  greenlagtest2.mp4

I can confirm that it doesn't work as expected. Shouldn't green be
planes=2 ? But that doesn't work either.

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: lagfun misunderstanding?

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

> Am 29.03.2020 um 15:13 schrieb Zedsquared:
>> I do apologise, the example I just posted omitted the planes argument to
>> lagfun, here's the command I was using and resulting output
>>
>>   ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>> -filter:v
>> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1  greenlagtest2.mp4
>
> I can confirm that it doesn't work as expected. Shouldn't green be
> planes=2 ? But that doesn't work either.

green is 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: lagfun misunderstanding?

Gyan Doshi-2
In reply to this post by Michael Koch


On 29-03-2020 07:56 pm, Michael Koch wrote:

> Am 29.03.2020 um 15:13 schrieb Zedsquared:
>> I do apologise, the example I just posted omitted the planes argument to
>> lagfun, here's the command I was using and resulting output
>>
>>   ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>> -filter:v
>> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1 greenlagtest2.mp4
>
> I can confirm that it doesn't work as expected. Shouldn't green be
> planes=2 ? But that doesn't work either.

It's a decimal input which is then treated as a binary bitmask. So dec
10 becomes bin 1010 i.e. filter the 1st and 3rd planes.

Gyan
_______________________________________________
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: lagfun misunderstanding?

Michael Koch
In reply to this post by Paul B Mahol
Am 29.03.2020 um 16:35 schrieb Paul B Mahol:

> On 3/29/20, Michael Koch <[hidden email]> wrote:
>> Am 29.03.2020 um 15:13 schrieb Zedsquared:
>>> I do apologise, the example I just posted omitted the planes argument to
>>> lagfun, here's the command I was using and resulting output
>>>
>>>    ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>>> -filter:v
>>> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1  greenlagtest2.mp4
>> I can confirm that it doesn't work as expected. Shouldn't green be
>> planes=2 ? But that doesn't work either.
> green is first plane.

But it doesn't work as expected with planes=1. I have added a green
rectangle that changes it's position after one second:

c:\ffmpeg\ffmpeg -i IMG_1685.MOV -vf "format=rgb24,sendcmd=c='1 drawbox
x
200',drawbox=x=0:w=100:h=100:t=fill:color=green,lagfun=decay=0.99:planes=1"
-t 5 -y greenlagtest.mp4

The decaying rectangle should be green, but it is white.

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: lagfun misunderstanding?

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

> Am 29.03.2020 um 16:35 schrieb Paul B Mahol:
>> On 3/29/20, Michael Koch <[hidden email]> wrote:
>>> Am 29.03.2020 um 15:13 schrieb Zedsquared:
>>>> I do apologise, the example I just posted omitted the planes argument to
>>>> lagfun, here's the command I was using and resulting output
>>>>
>>>>    ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>>>> -filter:v
>>>> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1  greenlagtest2.mp4
>>> I can confirm that it doesn't work as expected. Shouldn't green be
>>> planes=2 ? But that doesn't work either.
>> green is first plane.
>
> But it doesn't work as expected with planes=1. I have added a green
> rectangle that changes it's position after one second:

It works as expected.

>
> c:\ffmpeg\ffmpeg -i IMG_1685.MOV -vf "format=rgb24,sendcmd=c='1 drawbox
> x
> 200',drawbox=x=0:w=100:h=100:t=fill:color=green,lagfun=decay=0.99:planes=1"
> -t 5 -y greenlagtest.mp4
>
> The decaying rectangle should be green, but it is white.

Because your adjusted your filtergraph that way.
Drawbox does not support rgb formats, and i do not care enough to fix that.

>
> 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: lagfun misunderstanding?

Zedsquared
In reply to this post by Gyan Doshi-2

>It's a decimal input which is then treated as a binary bitmask. So dec
>10 becomes bin 1010 i.e. filter the 1st and 3rd planes.
>
>Gyan

Ah! that would explain a lot!  

I can confirm I'm still confused, however..

My understanding is that RGB24 has three planes, red then green then blue.
From your example it seems the masks act big endian so bit 0x08 represents
the first plane and bit 0x02 the third?

Using planes=10 ( should be Red  and Blue) gives a trail effect on the blue,
there is no strong red in that source:
see http://www.robinbussell.co.uk/mov/greenlagtest11.mp4

However using planes=4 (should be G plane by my reasoning) seems to have no
effect:

http://www.robinbussell.co.uk/mov/greenlagtest12.mp4


Just for completeness, here is

planes= 2 :http://www.robinbussell.co.uk/mov/greenlagtest13.mp4 .. blue
trails evident

In the above examples I also turned up the green before lagfun so full line
for last example is:

 ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2 -filter:v
format=pix_fmts=rgb24,colorlevels=romax=0.6:bomax=0.6,lagfun=decay=0.999:planes=2
greenlagtest13.mp4

Thanks,
      Robin.

 



--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
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: lagfun misunderstanding?

Michael Koch
In reply to this post by Paul B Mahol
Am 29.03.2020 um 17:59 schrieb Paul B Mahol:

> On 3/29/20, Michael Koch <[hidden email]> wrote:
>> Am 29.03.2020 um 16:35 schrieb Paul B Mahol:
>>> On 3/29/20, Michael Koch <[hidden email]> wrote:
>>>> Am 29.03.2020 um 15:13 schrieb Zedsquared:
>>>>> I do apologise, the example I just posted omitted the planes
>>>>> argument to
>>>>> lagfun, here's the command I was using and resulting output
>>>>>
>>>>>     ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>>>>> -filter:v
>>>>> format=pix_fmts=rgb24,lagfun=decay=0.999:planes=1 greenlagtest2.mp4
>>>> I can confirm that it doesn't work as expected. Shouldn't green be
>>>> planes=2 ? But that doesn't work either.
>>> green is first plane.
>> But it doesn't work as expected with planes=1. I have added a green
>> rectangle that changes it's position after one second:
> It works as expected.
>
>> c:\ffmpeg\ffmpeg -i IMG_1685.MOV -vf "format=rgb24,sendcmd=c='1 drawbox
>> x
>> 200',drawbox=x=0:w=100:h=100:t=fill:color=green,lagfun=decay=0.99:planes=1"
>>
>> -t 5 -y greenlagtest.mp4
>>
>> The decaying rectangle should be green, but it is white.
> Because your adjusted your filtergraph that way.
> Drawbox does not support rgb formats, and i do not care enough to fix
> that.

Now I have used format=rgb24 after drawbox, but it's still the same
problem. The green rectangle is decaying white--> gray--> black. I did
remove the planes option from the lagfun filter.

c:\ffmpeg\ffmpeg -i IMG_1685.MOV -vf "sendcmd=c='1 drawbox x
200',drawbox=x=0:w=100:h=100:t=fill:color=green,format=rgb24,lagfun=decay=0.999"
-t 5 -y greenlagtest.mp4

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: lagfun misunderstanding?

Michael Koch
In reply to this post by Zedsquared
Am 29.03.2020 um 18:09 schrieb Zedsquared:

>> It's a decimal input which is then treated as a binary bitmask. So dec
>> 10 becomes bin 1010 i.e. filter the 1st and 3rd planes.
>>
>> Gyan
> Ah! that would explain a lot!
>
> I can confirm I'm still confused, however..
>
> My understanding is that RGB24 has three planes, red then green then blue.
>  From your example it seems the masks act big endian so bit 0x08 represents
> the first plane and bit 0x02 the third?
>
> Using planes=10 ( should be Red  and Blue) gives a trail effect on the blue,
> there is no strong red in that source:
> see http://www.robinbussell.co.uk/mov/greenlagtest11.mp4
>
> However using planes=4 (should be G plane by my reasoning) seems to have no
> effect:
>
> http://www.robinbussell.co.uk/mov/greenlagtest12.mp4
>
>
> Just for completeness, here is
>
> planes= 2 :http://www.robinbussell.co.uk/mov/greenlagtest13.mp4 .. blue
> trails evident
>
> In the above examples I also turned up the green before lagfun so full line
> for last example is:
>
>   ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2 -filter:v
> format=pix_fmts=rgb24,colorlevels=romax=0.6:bomax=0.6,lagfun=decay=0.999:planes=2
> greenlagtest13.mp4

Try this workaround:

ffmpeg -i IMG_1685.MOV -filter_complex
"format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
-t 5 -y greenlagtest.mp4

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: lagfun misunderstanding?

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

> Am 29.03.2020 um 18:09 schrieb Zedsquared:
>>> It's a decimal input which is then treated as a binary bitmask. So dec
>>> 10 becomes bin 1010 i.e. filter the 1st and 3rd planes.
>>>
>>> Gyan
>> Ah! that would explain a lot!
>>
>> I can confirm I'm still confused, however..
>>
>> My understanding is that RGB24 has three planes, red then green then blue.
>>  From your example it seems the masks act big endian so bit 0x08
>> represents
>> the first plane and bit 0x02 the third?
>>
>> Using planes=10 ( should be Red  and Blue) gives a trail effect on the
>> blue,
>> there is no strong red in that source:
>> see http://www.robinbussell.co.uk/mov/greenlagtest11.mp4
>>
>> However using planes=4 (should be G plane by my reasoning) seems to have
>> no
>> effect:
>>
>> http://www.robinbussell.co.uk/mov/greenlagtest12.mp4
>>
>>
>> Just for completeness, here is
>>
>> planes= 2 :http://www.robinbussell.co.uk/mov/greenlagtest13.mp4 .. blue
>> trails evident
>>
>> In the above examples I also turned up the green before lagfun so full
>> line
>> for last example is:
>>
>>   ffmpeg -i IMG_1685.MOV -q:v 0 -vcodec h264 -acodec aac -strict -2
>> -filter:v
>> format=pix_fmts=rgb24,colorlevels=romax=0.6:bomax=0.6,lagfun=decay=0.999:planes=2
>> greenlagtest13.mp4
>
> Try this workaround:
>
> ffmpeg -i IMG_1685.MOV -filter_complex
> "format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
> -t 5 -y greenlagtest.mp4

You are over complicating things.

>
> 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: lagfun misunderstanding?

Zedsquared
In reply to this post by Michael Koch
>Try this workaround:

>ffmpeg -i IMG_1685.MOV -filter_complex
"format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
-t 5 -y greenlagtest.mp4

>Michael

Thanks Micheal!  I''ll have to take some time to see what's going on there
but I get the gist I think (I've not been near complex filters yet), you're
splitting the planes out and only running  lagfun on green then merging the
other two back in. Nice.

I'd still like to know what's up with the planes argument in lagfun, seems
the docs assume quite a lot of background knowledge that I've yet to
acquire, that's the trouble with diving into the middle of them.

Good fun getting my teeth stuck into this stuff though!

Thanks to all the devs who made this amazing software available for mere
mortals like me to play with.

cheers,
       Robin.
 



--
Sent from: http://www.ffmpeg-archive.org/
_______________________________________________
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: lagfun misunderstanding?

Carl Zwanzig
In reply to this post by Paul B Mahol
On 3/29/2020 10:38 AM, Paul B Mahol wrote:
> On 3/29/20, Michael Koch <[hidden email]> wrote:

>> ffmpeg -i IMG_1685.MOV -filter_complex
>> "format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
>> -t 5 -y greenlagtest.mp4
>
> You are over complicating things.

OK, how? What's a less complicated version? Explain, please.

z!
_______________________________________________
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: lagfun misunderstanding?

Paul B Mahol
On 3/29/20, Carl Zwanzig <[hidden email]> wrote:

> On 3/29/2020 10:38 AM, Paul B Mahol wrote:
>> On 3/29/20, Michael Koch <[hidden email]> wrote:
>
>>> ffmpeg -i IMG_1685.MOV -filter_complex
>>> "format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
>>> -t 5 -y greenlagtest.mp4
>>
>> You are over complicating things.
>
> OK, how? What's a less complicated version? Explain, please.

mpv "av://lavfi:color,format=gbrp,sendcmd=c='1 drawbox x
200',drawbox=x=0:w=100:h=100:t=fill:color=green,format=gbrp,lagfun=decay=0.99:planes=1,format=gbrp"
_______________________________________________
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: lagfun misunderstanding?

Michael Koch
Am 29.03.2020 um 20:06 schrieb Paul B Mahol:

> On 3/29/20, Carl Zwanzig <[hidden email]> wrote:
>> On 3/29/2020 10:38 AM, Paul B Mahol wrote:
>>> On 3/29/20, Michael Koch <[hidden email]> wrote:
>>>> ffmpeg -i IMG_1685.MOV -filter_complex
>>>> "format=rgb24,extractplanes=r+g+b[r][g][b];[g]lagfun=decay=0.999[gg];[gg][b][r]mergeplanes=0x001020:gbrp"
>>>> -t 5 -y greenlagtest.mp4
>>> You are over complicating things.
>> OK, how? What's a less complicated version? Explain, please.
> mpv "av://lavfi:color,format=gbrp,sendcmd=c='1 drawbox x
> 200',drawbox=x=0:w=100:h=100:t=fill:color=green,format=gbrp,lagfun=decay=0.99:planes=1,format=gbrp"

ok, that works. Please add to the lagfun documentation that it doesn't
work with rgb24. Or even better, throw an error message.
Mergeplanes gave me an error message when I tried to use it with rgb24.

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