lives-devel Mailing List for LiVES
LiVES is a Video Editing System. It is designed to be simple to use, y
Brought to you by:
gfinch
Menu
▾
▴
lives-devel — LiVES development list
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(6) |
Aug
(1) |
Sep
(33) |
Oct
(1) |
Nov
(10) |
Dec
|
| 2011 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
|
|
From: salsaman <sal...@gm...> - 2021-11-11 02:43:16
|
OK. Fix checked in ! The changes are as follows: - dont bail if the buffer size is not what we expected, only do so if it is too small - avoid picking formats with unusable palettes as the "best" size, check format prior to matching sizes - allow overriding of the default frame size selection - in addition to "At Most" (width X height) there is now an option to select the largest size - the test for "preferred" colourspaces will now select this whenever the new frame size match is at least as good as the current one (as opposed to having to exceed the current) in addition: - code for picking size matching methods is now a generic, standalone set of functions which can be reused anywhere within the application - saving the selected size match method, provided an ideal opportunity to extend the new "easy ptefs" API to integer values, so this has been added Please test and let me know if this resolves the original issue (clicking on "Options" and then "Pick the largest" in the webcam device selection dialog is likely to produce the best results given the debug output presented above. I'll now take a quick look at the other questions raised. Regards. Gabriel. http://lives-video.com https://www.openhub.net/accounts/salsaman On Tue, 9 Nov 2021 at 19:40, salsaman <sal...@gm...> wrote: > Thanks. It's going a bit slower than normal as I am in the middle of a > house move and large redecoration project linked to this. I'll push what I > have done to git later tonight. > > On Tue, 9 Nov 2021, 09:35 Clay Citadel, <cla...@gm...> wrote: > >> I'm ready to check whenever you are ready, I tried doing git pull but >> didn't get any new commits, I'm using https://github.com/salsaman/LiVES >> let me know if you need me to checkout from somewhere else or have a patch >> file. >> >> On Sun, Nov 7, 2021 at 12:30 AM salsaman <sal...@gm...> wrote: >> >>> OK, it's been a while since I last checked this part of the code. In >>> fact it IS one palette per array, however there is a built in max frame >>> size, which is set depending on the monitor size, in this case it defaults >>> to 1280 X 720 which is why the larger frame sizes are being ignored. What I >>> can do is improve this and reuse the size selection criteria from the >>> youtube downloader. The default can be "largest". >>> >>> >>> >>> >>> >>> >>> >>> >>> http://lives-video.com >>> https://www.openhub.net/accounts/salsaman >>> >>> >>> On Sat, 6 Nov 2021 at 19:38, salsaman <sal...@gm...> wrote: >>> >>>> OK, I see what is happening now. (My maths was a bit off there, >>>> of course it would be 4.5 bytes per pixel, not bits.) >>>> It turns out that the when a format offers an array of sizes, the >>>> buffer size is commonly set to accommodate the largest value possible, in >>>> this case 1920 X 1080, which works out correct for 2 bytes per pixel. Hence >>>> LiVES should ignore the buffer_size mismatch for arrays unless it is >>>> smaller than expected. >>>> >>>> In addition there is a check for palette type, so higher quality and >>>> RGB type palettes should be preferred, however this was only triggered if a >>>> larger frame was detected. I have corrected this so in such cases the >>>> preferred frame only needs to be at least the size of the current best. >>>> >>>> Furthermore, I was working under the assumption that when a device >>>> provided a size array, all entries in that array used the same palette >>>> which seems not be the case judging by your example. Thus this needs to be >>>> checked for each array entry, rather than per array. >>>> >>>> These fixes together should now ensure that the best format is >>>> correctly selected for every camera tested so far, including yours I >>>> believe. >>>> >>>> >>>> >>>> >>>> http://lives-video.com >>>> https://www.openhub.net/accounts/salsaman >>>> >>>> >>>> On Sat, 6 Nov 2021 at 17:33, salsaman <sal...@gm...> wrote: >>>> >>>>> That should read: >>>>> >>>>> ...caused the webcam to not work *correctly*... >>>>> >>>>> http://lives-video.com >>>>> https://www.openhub.net/accounts/salsaman >>>>> >>>>> >>>>> On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: >>>>> >>>>>> >>>>>> Hi Clay, >>>>>> I will get back to your questions shortly, but first I wanted to >>>>>> update you on progress in investigating the original issue. What I >>>>>> discovered just now is that for reasons which are still unclear to me, for >>>>>> some camera formates, the buffer size returned is not the same as the >>>>>> calculated value (width X height X pixel size). In fact in the example you >>>>>> gave, doing the sums results in a pixel size of 4.5 bits, as opposed to the >>>>>> 16 bits per pixel expected for uyvyv or yuyv.. When this occurs, LiVES >>>>>> assumed that the buffer size was set incorrectly and tried to change it to >>>>>> the predicted size, which caused the webcam to not work incorrectly and as >>>>>> a result LiVES would close the camera clip. The final warning message is >>>>>> not really relevant to this, but occurs due to more rigorous filesystem >>>>>> checking which had not been updated to include webcam clips. >>>>>> >>>>>> As i mentioned, I am unsure as to the cause of these buffer size >>>>>> mismatches - it maybe due to some kind of image / stream compression in the >>>>>> camera device. However I am updating the code so that the buffer size is >>>>>> checked whilst enumerating the possible formats, which prevents such >>>>>> formats from being selected as the "best". >>>>>> >>>>>> I have tested this fix and it does work to resolve the original issue >>>>>> and allows the webcam to open as a clip inside LiVES as intended. >>>>>> >>>>>> After I have completed a bit more testing I will check the code in to >>>>>> github so that you can verify that it fixes the original problem for you >>>>>> also. >>>>>> >>>>>> As soon as I check in the code I will have a look ar the other points >>>>>> you raised. >>>>>> >>>>>> Regards, >>>>>> Gabriel. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> >>>>>> wrote: >>>>>> >>>>>>> I managed to make the camera work! I'm not really sure what did it, >>>>>>> somethings I remember doing is switching from mplayer to mpd and installing >>>>>>> zvbi, maybe restarting could have also played a part too. Now I have a 2 >>>>>>> questions: >>>>>>> >>>>>>> 1) the video I get from recording the webcam in lives is not very >>>>>>> fluid, I switched to 30fps and if I can tell it's not the same quality that >>>>>>> other previews, that includes the preview and a quick transcode tested with >>>>>>> mpv separately. How can I tell if it's using MJPEG or YUYV? is there any >>>>>>> way to switch it? Is there any way I can make it more fluid, like say other >>>>>>> applications like OBS have done (I have noticed that YUYV is laggy like >>>>>>> this so I suspect this is the cause of the issue but can't tell for sure)? >>>>>>> Could this be fixed with proper configuration? or is it something that >>>>>>> would need further development? I'm willing write code to fix this if you >>>>>>> don't mind but wanna make sure I'm actually solving a problem and not >>>>>>> chasing something that could have been fixed by tweaking a few >>>>>>> settings/rebuilding lives. I really appreciate your help with pointing me >>>>>>> to the right place to get started on this. >>>>>>> >>>>>>> 2) Rendering takes a long time, I tried switching the encoder >>>>>>> settings but could you confirm this is how it should be? I suspect the >>>>>>> recording process get's raw input from the camera and then the rendering >>>>>>> encodes it into something lives can display? Any way to use GPU to help >>>>>>> with this? Again pointing to the right place would help. >>>>>>> >>>>>>> Thank you so much for making lives, I'm enjoying the way you've >>>>>>> setup the workflow. I think it really sets itself apart from other video >>>>>>> editors, >>>>>>> Tom >>>>>>> >>>>>>> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >>>>>>> >>>>>>>> This looks like a bug, I will investigate. >>>>>>>> >>>>>>>> "Wanted frame size 1280 x 720, got 1280 x 720" >>>>>>>> >>>>>>>> Most likely it is a divide by 2 error somewhere, each yuyv >>>>>>>> macropixel converts to 2 RGB pixels. >>>>>>>> >>>>>>>> It certainly should be possible to do what you wanted in LiVES. >>>>>>>> Just set audio source to external, p[en webcam, hit, record then play. >>>>>>>> Then you should be able to preview each recording before deciding >>>>>>>> whether to render / encode it. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Gabriel. >>>>>>>> >>>>>>>> >>>>>>>> http://lives-video.com >>>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>>> >>>>>>>> >>>>>>>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Gabriel, >>>>>>>>> >>>>>>>>> You were right make clean allowed me to see the option. However >>>>>>>>> now when I select any of my webcams lives doesn't open it, at the bottom of >>>>>>>>> this email is the command line output I get when I try to set it. To be >>>>>>>>> fair I don't think my webcams work well will YUYV, because when I go to >>>>>>>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>>>>>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>>>>>>> formats but I haven't been able to get MJPEG working in any program (I have >>>>>>>>> mjpegtools installed but maybe I'm missing something). >>>>>>>>> >>>>>>>>> Maybe if I explain what I need to do with lives you could give me >>>>>>>>> some advice on the best way to go about it. I'm trying to record how to >>>>>>>>> play my own songs on guitar so I can comeback to it and just watch and >>>>>>>>> relearn each part. I could record all the parts in advance and then import >>>>>>>>> them into a program which is what I'm currently doing with lives. But >>>>>>>>> ideally what I want to do is record my performance inside lives, decide if >>>>>>>>> the take is good or not. If it's not good discard it, if it's good keep it >>>>>>>>> as a clip so I can use the multitrack functionality after I'm done >>>>>>>>> recording all parts. I've thought about maybe make a script with ffmpeg >>>>>>>>> instead for taking the yes no decision on each take and then storing >>>>>>>>> everything into the same folder that I will open later with lives. Probably >>>>>>>>> what I'll end up doing but I'm just curious if I could make it within lives >>>>>>>>> itself. >>>>>>>>> >>>>>>>>> Thank you for your work and help, I'm a huge fan! >>>>>>>>> >>>>>>>>> here is the relevant console output from running lives while >>>>>>>>> trying to set the webcam: >>>>>>>>> checking formats for /dev/video1 >>>>>>>>> Checking 19 array sizes >>>>>>>>> entry 0:640 x 480 >>>>>>>>> Size is best so far >>>>>>>>> entry 1:160 x 120 >>>>>>>>> entry 2:176 x 144 >>>>>>>>> entry 3:320 x 180 >>>>>>>>> entry 4:320 x 240 >>>>>>>>> entry 5:352 x 288 >>>>>>>>> entry 6:340 x 340 >>>>>>>>> entry 7:424 x 240 >>>>>>>>> entry 8:440 x 440 >>>>>>>>> entry 9:480 x 270 >>>>>>>>> entry 10:640 x 360 >>>>>>>>> entry 11:800 x 448 >>>>>>>>> entry 12:800 x 600 >>>>>>>>> Size is best so far >>>>>>>>> entry 13:848 x 480 >>>>>>>>> entry 14:960 x 540 >>>>>>>>> entry 15:1024 x 576 >>>>>>>>> entry 16:1280 x 720 >>>>>>>>> Size is best so far >>>>>>>>> entry 17:1600 x 896 >>>>>>>>> entry 18:1920 x 1080 >>>>>>>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 >>>>>>>>> buf=0 >>>>>>>>> >>>>>>>>> Using palette with fourcc 0x56595559, translated as YUYV >>>>>>>>> ALLX 4147200 1280 720 32 2 >>>>>>>>> Unicap buffer size is wrong, resetting it. >>>>>>>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>>>>>>> >>>>>>>>> >>>>>>>>> smogrify: WARNING ! asked to close dir >>>>>>>>> /dev/shm/livesprojects/882280649 >>>>>>>>> which appears not to belong to us, there is no marker file >>>>>>>>> >>>>>>>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ho Tom, >>>>>>>>>> you shouldn't really need to compile unicap, if you have the >>>>>>>>>> package libunicap-dev installed during configure, it should be enough. >>>>>>>>>> Are you sure you didm't do something silly like forgetting to run >>>>>>>>>> "make clean" after installing unicap ? >>>>>>>>>> >>>>>>>>>> If you can attach the complete output of ./configure and make, I >>>>>>>>>> will take a look and see what is wrong. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Gabriel. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://lives-video.com >>>>>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, I've compiled lives from git, and was a bit disappointed to >>>>>>>>>>> find that Files->Add webcam/tv card... menu option showed no options. >>>>>>>>>>> Thinking it was a missing dependency I dug into the source code and found >>>>>>>>>>> that maybe if I had libunicap I would be able to see it. So I went and >>>>>>>>>>> compiled the latest git version of unicap which wasn't very straightforward >>>>>>>>>>> but I managed to do it. I recompiled lives making sure the output of >>>>>>>>>>> ./configure had unicap set to yes. To my surprise I didn't have the option, >>>>>>>>>>> I feel like I'm close but I would like to know if someone here can help me >>>>>>>>>>> figure it out. >>>>>>>>>>> >>>>>>>>>>> Thank you in advance for all your help, >>>>>>>>>>> Tom >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lives-devel mailing list >>>>>>>>>>> Liv...@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lives-devel mailing list >>>>>>>>>> Liv...@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Lives-devel mailing list >>>>>>>>> Liv...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lives-devel mailing list >>>>>>>> Liv...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lives-devel mailing list >>>>>>> Liv...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>> >>>>>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > |
|
From: salsaman <sal...@gm...> - 2021-11-09 22:40:28
|
Thanks. It's going a bit slower than normal as I am in the middle of a house move and large redecoration project linked to this. I'll push what I have done to git later tonight. On Tue, 9 Nov 2021, 09:35 Clay Citadel, <cla...@gm...> wrote: > I'm ready to check whenever you are ready, I tried doing git pull but > didn't get any new commits, I'm using https://github.com/salsaman/LiVES > let me know if you need me to checkout from somewhere else or have a patch > file. > > On Sun, Nov 7, 2021 at 12:30 AM salsaman <sal...@gm...> wrote: > >> OK, it's been a while since I last checked this part of the code. In fact >> it IS one palette per array, however there is a built in max frame size, >> which is set depending on the monitor size, in this case it defaults to >> 1280 X 720 which is why the larger frame sizes are being ignored. What I >> can do is improve this and reuse the size selection criteria from the >> youtube downloader. The default can be "largest". >> >> >> >> >> >> >> >> >> http://lives-video.com >> https://www.openhub.net/accounts/salsaman >> >> >> On Sat, 6 Nov 2021 at 19:38, salsaman <sal...@gm...> wrote: >> >>> OK, I see what is happening now. (My maths was a bit off there, >>> of course it would be 4.5 bytes per pixel, not bits.) >>> It turns out that the when a format offers an array of sizes, the buffer >>> size is commonly set to accommodate the largest value possible, in this >>> case 1920 X 1080, which works out correct for 2 bytes per pixel. Hence >>> LiVES should ignore the buffer_size mismatch for arrays unless it is >>> smaller than expected. >>> >>> In addition there is a check for palette type, so higher quality and RGB >>> type palettes should be preferred, however this was only triggered if a >>> larger frame was detected. I have corrected this so in such cases the >>> preferred frame only needs to be at least the size of the current best. >>> >>> Furthermore, I was working under the assumption that when a device >>> provided a size array, all entries in that array used the same palette >>> which seems not be the case judging by your example. Thus this needs to be >>> checked for each array entry, rather than per array. >>> >>> These fixes together should now ensure that the best format is >>> correctly selected for every camera tested so far, including yours I >>> believe. >>> >>> >>> >>> >>> http://lives-video.com >>> https://www.openhub.net/accounts/salsaman >>> >>> >>> On Sat, 6 Nov 2021 at 17:33, salsaman <sal...@gm...> wrote: >>> >>>> That should read: >>>> >>>> ...caused the webcam to not work *correctly*... >>>> >>>> http://lives-video.com >>>> https://www.openhub.net/accounts/salsaman >>>> >>>> >>>> On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: >>>> >>>>> >>>>> Hi Clay, >>>>> I will get back to your questions shortly, but first I wanted to >>>>> update you on progress in investigating the original issue. What I >>>>> discovered just now is that for reasons which are still unclear to me, for >>>>> some camera formates, the buffer size returned is not the same as the >>>>> calculated value (width X height X pixel size). In fact in the example you >>>>> gave, doing the sums results in a pixel size of 4.5 bits, as opposed to the >>>>> 16 bits per pixel expected for uyvyv or yuyv.. When this occurs, LiVES >>>>> assumed that the buffer size was set incorrectly and tried to change it to >>>>> the predicted size, which caused the webcam to not work incorrectly and as >>>>> a result LiVES would close the camera clip. The final warning message is >>>>> not really relevant to this, but occurs due to more rigorous filesystem >>>>> checking which had not been updated to include webcam clips. >>>>> >>>>> As i mentioned, I am unsure as to the cause of these buffer size >>>>> mismatches - it maybe due to some kind of image / stream compression in the >>>>> camera device. However I am updating the code so that the buffer size is >>>>> checked whilst enumerating the possible formats, which prevents such >>>>> formats from being selected as the "best". >>>>> >>>>> I have tested this fix and it does work to resolve the original issue >>>>> and allows the webcam to open as a clip inside LiVES as intended. >>>>> >>>>> After I have completed a bit more testing I will check the code in to >>>>> github so that you can verify that it fixes the original problem for you >>>>> also. >>>>> >>>>> As soon as I check in the code I will have a look ar the other points >>>>> you raised. >>>>> >>>>> Regards, >>>>> Gabriel. >>>>> >>>>> >>>>> >>>>> On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> >>>>> wrote: >>>>> >>>>>> I managed to make the camera work! I'm not really sure what did it, >>>>>> somethings I remember doing is switching from mplayer to mpd and installing >>>>>> zvbi, maybe restarting could have also played a part too. Now I have a 2 >>>>>> questions: >>>>>> >>>>>> 1) the video I get from recording the webcam in lives is not very >>>>>> fluid, I switched to 30fps and if I can tell it's not the same quality that >>>>>> other previews, that includes the preview and a quick transcode tested with >>>>>> mpv separately. How can I tell if it's using MJPEG or YUYV? is there any >>>>>> way to switch it? Is there any way I can make it more fluid, like say other >>>>>> applications like OBS have done (I have noticed that YUYV is laggy like >>>>>> this so I suspect this is the cause of the issue but can't tell for sure)? >>>>>> Could this be fixed with proper configuration? or is it something that >>>>>> would need further development? I'm willing write code to fix this if you >>>>>> don't mind but wanna make sure I'm actually solving a problem and not >>>>>> chasing something that could have been fixed by tweaking a few >>>>>> settings/rebuilding lives. I really appreciate your help with pointing me >>>>>> to the right place to get started on this. >>>>>> >>>>>> 2) Rendering takes a long time, I tried switching the encoder >>>>>> settings but could you confirm this is how it should be? I suspect the >>>>>> recording process get's raw input from the camera and then the rendering >>>>>> encodes it into something lives can display? Any way to use GPU to help >>>>>> with this? Again pointing to the right place would help. >>>>>> >>>>>> Thank you so much for making lives, I'm enjoying the way you've setup >>>>>> the workflow. I think it really sets itself apart from other video editors, >>>>>> Tom >>>>>> >>>>>> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >>>>>> >>>>>>> This looks like a bug, I will investigate. >>>>>>> >>>>>>> "Wanted frame size 1280 x 720, got 1280 x 720" >>>>>>> >>>>>>> Most likely it is a divide by 2 error somewhere, each yuyv >>>>>>> macropixel converts to 2 RGB pixels. >>>>>>> >>>>>>> It certainly should be possible to do what you wanted in LiVES. Just >>>>>>> set audio source to external, p[en webcam, hit, record then play. >>>>>>> Then you should be able to preview each recording before deciding >>>>>>> whether to render / encode it. >>>>>>> >>>>>>> Regards, >>>>>>> Gabriel. >>>>>>> >>>>>>> >>>>>>> http://lives-video.com >>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>> >>>>>>> >>>>>>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Gabriel, >>>>>>>> >>>>>>>> You were right make clean allowed me to see the option. However now >>>>>>>> when I select any of my webcams lives doesn't open it, at the bottom of >>>>>>>> this email is the command line output I get when I try to set it. To be >>>>>>>> fair I don't think my webcams work well will YUYV, because when I go to >>>>>>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>>>>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>>>>>> formats but I haven't been able to get MJPEG working in any program (I have >>>>>>>> mjpegtools installed but maybe I'm missing something). >>>>>>>> >>>>>>>> Maybe if I explain what I need to do with lives you could give me >>>>>>>> some advice on the best way to go about it. I'm trying to record how to >>>>>>>> play my own songs on guitar so I can comeback to it and just watch and >>>>>>>> relearn each part. I could record all the parts in advance and then import >>>>>>>> them into a program which is what I'm currently doing with lives. But >>>>>>>> ideally what I want to do is record my performance inside lives, decide if >>>>>>>> the take is good or not. If it's not good discard it, if it's good keep it >>>>>>>> as a clip so I can use the multitrack functionality after I'm done >>>>>>>> recording all parts. I've thought about maybe make a script with ffmpeg >>>>>>>> instead for taking the yes no decision on each take and then storing >>>>>>>> everything into the same folder that I will open later with lives. Probably >>>>>>>> what I'll end up doing but I'm just curious if I could make it within lives >>>>>>>> itself. >>>>>>>> >>>>>>>> Thank you for your work and help, I'm a huge fan! >>>>>>>> >>>>>>>> here is the relevant console output from running lives while trying >>>>>>>> to set the webcam: >>>>>>>> checking formats for /dev/video1 >>>>>>>> Checking 19 array sizes >>>>>>>> entry 0:640 x 480 >>>>>>>> Size is best so far >>>>>>>> entry 1:160 x 120 >>>>>>>> entry 2:176 x 144 >>>>>>>> entry 3:320 x 180 >>>>>>>> entry 4:320 x 240 >>>>>>>> entry 5:352 x 288 >>>>>>>> entry 6:340 x 340 >>>>>>>> entry 7:424 x 240 >>>>>>>> entry 8:440 x 440 >>>>>>>> entry 9:480 x 270 >>>>>>>> entry 10:640 x 360 >>>>>>>> entry 11:800 x 448 >>>>>>>> entry 12:800 x 600 >>>>>>>> Size is best so far >>>>>>>> entry 13:848 x 480 >>>>>>>> entry 14:960 x 540 >>>>>>>> entry 15:1024 x 576 >>>>>>>> entry 16:1280 x 720 >>>>>>>> Size is best so far >>>>>>>> entry 17:1600 x 896 >>>>>>>> entry 18:1920 x 1080 >>>>>>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>>>>>>> >>>>>>>> Using palette with fourcc 0x56595559, translated as YUYV >>>>>>>> ALLX 4147200 1280 720 32 2 >>>>>>>> Unicap buffer size is wrong, resetting it. >>>>>>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>>>>>> >>>>>>>> >>>>>>>> smogrify: WARNING ! asked to close dir >>>>>>>> /dev/shm/livesprojects/882280649 >>>>>>>> which appears not to belong to us, there is no marker file >>>>>>>> >>>>>>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ho Tom, >>>>>>>>> you shouldn't really need to compile unicap, if you have the >>>>>>>>> package libunicap-dev installed during configure, it should be enough. >>>>>>>>> Are you sure you didm't do something silly like forgetting to run >>>>>>>>> "make clean" after installing unicap ? >>>>>>>>> >>>>>>>>> If you can attach the complete output of ./configure and make, I >>>>>>>>> will take a look and see what is wrong. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Gabriel. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://lives-video.com >>>>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, I've compiled lives from git, and was a bit disappointed to >>>>>>>>>> find that Files->Add webcam/tv card... menu option showed no options. >>>>>>>>>> Thinking it was a missing dependency I dug into the source code and found >>>>>>>>>> that maybe if I had libunicap I would be able to see it. So I went and >>>>>>>>>> compiled the latest git version of unicap which wasn't very straightforward >>>>>>>>>> but I managed to do it. I recompiled lives making sure the output of >>>>>>>>>> ./configure had unicap set to yes. To my surprise I didn't have the option, >>>>>>>>>> I feel like I'm close but I would like to know if someone here can help me >>>>>>>>>> figure it out. >>>>>>>>>> >>>>>>>>>> Thank you in advance for all your help, >>>>>>>>>> Tom >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lives-devel mailing list >>>>>>>>>> Liv...@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Lives-devel mailing list >>>>>>>>> Liv...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lives-devel mailing list >>>>>>>> Liv...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lives-devel mailing list >>>>>>> Liv...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Lives-devel mailing list >>>>>> Liv...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>> >>>>> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: Clay C. <cla...@gm...> - 2021-11-09 12:35:44
|
I'm ready to check whenever you are ready, I tried doing git pull but didn't get any new commits, I'm using https://github.com/salsaman/LiVES let me know if you need me to checkout from somewhere else or have a patch file. On Sun, Nov 7, 2021 at 12:30 AM salsaman <sal...@gm...> wrote: > OK, it's been a while since I last checked this part of the code. In fact > it IS one palette per array, however there is a built in max frame size, > which is set depending on the monitor size, in this case it defaults to > 1280 X 720 which is why the larger frame sizes are being ignored. What I > can do is improve this and reuse the size selection criteria from the > youtube downloader. The default can be "largest". > > > > > > > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > On Sat, 6 Nov 2021 at 19:38, salsaman <sal...@gm...> wrote: > >> OK, I see what is happening now. (My maths was a bit off there, of course >> it would be 4.5 bytes per pixel, not bits.) >> It turns out that the when a format offers an array of sizes, the buffer >> size is commonly set to accommodate the largest value possible, in this >> case 1920 X 1080, which works out correct for 2 bytes per pixel. Hence >> LiVES should ignore the buffer_size mismatch for arrays unless it is >> smaller than expected. >> >> In addition there is a check for palette type, so higher quality and RGB >> type palettes should be preferred, however this was only triggered if a >> larger frame was detected. I have corrected this so in such cases the >> preferred frame only needs to be at least the size of the current best. >> >> Furthermore, I was working under the assumption that when a device >> provided a size array, all entries in that array used the same palette >> which seems not be the case judging by your example. Thus this needs to be >> checked for each array entry, rather than per array. >> >> These fixes together should now ensure that the best format is >> correctly selected for every camera tested so far, including yours I >> believe. >> >> >> >> >> http://lives-video.com >> https://www.openhub.net/accounts/salsaman >> >> >> On Sat, 6 Nov 2021 at 17:33, salsaman <sal...@gm...> wrote: >> >>> That should read: >>> >>> ...caused the webcam to not work *correctly*... >>> >>> http://lives-video.com >>> https://www.openhub.net/accounts/salsaman >>> >>> >>> On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: >>> >>>> >>>> Hi Clay, >>>> I will get back to your questions shortly, but first I wanted to update >>>> you on progress in investigating the original issue. What I discovered just >>>> now is that for reasons which are still unclear to me, for some camera >>>> formates, the buffer size returned is not the same as the calculated value >>>> (width X height X pixel size). In fact in the example you gave, doing the >>>> sums results in a pixel size of 4.5 bits, as opposed to the 16 bits per >>>> pixel expected for uyvyv or yuyv.. When this occurs, LiVES assumed that the >>>> buffer size was set incorrectly and tried to change it to the predicted >>>> size, which caused the webcam to not work incorrectly and as a result LiVES >>>> would close the camera clip. The final warning message is not really >>>> relevant to this, but occurs due to more rigorous filesystem checking which >>>> had not been updated to include webcam clips. >>>> >>>> As i mentioned, I am unsure as to the cause of these buffer size >>>> mismatches - it maybe due to some kind of image / stream compression in the >>>> camera device. However I am updating the code so that the buffer size is >>>> checked whilst enumerating the possible formats, which prevents such >>>> formats from being selected as the "best". >>>> >>>> I have tested this fix and it does work to resolve the original issue >>>> and allows the webcam to open as a clip inside LiVES as intended. >>>> >>>> After I have completed a bit more testing I will check the code in to >>>> github so that you can verify that it fixes the original problem for you >>>> also. >>>> >>>> As soon as I check in the code I will have a look ar the other points >>>> you raised. >>>> >>>> Regards, >>>> Gabriel. >>>> >>>> >>>> >>>> On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> >>>> wrote: >>>> >>>>> I managed to make the camera work! I'm not really sure what did it, >>>>> somethings I remember doing is switching from mplayer to mpd and installing >>>>> zvbi, maybe restarting could have also played a part too. Now I have a 2 >>>>> questions: >>>>> >>>>> 1) the video I get from recording the webcam in lives is not very >>>>> fluid, I switched to 30fps and if I can tell it's not the same quality that >>>>> other previews, that includes the preview and a quick transcode tested with >>>>> mpv separately. How can I tell if it's using MJPEG or YUYV? is there any >>>>> way to switch it? Is there any way I can make it more fluid, like say other >>>>> applications like OBS have done (I have noticed that YUYV is laggy like >>>>> this so I suspect this is the cause of the issue but can't tell for sure)? >>>>> Could this be fixed with proper configuration? or is it something that >>>>> would need further development? I'm willing write code to fix this if you >>>>> don't mind but wanna make sure I'm actually solving a problem and not >>>>> chasing something that could have been fixed by tweaking a few >>>>> settings/rebuilding lives. I really appreciate your help with pointing me >>>>> to the right place to get started on this. >>>>> >>>>> 2) Rendering takes a long time, I tried switching the encoder settings >>>>> but could you confirm this is how it should be? I suspect the recording >>>>> process get's raw input from the camera and then the rendering encodes it >>>>> into something lives can display? Any way to use GPU to help with this? >>>>> Again pointing to the right place would help. >>>>> >>>>> Thank you so much for making lives, I'm enjoying the way you've setup >>>>> the workflow. I think it really sets itself apart from other video editors, >>>>> Tom >>>>> >>>>> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >>>>> >>>>>> This looks like a bug, I will investigate. >>>>>> >>>>>> "Wanted frame size 1280 x 720, got 1280 x 720" >>>>>> >>>>>> Most likely it is a divide by 2 error somewhere, each yuyv macropixel >>>>>> converts to 2 RGB pixels. >>>>>> >>>>>> It certainly should be possible to do what you wanted in LiVES. Just >>>>>> set audio source to external, p[en webcam, hit, record then play. >>>>>> Then you should be able to preview each recording before deciding >>>>>> whether to render / encode it. >>>>>> >>>>>> Regards, >>>>>> Gabriel. >>>>>> >>>>>> >>>>>> http://lives-video.com >>>>>> https://www.openhub.net/accounts/salsaman >>>>>> >>>>>> >>>>>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> >>>>>> wrote: >>>>>> >>>>>>> Hi Gabriel, >>>>>>> >>>>>>> You were right make clean allowed me to see the option. However now >>>>>>> when I select any of my webcams lives doesn't open it, at the bottom of >>>>>>> this email is the command line output I get when I try to set it. To be >>>>>>> fair I don't think my webcams work well will YUYV, because when I go to >>>>>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>>>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>>>>> formats but I haven't been able to get MJPEG working in any program (I have >>>>>>> mjpegtools installed but maybe I'm missing something). >>>>>>> >>>>>>> Maybe if I explain what I need to do with lives you could give me >>>>>>> some advice on the best way to go about it. I'm trying to record how to >>>>>>> play my own songs on guitar so I can comeback to it and just watch and >>>>>>> relearn each part. I could record all the parts in advance and then import >>>>>>> them into a program which is what I'm currently doing with lives. But >>>>>>> ideally what I want to do is record my performance inside lives, decide if >>>>>>> the take is good or not. If it's not good discard it, if it's good keep it >>>>>>> as a clip so I can use the multitrack functionality after I'm done >>>>>>> recording all parts. I've thought about maybe make a script with ffmpeg >>>>>>> instead for taking the yes no decision on each take and then storing >>>>>>> everything into the same folder that I will open later with lives. Probably >>>>>>> what I'll end up doing but I'm just curious if I could make it within lives >>>>>>> itself. >>>>>>> >>>>>>> Thank you for your work and help, I'm a huge fan! >>>>>>> >>>>>>> here is the relevant console output from running lives while trying >>>>>>> to set the webcam: >>>>>>> checking formats for /dev/video1 >>>>>>> Checking 19 array sizes >>>>>>> entry 0:640 x 480 >>>>>>> Size is best so far >>>>>>> entry 1:160 x 120 >>>>>>> entry 2:176 x 144 >>>>>>> entry 3:320 x 180 >>>>>>> entry 4:320 x 240 >>>>>>> entry 5:352 x 288 >>>>>>> entry 6:340 x 340 >>>>>>> entry 7:424 x 240 >>>>>>> entry 8:440 x 440 >>>>>>> entry 9:480 x 270 >>>>>>> entry 10:640 x 360 >>>>>>> entry 11:800 x 448 >>>>>>> entry 12:800 x 600 >>>>>>> Size is best so far >>>>>>> entry 13:848 x 480 >>>>>>> entry 14:960 x 540 >>>>>>> entry 15:1024 x 576 >>>>>>> entry 16:1280 x 720 >>>>>>> Size is best so far >>>>>>> entry 17:1600 x 896 >>>>>>> entry 18:1920 x 1080 >>>>>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>>>>>> >>>>>>> Using palette with fourcc 0x56595559, translated as YUYV >>>>>>> ALLX 4147200 1280 720 32 2 >>>>>>> Unicap buffer size is wrong, resetting it. >>>>>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>>>>> >>>>>>> >>>>>>> smogrify: WARNING ! asked to close dir >>>>>>> /dev/shm/livesprojects/882280649 >>>>>>> which appears not to belong to us, there is no marker file >>>>>>> >>>>>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >>>>>>> >>>>>>>> Ho Tom, >>>>>>>> you shouldn't really need to compile unicap, if you have the >>>>>>>> package libunicap-dev installed during configure, it should be enough. >>>>>>>> Are you sure you didm't do something silly like forgetting to run >>>>>>>> "make clean" after installing unicap ? >>>>>>>> >>>>>>>> If you can attach the complete output of ./configure and make, I >>>>>>>> will take a look and see what is wrong. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Gabriel. >>>>>>>> >>>>>>>> >>>>>>>> http://lives-video.com >>>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>>> >>>>>>>> >>>>>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, I've compiled lives from git, and was a bit disappointed to >>>>>>>>> find that Files->Add webcam/tv card... menu option showed no options. >>>>>>>>> Thinking it was a missing dependency I dug into the source code and found >>>>>>>>> that maybe if I had libunicap I would be able to see it. So I went and >>>>>>>>> compiled the latest git version of unicap which wasn't very straightforward >>>>>>>>> but I managed to do it. I recompiled lives making sure the output of >>>>>>>>> ./configure had unicap set to yes. To my surprise I didn't have the option, >>>>>>>>> I feel like I'm close but I would like to know if someone here can help me >>>>>>>>> figure it out. >>>>>>>>> >>>>>>>>> Thank you in advance for all your help, >>>>>>>>> Tom >>>>>>>>> _______________________________________________ >>>>>>>>> Lives-devel mailing list >>>>>>>>> Liv...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Lives-devel mailing list >>>>>>>> Liv...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lives-devel mailing list >>>>>>> Liv...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Lives-devel mailing list >>>>>> Liv...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>> >>>>> _______________________________________________ >>>>> Lives-devel mailing list >>>>> Liv...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>> >>>> _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: salsaman <sal...@gm...> - 2021-11-07 05:29:58
|
OK, it's been a while since I last checked this part of the code. In fact it IS one palette per array, however there is a built in max frame size, which is set depending on the monitor size, in this case it defaults to 1280 X 720 which is why the larger frame sizes are being ignored. What I can do is improve this and reuse the size selection criteria from the youtube downloader. The default can be "largest". http://lives-video.com https://www.openhub.net/accounts/salsaman On Sat, 6 Nov 2021 at 19:38, salsaman <sal...@gm...> wrote: > OK, I see what is happening now. (My maths was a bit off there, of course > it would be 4.5 bytes per pixel, not bits.) > It turns out that the when a format offers an array of sizes, the buffer > size is commonly set to accommodate the largest value possible, in this > case 1920 X 1080, which works out correct for 2 bytes per pixel. Hence > LiVES should ignore the buffer_size mismatch for arrays unless it is > smaller than expected. > > In addition there is a check for palette type, so higher quality and RGB > type palettes should be preferred, however this was only triggered if a > larger frame was detected. I have corrected this so in such cases the > preferred frame only needs to be at least the size of the current best. > > Furthermore, I was working under the assumption that when a device > provided a size array, all entries in that array used the same palette > which seems not be the case judging by your example. Thus this needs to be > checked for each array entry, rather than per array. > > These fixes together should now ensure that the best format is > correctly selected for every camera tested so far, including yours I > believe. > > > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > On Sat, 6 Nov 2021 at 17:33, salsaman <sal...@gm...> wrote: > >> That should read: >> >> ...caused the webcam to not work *correctly*... >> >> http://lives-video.com >> https://www.openhub.net/accounts/salsaman >> >> >> On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: >> >>> >>> Hi Clay, >>> I will get back to your questions shortly, but first I wanted to update >>> you on progress in investigating the original issue. What I discovered just >>> now is that for reasons which are still unclear to me, for some camera >>> formates, the buffer size returned is not the same as the calculated value >>> (width X height X pixel size). In fact in the example you gave, doing the >>> sums results in a pixel size of 4.5 bits, as opposed to the 16 bits per >>> pixel expected for uyvyv or yuyv.. When this occurs, LiVES assumed that the >>> buffer size was set incorrectly and tried to change it to the predicted >>> size, which caused the webcam to not work incorrectly and as a result LiVES >>> would close the camera clip. The final warning message is not really >>> relevant to this, but occurs due to more rigorous filesystem checking which >>> had not been updated to include webcam clips. >>> >>> As i mentioned, I am unsure as to the cause of these buffer size >>> mismatches - it maybe due to some kind of image / stream compression in the >>> camera device. However I am updating the code so that the buffer size is >>> checked whilst enumerating the possible formats, which prevents such >>> formats from being selected as the "best". >>> >>> I have tested this fix and it does work to resolve the original issue >>> and allows the webcam to open as a clip inside LiVES as intended. >>> >>> After I have completed a bit more testing I will check the code in to >>> github so that you can verify that it fixes the original problem for you >>> also. >>> >>> As soon as I check in the code I will have a look ar the other points >>> you raised. >>> >>> Regards, >>> Gabriel. >>> >>> >>> >>> On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> wrote: >>> >>>> I managed to make the camera work! I'm not really sure what did it, >>>> somethings I remember doing is switching from mplayer to mpd and installing >>>> zvbi, maybe restarting could have also played a part too. Now I have a 2 >>>> questions: >>>> >>>> 1) the video I get from recording the webcam in lives is not very >>>> fluid, I switched to 30fps and if I can tell it's not the same quality that >>>> other previews, that includes the preview and a quick transcode tested with >>>> mpv separately. How can I tell if it's using MJPEG or YUYV? is there any >>>> way to switch it? Is there any way I can make it more fluid, like say other >>>> applications like OBS have done (I have noticed that YUYV is laggy like >>>> this so I suspect this is the cause of the issue but can't tell for sure)? >>>> Could this be fixed with proper configuration? or is it something that >>>> would need further development? I'm willing write code to fix this if you >>>> don't mind but wanna make sure I'm actually solving a problem and not >>>> chasing something that could have been fixed by tweaking a few >>>> settings/rebuilding lives. I really appreciate your help with pointing me >>>> to the right place to get started on this. >>>> >>>> 2) Rendering takes a long time, I tried switching the encoder settings >>>> but could you confirm this is how it should be? I suspect the recording >>>> process get's raw input from the camera and then the rendering encodes it >>>> into something lives can display? Any way to use GPU to help with this? >>>> Again pointing to the right place would help. >>>> >>>> Thank you so much for making lives, I'm enjoying the way you've setup >>>> the workflow. I think it really sets itself apart from other video editors, >>>> Tom >>>> >>>> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >>>> >>>>> This looks like a bug, I will investigate. >>>>> >>>>> "Wanted frame size 1280 x 720, got 1280 x 720" >>>>> >>>>> Most likely it is a divide by 2 error somewhere, each yuyv macropixel >>>>> converts to 2 RGB pixels. >>>>> >>>>> It certainly should be possible to do what you wanted in LiVES. Just >>>>> set audio source to external, p[en webcam, hit, record then play. >>>>> Then you should be able to preview each recording before deciding >>>>> whether to render / encode it. >>>>> >>>>> Regards, >>>>> Gabriel. >>>>> >>>>> >>>>> http://lives-video.com >>>>> https://www.openhub.net/accounts/salsaman >>>>> >>>>> >>>>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> >>>>> wrote: >>>>> >>>>>> Hi Gabriel, >>>>>> >>>>>> You were right make clean allowed me to see the option. However now >>>>>> when I select any of my webcams lives doesn't open it, at the bottom of >>>>>> this email is the command line output I get when I try to set it. To be >>>>>> fair I don't think my webcams work well will YUYV, because when I go to >>>>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>>>> formats but I haven't been able to get MJPEG working in any program (I have >>>>>> mjpegtools installed but maybe I'm missing something). >>>>>> >>>>>> Maybe if I explain what I need to do with lives you could give me >>>>>> some advice on the best way to go about it. I'm trying to record how to >>>>>> play my own songs on guitar so I can comeback to it and just watch and >>>>>> relearn each part. I could record all the parts in advance and then import >>>>>> them into a program which is what I'm currently doing with lives. But >>>>>> ideally what I want to do is record my performance inside lives, decide if >>>>>> the take is good or not. If it's not good discard it, if it's good keep it >>>>>> as a clip so I can use the multitrack functionality after I'm done >>>>>> recording all parts. I've thought about maybe make a script with ffmpeg >>>>>> instead for taking the yes no decision on each take and then storing >>>>>> everything into the same folder that I will open later with lives. Probably >>>>>> what I'll end up doing but I'm just curious if I could make it within lives >>>>>> itself. >>>>>> >>>>>> Thank you for your work and help, I'm a huge fan! >>>>>> >>>>>> here is the relevant console output from running lives while trying >>>>>> to set the webcam: >>>>>> checking formats for /dev/video1 >>>>>> Checking 19 array sizes >>>>>> entry 0:640 x 480 >>>>>> Size is best so far >>>>>> entry 1:160 x 120 >>>>>> entry 2:176 x 144 >>>>>> entry 3:320 x 180 >>>>>> entry 4:320 x 240 >>>>>> entry 5:352 x 288 >>>>>> entry 6:340 x 340 >>>>>> entry 7:424 x 240 >>>>>> entry 8:440 x 440 >>>>>> entry 9:480 x 270 >>>>>> entry 10:640 x 360 >>>>>> entry 11:800 x 448 >>>>>> entry 12:800 x 600 >>>>>> Size is best so far >>>>>> entry 13:848 x 480 >>>>>> entry 14:960 x 540 >>>>>> entry 15:1024 x 576 >>>>>> entry 16:1280 x 720 >>>>>> Size is best so far >>>>>> entry 17:1600 x 896 >>>>>> entry 18:1920 x 1080 >>>>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>>>>> >>>>>> Using palette with fourcc 0x56595559, translated as YUYV >>>>>> ALLX 4147200 1280 720 32 2 >>>>>> Unicap buffer size is wrong, resetting it. >>>>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>>>> >>>>>> >>>>>> smogrify: WARNING ! asked to close dir >>>>>> /dev/shm/livesprojects/882280649 >>>>>> which appears not to belong to us, there is no marker file >>>>>> >>>>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >>>>>> >>>>>>> Ho Tom, >>>>>>> you shouldn't really need to compile unicap, if you have the package >>>>>>> libunicap-dev installed during configure, it should be enough. >>>>>>> Are you sure you didm't do something silly like forgetting to run >>>>>>> "make clean" after installing unicap ? >>>>>>> >>>>>>> If you can attach the complete output of ./configure and make, I >>>>>>> will take a look and see what is wrong. >>>>>>> >>>>>>> Regards, >>>>>>> Gabriel. >>>>>>> >>>>>>> >>>>>>> http://lives-video.com >>>>>>> https://www.openhub.net/accounts/salsaman >>>>>>> >>>>>>> >>>>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, I've compiled lives from git, and was a bit disappointed to >>>>>>>> find that Files->Add webcam/tv card... menu option showed no options. >>>>>>>> Thinking it was a missing dependency I dug into the source code and found >>>>>>>> that maybe if I had libunicap I would be able to see it. So I went and >>>>>>>> compiled the latest git version of unicap which wasn't very straightforward >>>>>>>> but I managed to do it. I recompiled lives making sure the output of >>>>>>>> ./configure had unicap set to yes. To my surprise I didn't have the option, >>>>>>>> I feel like I'm close but I would like to know if someone here can help me >>>>>>>> figure it out. >>>>>>>> >>>>>>>> Thank you in advance for all your help, >>>>>>>> Tom >>>>>>>> _______________________________________________ >>>>>>>> Lives-devel mailing list >>>>>>>> Liv...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Lives-devel mailing list >>>>>>> Liv...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Lives-devel mailing list >>>>>> Liv...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>> >>>>> _______________________________________________ >>>>> Lives-devel mailing list >>>>> Liv...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>> >>>> _______________________________________________ >>>> Lives-devel mailing list >>>> Liv...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>> >>> |
|
From: salsaman <sal...@gm...> - 2021-11-06 22:39:18
|
OK, I see what is happening now. (My maths was a bit off there, of course it would be 4.5 bytes per pixel, not bits.) It turns out that the when a format offers an array of sizes, the buffer size is commonly set to accommodate the largest value possible, in this case 1920 X 1080, which works out correct for 2 bytes per pixel. Hence LiVES should ignore the buffer_size mismatch for arrays unless it is smaller than expected. In addition there is a check for palette type, so higher quality and RGB type palettes should be preferred, however this was only triggered if a larger frame was detected. I have corrected this so in such cases the preferred frame only needs to be at least the size of the current best. Furthermore, I was working under the assumption that when a device provided a size array, all entries in that array used the same palette which seems not be the case judging by your example. Thus this needs to be checked for each array entry, rather than per array. These fixes together should now ensure that the best format is correctly selected for every camera tested so far, including yours I believe. http://lives-video.com https://www.openhub.net/accounts/salsaman On Sat, 6 Nov 2021 at 17:33, salsaman <sal...@gm...> wrote: > That should read: > > ...caused the webcam to not work *correctly*... > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: > >> >> Hi Clay, >> I will get back to your questions shortly, but first I wanted to update >> you on progress in investigating the original issue. What I discovered just >> now is that for reasons which are still unclear to me, for some camera >> formates, the buffer size returned is not the same as the calculated value >> (width X height X pixel size). In fact in the example you gave, doing the >> sums results in a pixel size of 4.5 bits, as opposed to the 16 bits per >> pixel expected for uyvyv or yuyv.. When this occurs, LiVES assumed that the >> buffer size was set incorrectly and tried to change it to the predicted >> size, which caused the webcam to not work incorrectly and as a result LiVES >> would close the camera clip. The final warning message is not really >> relevant to this, but occurs due to more rigorous filesystem checking which >> had not been updated to include webcam clips. >> >> As i mentioned, I am unsure as to the cause of these buffer size >> mismatches - it maybe due to some kind of image / stream compression in the >> camera device. However I am updating the code so that the buffer size is >> checked whilst enumerating the possible formats, which prevents such >> formats from being selected as the "best". >> >> I have tested this fix and it does work to resolve the original issue and >> allows the webcam to open as a clip inside LiVES as intended. >> >> After I have completed a bit more testing I will check the code in to >> github so that you can verify that it fixes the original problem for you >> also. >> >> As soon as I check in the code I will have a look ar the other points you >> raised. >> >> Regards, >> Gabriel. >> >> >> >> On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> wrote: >> >>> I managed to make the camera work! I'm not really sure what did it, >>> somethings I remember doing is switching from mplayer to mpd and installing >>> zvbi, maybe restarting could have also played a part too. Now I have a 2 >>> questions: >>> >>> 1) the video I get from recording the webcam in lives is not very fluid, >>> I switched to 30fps and if I can tell it's not the same quality that other >>> previews, that includes the preview and a quick transcode tested with mpv >>> separately. How can I tell if it's using MJPEG or YUYV? is there any way to >>> switch it? Is there any way I can make it more fluid, like say other >>> applications like OBS have done (I have noticed that YUYV is laggy like >>> this so I suspect this is the cause of the issue but can't tell for sure)? >>> Could this be fixed with proper configuration? or is it something that >>> would need further development? I'm willing write code to fix this if you >>> don't mind but wanna make sure I'm actually solving a problem and not >>> chasing something that could have been fixed by tweaking a few >>> settings/rebuilding lives. I really appreciate your help with pointing me >>> to the right place to get started on this. >>> >>> 2) Rendering takes a long time, I tried switching the encoder settings >>> but could you confirm this is how it should be? I suspect the recording >>> process get's raw input from the camera and then the rendering encodes it >>> into something lives can display? Any way to use GPU to help with this? >>> Again pointing to the right place would help. >>> >>> Thank you so much for making lives, I'm enjoying the way you've setup >>> the workflow. I think it really sets itself apart from other video editors, >>> Tom >>> >>> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >>> >>>> This looks like a bug, I will investigate. >>>> >>>> "Wanted frame size 1280 x 720, got 1280 x 720" >>>> >>>> Most likely it is a divide by 2 error somewhere, each yuyv macropixel >>>> converts to 2 RGB pixels. >>>> >>>> It certainly should be possible to do what you wanted in LiVES. Just >>>> set audio source to external, p[en webcam, hit, record then play. >>>> Then you should be able to preview each recording before deciding >>>> whether to render / encode it. >>>> >>>> Regards, >>>> Gabriel. >>>> >>>> >>>> http://lives-video.com >>>> https://www.openhub.net/accounts/salsaman >>>> >>>> >>>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> >>>> wrote: >>>> >>>>> Hi Gabriel, >>>>> >>>>> You were right make clean allowed me to see the option. However now >>>>> when I select any of my webcams lives doesn't open it, at the bottom of >>>>> this email is the command line output I get when I try to set it. To be >>>>> fair I don't think my webcams work well will YUYV, because when I go to >>>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>>> formats but I haven't been able to get MJPEG working in any program (I have >>>>> mjpegtools installed but maybe I'm missing something). >>>>> >>>>> Maybe if I explain what I need to do with lives you could give me some >>>>> advice on the best way to go about it. I'm trying to record how to play my >>>>> own songs on guitar so I can comeback to it and just watch and relearn each >>>>> part. I could record all the parts in advance and then import them into a >>>>> program which is what I'm currently doing with lives. But ideally what I >>>>> want to do is record my performance inside lives, decide if the take is >>>>> good or not. If it's not good discard it, if it's good keep it as a clip so >>>>> I can use the multitrack functionality after I'm done recording all parts. >>>>> I've thought about maybe make a script with ffmpeg instead for taking the >>>>> yes no decision on each take and then storing everything into the same >>>>> folder that I will open later with lives. Probably what I'll end up doing >>>>> but I'm just curious if I could make it within lives itself. >>>>> >>>>> Thank you for your work and help, I'm a huge fan! >>>>> >>>>> here is the relevant console output from running lives while trying to >>>>> set the webcam: >>>>> checking formats for /dev/video1 >>>>> Checking 19 array sizes >>>>> entry 0:640 x 480 >>>>> Size is best so far >>>>> entry 1:160 x 120 >>>>> entry 2:176 x 144 >>>>> entry 3:320 x 180 >>>>> entry 4:320 x 240 >>>>> entry 5:352 x 288 >>>>> entry 6:340 x 340 >>>>> entry 7:424 x 240 >>>>> entry 8:440 x 440 >>>>> entry 9:480 x 270 >>>>> entry 10:640 x 360 >>>>> entry 11:800 x 448 >>>>> entry 12:800 x 600 >>>>> Size is best so far >>>>> entry 13:848 x 480 >>>>> entry 14:960 x 540 >>>>> entry 15:1024 x 576 >>>>> entry 16:1280 x 720 >>>>> Size is best so far >>>>> entry 17:1600 x 896 >>>>> entry 18:1920 x 1080 >>>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>>>> >>>>> Using palette with fourcc 0x56595559, translated as YUYV >>>>> ALLX 4147200 1280 720 32 2 >>>>> Unicap buffer size is wrong, resetting it. >>>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>>> >>>>> >>>>> smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 >>>>> which appears not to belong to us, there is no marker file >>>>> >>>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >>>>> >>>>>> Ho Tom, >>>>>> you shouldn't really need to compile unicap, if you have the package >>>>>> libunicap-dev installed during configure, it should be enough. >>>>>> Are you sure you didm't do something silly like forgetting to run >>>>>> "make clean" after installing unicap ? >>>>>> >>>>>> If you can attach the complete output of ./configure and make, I will >>>>>> take a look and see what is wrong. >>>>>> >>>>>> Regards, >>>>>> Gabriel. >>>>>> >>>>>> >>>>>> http://lives-video.com >>>>>> https://www.openhub.net/accounts/salsaman >>>>>> >>>>>> >>>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>>> wrote: >>>>>> >>>>>>> Hi, I've compiled lives from git, and was a bit disappointed to find >>>>>>> that Files->Add webcam/tv card... menu option showed no options. Thinking >>>>>>> it was a missing dependency I dug into the source code and found that maybe >>>>>>> if I had libunicap I would be able to see it. So I went and compiled the >>>>>>> latest git version of unicap which wasn't very straightforward but I >>>>>>> managed to do it. I recompiled lives making sure the output of ./configure >>>>>>> had unicap set to yes. To my surprise I didn't have the option, I feel like >>>>>>> I'm close but I would like to know if someone here can help me figure it >>>>>>> out. >>>>>>> >>>>>>> Thank you in advance for all your help, >>>>>>> Tom >>>>>>> _______________________________________________ >>>>>>> Lives-devel mailing list >>>>>>> Liv...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> Lives-devel mailing list >>>>>> Liv...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>> >>>>> _______________________________________________ >>>>> Lives-devel mailing list >>>>> Liv...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>> >>>> _______________________________________________ >>>> Lives-devel mailing list >>>> Liv...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>> >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> |
|
From: salsaman <sal...@gm...> - 2021-11-06 20:33:46
|
That should read: ...caused the webcam to not work *correctly*... http://lives-video.com https://www.openhub.net/accounts/salsaman On Sat, 6 Nov 2021 at 17:30, salsaman <sal...@gm...> wrote: > > Hi Clay, > I will get back to your questions shortly, but first I wanted to update > you on progress in investigating the original issue. What I discovered just > now is that for reasons which are still unclear to me, for some camera > formates, the buffer size returned is not the same as the calculated value > (width X height X pixel size). In fact in the example you gave, doing the > sums results in a pixel size of 4.5 bits, as opposed to the 16 bits per > pixel expected for uyvyv or yuyv.. When this occurs, LiVES assumed that the > buffer size was set incorrectly and tried to change it to the predicted > size, which caused the webcam to not work incorrectly and as a result LiVES > would close the camera clip. The final warning message is not really > relevant to this, but occurs due to more rigorous filesystem checking which > had not been updated to include webcam clips. > > As i mentioned, I am unsure as to the cause of these buffer size > mismatches - it maybe due to some kind of image / stream compression in the > camera device. However I am updating the code so that the buffer size is > checked whilst enumerating the possible formats, which prevents such > formats from being selected as the "best". > > I have tested this fix and it does work to resolve the original issue and > allows the webcam to open as a clip inside LiVES as intended. > > After I have completed a bit more testing I will check the code in to > github so that you can verify that it fixes the original problem for you > also. > > As soon as I check in the code I will have a look ar the other points you > raised. > > Regards, > Gabriel. > > > > On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> wrote: > >> I managed to make the camera work! I'm not really sure what did it, >> somethings I remember doing is switching from mplayer to mpd and installing >> zvbi, maybe restarting could have also played a part too. Now I have a 2 >> questions: >> >> 1) the video I get from recording the webcam in lives is not very fluid, >> I switched to 30fps and if I can tell it's not the same quality that other >> previews, that includes the preview and a quick transcode tested with mpv >> separately. How can I tell if it's using MJPEG or YUYV? is there any way to >> switch it? Is there any way I can make it more fluid, like say other >> applications like OBS have done (I have noticed that YUYV is laggy like >> this so I suspect this is the cause of the issue but can't tell for sure)? >> Could this be fixed with proper configuration? or is it something that >> would need further development? I'm willing write code to fix this if you >> don't mind but wanna make sure I'm actually solving a problem and not >> chasing something that could have been fixed by tweaking a few >> settings/rebuilding lives. I really appreciate your help with pointing me >> to the right place to get started on this. >> >> 2) Rendering takes a long time, I tried switching the encoder settings >> but could you confirm this is how it should be? I suspect the recording >> process get's raw input from the camera and then the rendering encodes it >> into something lives can display? Any way to use GPU to help with this? >> Again pointing to the right place would help. >> >> Thank you so much for making lives, I'm enjoying the way you've setup the >> workflow. I think it really sets itself apart from other video editors, >> Tom >> >> On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: >> >>> This looks like a bug, I will investigate. >>> >>> "Wanted frame size 1280 x 720, got 1280 x 720" >>> >>> Most likely it is a divide by 2 error somewhere, each yuyv macropixel >>> converts to 2 RGB pixels. >>> >>> It certainly should be possible to do what you wanted in LiVES. Just set >>> audio source to external, p[en webcam, hit, record then play. >>> Then you should be able to preview each recording before deciding >>> whether to render / encode it. >>> >>> Regards, >>> Gabriel. >>> >>> >>> http://lives-video.com >>> https://www.openhub.net/accounts/salsaman >>> >>> >>> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> wrote: >>> >>>> Hi Gabriel, >>>> >>>> You were right make clean allowed me to see the option. However now >>>> when I select any of my webcams lives doesn't open it, at the bottom of >>>> this email is the command line output I get when I try to set it. To be >>>> fair I don't think my webcams work well will YUYV, because when I go to >>>> OBS, I have to change to video format to one of the emulated options: BGR3, >>>> YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>>> formats but I haven't been able to get MJPEG working in any program (I have >>>> mjpegtools installed but maybe I'm missing something). >>>> >>>> Maybe if I explain what I need to do with lives you could give me some >>>> advice on the best way to go about it. I'm trying to record how to play my >>>> own songs on guitar so I can comeback to it and just watch and relearn each >>>> part. I could record all the parts in advance and then import them into a >>>> program which is what I'm currently doing with lives. But ideally what I >>>> want to do is record my performance inside lives, decide if the take is >>>> good or not. If it's not good discard it, if it's good keep it as a clip so >>>> I can use the multitrack functionality after I'm done recording all parts. >>>> I've thought about maybe make a script with ffmpeg instead for taking the >>>> yes no decision on each take and then storing everything into the same >>>> folder that I will open later with lives. Probably what I'll end up doing >>>> but I'm just curious if I could make it within lives itself. >>>> >>>> Thank you for your work and help, I'm a huge fan! >>>> >>>> here is the relevant console output from running lives while trying to >>>> set the webcam: >>>> checking formats for /dev/video1 >>>> Checking 19 array sizes >>>> entry 0:640 x 480 >>>> Size is best so far >>>> entry 1:160 x 120 >>>> entry 2:176 x 144 >>>> entry 3:320 x 180 >>>> entry 4:320 x 240 >>>> entry 5:352 x 288 >>>> entry 6:340 x 340 >>>> entry 7:424 x 240 >>>> entry 8:440 x 440 >>>> entry 9:480 x 270 >>>> entry 10:640 x 360 >>>> entry 11:800 x 448 >>>> entry 12:800 x 600 >>>> Size is best so far >>>> entry 13:848 x 480 >>>> entry 14:960 x 540 >>>> entry 15:1024 x 576 >>>> entry 16:1280 x 720 >>>> Size is best so far >>>> entry 17:1600 x 896 >>>> entry 18:1920 x 1080 >>>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>>> >>>> Using palette with fourcc 0x56595559, translated as YUYV >>>> ALLX 4147200 1280 720 32 2 >>>> Unicap buffer size is wrong, resetting it. >>>> Wanted frame size 1280 x 720, got 1280 x 720 >>>> >>>> >>>> smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 >>>> which appears not to belong to us, there is no marker file >>>> >>>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >>>> >>>>> Ho Tom, >>>>> you shouldn't really need to compile unicap, if you have the package >>>>> libunicap-dev installed during configure, it should be enough. >>>>> Are you sure you didm't do something silly like forgetting to run >>>>> "make clean" after installing unicap ? >>>>> >>>>> If you can attach the complete output of ./configure and make, I will >>>>> take a look and see what is wrong. >>>>> >>>>> Regards, >>>>> Gabriel. >>>>> >>>>> >>>>> http://lives-video.com >>>>> https://www.openhub.net/accounts/salsaman >>>>> >>>>> >>>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>>> wrote: >>>>> >>>>>> Hi, I've compiled lives from git, and was a bit disappointed to find >>>>>> that Files->Add webcam/tv card... menu option showed no options. Thinking >>>>>> it was a missing dependency I dug into the source code and found that maybe >>>>>> if I had libunicap I would be able to see it. So I went and compiled the >>>>>> latest git version of unicap which wasn't very straightforward but I >>>>>> managed to do it. I recompiled lives making sure the output of ./configure >>>>>> had unicap set to yes. To my surprise I didn't have the option, I feel like >>>>>> I'm close but I would like to know if someone here can help me figure it >>>>>> out. >>>>>> >>>>>> Thank you in advance for all your help, >>>>>> Tom >>>>>> _______________________________________________ >>>>>> Lives-devel mailing list >>>>>> Liv...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>>> >>>>> _______________________________________________ >>>>> Lives-devel mailing list >>>>> Liv...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>> >>>> _______________________________________________ >>>> Lives-devel mailing list >>>> Liv...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>> >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > |
|
From: salsaman <sal...@gm...> - 2021-11-06 20:30:38
|
Hi Clay, I will get back to your questions shortly, but first I wanted to update you on progress in investigating the original issue. What I discovered just now is that for reasons which are still unclear to me, for some camera formates, the buffer size returned is not the same as the calculated value (width X height X pixel size). In fact in the example you gave, doing the sums results in a pixel size of 4.5 bits, as opposed to the 16 bits per pixel expected for uyvyv or yuyv.. When this occurs, LiVES assumed that the buffer size was set incorrectly and tried to change it to the predicted size, which caused the webcam to not work incorrectly and as a result LiVES would close the camera clip. The final warning message is not really relevant to this, but occurs due to more rigorous filesystem checking which had not been updated to include webcam clips. As i mentioned, I am unsure as to the cause of these buffer size mismatches - it maybe due to some kind of image / stream compression in the camera device. However I am updating the code so that the buffer size is checked whilst enumerating the possible formats, which prevents such formats from being selected as the "best". I have tested this fix and it does work to resolve the original issue and allows the webcam to open as a clip inside LiVES as intended. After I have completed a bit more testing I will check the code in to github so that you can verify that it fixes the original problem for you also. As soon as I check in the code I will have a look ar the other points you raised. Regards, Gabriel. On Sat, 6 Nov 2021 at 14:48, Clay Citadel <cla...@gm...> wrote: > I managed to make the camera work! I'm not really sure what did it, > somethings I remember doing is switching from mplayer to mpd and installing > zvbi, maybe restarting could have also played a part too. Now I have a 2 > questions: > > 1) the video I get from recording the webcam in lives is not very fluid, I > switched to 30fps and if I can tell it's not the same quality that other > previews, that includes the preview and a quick transcode tested with mpv > separately. How can I tell if it's using MJPEG or YUYV? is there any way to > switch it? Is there any way I can make it more fluid, like say other > applications like OBS have done (I have noticed that YUYV is laggy like > this so I suspect this is the cause of the issue but can't tell for sure)? > Could this be fixed with proper configuration? or is it something that > would need further development? I'm willing write code to fix this if you > don't mind but wanna make sure I'm actually solving a problem and not > chasing something that could have been fixed by tweaking a few > settings/rebuilding lives. I really appreciate your help with pointing me > to the right place to get started on this. > > 2) Rendering takes a long time, I tried switching the encoder settings but > could you confirm this is how it should be? I suspect the recording process > get's raw input from the camera and then the rendering encodes it into > something lives can display? Any way to use GPU to help with this? Again > pointing to the right place would help. > > Thank you so much for making lives, I'm enjoying the way you've setup the > workflow. I think it really sets itself apart from other video editors, > Tom > > On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: > >> This looks like a bug, I will investigate. >> >> "Wanted frame size 1280 x 720, got 1280 x 720" >> >> Most likely it is a divide by 2 error somewhere, each yuyv macropixel >> converts to 2 RGB pixels. >> >> It certainly should be possible to do what you wanted in LiVES. Just set >> audio source to external, p[en webcam, hit, record then play. >> Then you should be able to preview each recording before deciding >> whether to render / encode it. >> >> Regards, >> Gabriel. >> >> >> http://lives-video.com >> https://www.openhub.net/accounts/salsaman >> >> >> On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> wrote: >> >>> Hi Gabriel, >>> >>> You were right make clean allowed me to see the option. However now when >>> I select any of my webcams lives doesn't open it, at the bottom of this >>> email is the command line output I get when I try to set it. To be fair I >>> don't think my webcams work well will YUYV, because when I go to OBS, I >>> have to change to video format to one of the emulated options: BGR3, YU12, >>> YV12 to be able to even see the preview. My camera has YUYV and MJPEG >>> formats but I haven't been able to get MJPEG working in any program (I have >>> mjpegtools installed but maybe I'm missing something). >>> >>> Maybe if I explain what I need to do with lives you could give me some >>> advice on the best way to go about it. I'm trying to record how to play my >>> own songs on guitar so I can comeback to it and just watch and relearn each >>> part. I could record all the parts in advance and then import them into a >>> program which is what I'm currently doing with lives. But ideally what I >>> want to do is record my performance inside lives, decide if the take is >>> good or not. If it's not good discard it, if it's good keep it as a clip so >>> I can use the multitrack functionality after I'm done recording all parts. >>> I've thought about maybe make a script with ffmpeg instead for taking the >>> yes no decision on each take and then storing everything into the same >>> folder that I will open later with lives. Probably what I'll end up doing >>> but I'm just curious if I could make it within lives itself. >>> >>> Thank you for your work and help, I'm a huge fan! >>> >>> here is the relevant console output from running lives while trying to >>> set the webcam: >>> checking formats for /dev/video1 >>> Checking 19 array sizes >>> entry 0:640 x 480 >>> Size is best so far >>> entry 1:160 x 120 >>> entry 2:176 x 144 >>> entry 3:320 x 180 >>> entry 4:320 x 240 >>> entry 5:352 x 288 >>> entry 6:340 x 340 >>> entry 7:424 x 240 >>> entry 8:440 x 440 >>> entry 9:480 x 270 >>> entry 10:640 x 360 >>> entry 11:800 x 448 >>> entry 12:800 x 600 >>> Size is best so far >>> entry 13:848 x 480 >>> entry 14:960 x 540 >>> entry 15:1024 x 576 >>> entry 16:1280 x 720 >>> Size is best so far >>> entry 17:1600 x 896 >>> entry 18:1920 x 1080 >>> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >>> >>> Using palette with fourcc 0x56595559, translated as YUYV >>> ALLX 4147200 1280 720 32 2 >>> Unicap buffer size is wrong, resetting it. >>> Wanted frame size 1280 x 720, got 1280 x 720 >>> >>> >>> smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 >>> which appears not to belong to us, there is no marker file >>> >>> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >>> >>>> Ho Tom, >>>> you shouldn't really need to compile unicap, if you have the package >>>> libunicap-dev installed during configure, it should be enough. >>>> Are you sure you didm't do something silly like forgetting to run "make >>>> clean" after installing unicap ? >>>> >>>> If you can attach the complete output of ./configure and make, I will >>>> take a look and see what is wrong. >>>> >>>> Regards, >>>> Gabriel. >>>> >>>> >>>> http://lives-video.com >>>> https://www.openhub.net/accounts/salsaman >>>> >>>> >>>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> >>>> wrote: >>>> >>>>> Hi, I've compiled lives from git, and was a bit disappointed to find >>>>> that Files->Add webcam/tv card... menu option showed no options. Thinking >>>>> it was a missing dependency I dug into the source code and found that maybe >>>>> if I had libunicap I would be able to see it. So I went and compiled the >>>>> latest git version of unicap which wasn't very straightforward but I >>>>> managed to do it. I recompiled lives making sure the output of ./configure >>>>> had unicap set to yes. To my surprise I didn't have the option, I feel like >>>>> I'm close but I would like to know if someone here can help me figure it >>>>> out. >>>>> >>>>> Thank you in advance for all your help, >>>>> Tom >>>>> _______________________________________________ >>>>> Lives-devel mailing list >>>>> Liv...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>>> >>>> _______________________________________________ >>>> Lives-devel mailing list >>>> Liv...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>> >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: Clay C. <cla...@gm...> - 2021-11-06 17:47:55
|
I managed to make the camera work! I'm not really sure what did it, somethings I remember doing is switching from mplayer to mpd and installing zvbi, maybe restarting could have also played a part too. Now I have a 2 questions: 1) the video I get from recording the webcam in lives is not very fluid, I switched to 30fps and if I can tell it's not the same quality that other previews, that includes the preview and a quick transcode tested with mpv separately. How can I tell if it's using MJPEG or YUYV? is there any way to switch it? Is there any way I can make it more fluid, like say other applications like OBS have done (I have noticed that YUYV is laggy like this so I suspect this is the cause of the issue but can't tell for sure)? Could this be fixed with proper configuration? or is it something that would need further development? I'm willing write code to fix this if you don't mind but wanna make sure I'm actually solving a problem and not chasing something that could have been fixed by tweaking a few settings/rebuilding lives. I really appreciate your help with pointing me to the right place to get started on this. 2) Rendering takes a long time, I tried switching the encoder settings but could you confirm this is how it should be? I suspect the recording process get's raw input from the camera and then the rendering encodes it into something lives can display? Any way to use GPU to help with this? Again pointing to the right place would help. Thank you so much for making lives, I'm enjoying the way you've setup the workflow. I think it really sets itself apart from other video editors, Tom On Fri, Nov 5, 2021 at 5:33 PM salsaman <sal...@gm...> wrote: > This looks like a bug, I will investigate. > > "Wanted frame size 1280 x 720, got 1280 x 720" > > Most likely it is a divide by 2 error somewhere, each yuyv macropixel > converts to 2 RGB pixels. > > It certainly should be possible to do what you wanted in LiVES. Just set > audio source to external, p[en webcam, hit, record then play. > Then you should be able to preview each recording before deciding > whether to render / encode it. > > Regards, > Gabriel. > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> wrote: > >> Hi Gabriel, >> >> You were right make clean allowed me to see the option. However now when >> I select any of my webcams lives doesn't open it, at the bottom of this >> email is the command line output I get when I try to set it. To be fair I >> don't think my webcams work well will YUYV, because when I go to OBS, I >> have to change to video format to one of the emulated options: BGR3, YU12, >> YV12 to be able to even see the preview. My camera has YUYV and MJPEG >> formats but I haven't been able to get MJPEG working in any program (I have >> mjpegtools installed but maybe I'm missing something). >> >> Maybe if I explain what I need to do with lives you could give me some >> advice on the best way to go about it. I'm trying to record how to play my >> own songs on guitar so I can comeback to it and just watch and relearn each >> part. I could record all the parts in advance and then import them into a >> program which is what I'm currently doing with lives. But ideally what I >> want to do is record my performance inside lives, decide if the take is >> good or not. If it's not good discard it, if it's good keep it as a clip so >> I can use the multitrack functionality after I'm done recording all parts. >> I've thought about maybe make a script with ffmpeg instead for taking the >> yes no decision on each take and then storing everything into the same >> folder that I will open later with lives. Probably what I'll end up doing >> but I'm just curious if I could make it within lives itself. >> >> Thank you for your work and help, I'm a huge fan! >> >> here is the relevant console output from running lives while trying to >> set the webcam: >> checking formats for /dev/video1 >> Checking 19 array sizes >> entry 0:640 x 480 >> Size is best so far >> entry 1:160 x 120 >> entry 2:176 x 144 >> entry 3:320 x 180 >> entry 4:320 x 240 >> entry 5:352 x 288 >> entry 6:340 x 340 >> entry 7:424 x 240 >> entry 8:440 x 440 >> entry 9:480 x 270 >> entry 10:640 x 360 >> entry 11:800 x 448 >> entry 12:800 x 600 >> Size is best so far >> entry 13:848 x 480 >> entry 14:960 x 540 >> entry 15:1024 x 576 >> entry 16:1280 x 720 >> Size is best so far >> entry 17:1600 x 896 >> entry 18:1920 x 1080 >> Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 >> >> Using palette with fourcc 0x56595559, translated as YUYV >> ALLX 4147200 1280 720 32 2 >> Unicap buffer size is wrong, resetting it. >> Wanted frame size 1280 x 720, got 1280 x 720 >> >> >> smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 >> which appears not to belong to us, there is no marker file >> >> On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: >> >>> Ho Tom, >>> you shouldn't really need to compile unicap, if you have the package >>> libunicap-dev installed during configure, it should be enough. >>> Are you sure you didm't do something silly like forgetting to run "make >>> clean" after installing unicap ? >>> >>> If you can attach the complete output of ./configure and make, I will >>> take a look and see what is wrong. >>> >>> Regards, >>> Gabriel. >>> >>> >>> http://lives-video.com >>> https://www.openhub.net/accounts/salsaman >>> >>> >>> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> wrote: >>> >>>> Hi, I've compiled lives from git, and was a bit disappointed to find >>>> that Files->Add webcam/tv card... menu option showed no options. Thinking >>>> it was a missing dependency I dug into the source code and found that maybe >>>> if I had libunicap I would be able to see it. So I went and compiled the >>>> latest git version of unicap which wasn't very straightforward but I >>>> managed to do it. I recompiled lives making sure the output of ./configure >>>> had unicap set to yes. To my surprise I didn't have the option, I feel like >>>> I'm close but I would like to know if someone here can help me figure it >>>> out. >>>> >>>> Thank you in advance for all your help, >>>> Tom >>>> _______________________________________________ >>>> Lives-devel mailing list >>>> Liv...@li... >>>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>>> >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: salsaman <sal...@gm...> - 2021-11-05 22:33:29
|
This looks like a bug, I will investigate. "Wanted frame size 1280 x 720, got 1280 x 720" Most likely it is a divide by 2 error somewhere, each yuyv macropixel converts to 2 RGB pixels. It certainly should be possible to do what you wanted in LiVES. Just set audio source to external, p[en webcam, hit, record then play. Then you should be able to preview each recording before deciding whether to render / encode it. Regards, Gabriel. http://lives-video.com https://www.openhub.net/accounts/salsaman On Fri, 5 Nov 2021 at 18:13, Clay Citadel <cla...@gm...> wrote: > Hi Gabriel, > > You were right make clean allowed me to see the option. However now when I > select any of my webcams lives doesn't open it, at the bottom of this email > is the command line output I get when I try to set it. To be fair I don't > think my webcams work well will YUYV, because when I go to OBS, I have to > change to video format to one of the emulated options: BGR3, YU12, YV12 to > be able to even see the preview. My camera has YUYV and MJPEG formats but I > haven't been able to get MJPEG working in any program (I have mjpegtools > installed but maybe I'm missing something). > > Maybe if I explain what I need to do with lives you could give me some > advice on the best way to go about it. I'm trying to record how to play my > own songs on guitar so I can comeback to it and just watch and relearn each > part. I could record all the parts in advance and then import them into a > program which is what I'm currently doing with lives. But ideally what I > want to do is record my performance inside lives, decide if the take is > good or not. If it's not good discard it, if it's good keep it as a clip so > I can use the multitrack functionality after I'm done recording all parts. > I've thought about maybe make a script with ffmpeg instead for taking the > yes no decision on each take and then storing everything into the same > folder that I will open later with lives. Probably what I'll end up doing > but I'm just curious if I could make it within lives itself. > > Thank you for your work and help, I'm a huge fan! > > here is the relevant console output from running lives while trying to set > the webcam: > checking formats for /dev/video1 > Checking 19 array sizes > entry 0:640 x 480 > Size is best so far > entry 1:160 x 120 > entry 2:176 x 144 > entry 3:320 x 180 > entry 4:320 x 240 > entry 5:352 x 288 > entry 6:340 x 340 > entry 7:424 x 240 > entry 8:440 x 440 > entry 9:480 x 270 > entry 10:640 x 360 > entry 11:800 x 448 > entry 12:800 x 600 > Size is best so far > entry 13:848 x 480 > entry 14:960 x 540 > entry 15:1024 x 576 > entry 16:1280 x 720 > Size is best so far > entry 17:1600 x 896 > entry 18:1920 x 1080 > Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 > > Using palette with fourcc 0x56595559, translated as YUYV > ALLX 4147200 1280 720 32 2 > Unicap buffer size is wrong, resetting it. > Wanted frame size 1280 x 720, got 1280 x 720 > > > smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 > which appears not to belong to us, there is no marker file > > On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: > >> Ho Tom, >> you shouldn't really need to compile unicap, if you have the package >> libunicap-dev installed during configure, it should be enough. >> Are you sure you didm't do something silly like forgetting to run "make >> clean" after installing unicap ? >> >> If you can attach the complete output of ./configure and make, I will >> take a look and see what is wrong. >> >> Regards, >> Gabriel. >> >> >> http://lives-video.com >> https://www.openhub.net/accounts/salsaman >> >> >> On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> wrote: >> >>> Hi, I've compiled lives from git, and was a bit disappointed to find >>> that Files->Add webcam/tv card... menu option showed no options. Thinking >>> it was a missing dependency I dug into the source code and found that maybe >>> if I had libunicap I would be able to see it. So I went and compiled the >>> latest git version of unicap which wasn't very straightforward but I >>> managed to do it. I recompiled lives making sure the output of ./configure >>> had unicap set to yes. To my surprise I didn't have the option, I feel like >>> I'm close but I would like to know if someone here can help me figure it >>> out. >>> >>> Thank you in advance for all your help, >>> Tom >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: Clay C. <cla...@gm...> - 2021-11-05 21:13:34
|
Hi Gabriel, You were right make clean allowed me to see the option. However now when I select any of my webcams lives doesn't open it, at the bottom of this email is the command line output I get when I try to set it. To be fair I don't think my webcams work well will YUYV, because when I go to OBS, I have to change to video format to one of the emulated options: BGR3, YU12, YV12 to be able to even see the preview. My camera has YUYV and MJPEG formats but I haven't been able to get MJPEG working in any program (I have mjpegtools installed but maybe I'm missing something). Maybe if I explain what I need to do with lives you could give me some advice on the best way to go about it. I'm trying to record how to play my own songs on guitar so I can comeback to it and just watch and relearn each part. I could record all the parts in advance and then import them into a program which is what I'm currently doing with lives. But ideally what I want to do is record my performance inside lives, decide if the take is good or not. If it's not good discard it, if it's good keep it as a clip so I can use the multitrack functionality after I'm done recording all parts. I've thought about maybe make a script with ffmpeg instead for taking the yes no decision on each take and then storing everything into the same folder that I will open later with lives. Probably what I'll end up doing but I'm just curious if I could make it within lives itself. Thank you for your work and help, I'm a huge fan! here is the relevant console output from running lives while trying to set the webcam: checking formats for /dev/video1 Checking 19 array sizes entry 0:640 x 480 Size is best so far entry 1:160 x 120 entry 2:176 x 144 entry 3:320 x 180 entry 4:320 x 240 entry 5:352 x 288 entry 6:340 x 340 entry 7:424 x 240 entry 8:440 x 440 entry 9:480 x 270 entry 10:640 x 360 entry 11:800 x 448 entry 12:800 x 600 Size is best so far entry 13:848 x 480 entry 14:960 x 540 entry 15:1024 x 576 entry 16:1280 x 720 Size is best so far entry 17:1600 x 896 entry 18:1920 x 1080 Unusable palette with fourcc 0x47504a4d bpp=0, size=1920x1080 buf=0 Using palette with fourcc 0x56595559, translated as YUYV ALLX 4147200 1280 720 32 2 Unicap buffer size is wrong, resetting it. Wanted frame size 1280 x 720, got 1280 x 720 smogrify: WARNING ! asked to close dir /dev/shm/livesprojects/882280649 which appears not to belong to us, there is no marker file On Thu, Nov 4, 2021 at 10:28 PM salsaman <sal...@gm...> wrote: > Ho Tom, > you shouldn't really need to compile unicap, if you have the package > libunicap-dev installed during configure, it should be enough. > Are you sure you didm't do something silly like forgetting to run "make > clean" after installing unicap ? > > If you can attach the complete output of ./configure and make, I will take > a look and see what is wrong. > > Regards, > Gabriel. > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> wrote: > >> Hi, I've compiled lives from git, and was a bit disappointed to find that >> Files->Add webcam/tv card... menu option showed no options. Thinking it was >> a missing dependency I dug into the source code and found that maybe if I >> had libunicap I would be able to see it. So I went and compiled the latest >> git version of unicap which wasn't very straightforward but I managed to do >> it. I recompiled lives making sure the output of ./configure had unicap set >> to yes. To my surprise I didn't have the option, I feel like I'm close but >> I would like to know if someone here can help me figure it out. >> >> Thank you in advance for all your help, >> Tom >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: salsaman <sal...@gm...> - 2021-11-05 03:28:42
|
Ho Tom, you shouldn't really need to compile unicap, if you have the package libunicap-dev installed during configure, it should be enough. Are you sure you didm't do something silly like forgetting to run "make clean" after installing unicap ? If you can attach the complete output of ./configure and make, I will take a look and see what is wrong. Regards, Gabriel. http://lives-video.com https://www.openhub.net/accounts/salsaman On Thu, 4 Nov 2021 at 23:42, Clay Citadel <cla...@gm...> wrote: > Hi, I've compiled lives from git, and was a bit disappointed to find that > Files->Add webcam/tv card... menu option showed no options. Thinking it was > a missing dependency I dug into the source code and found that maybe if I > had libunicap I would be able to see it. So I went and compiled the latest > git version of unicap which wasn't very straightforward but I managed to do > it. I recompiled lives making sure the output of ./configure had unicap set > to yes. To my surprise I didn't have the option, I feel like I'm close but > I would like to know if someone here can help me figure it out. > > Thank you in advance for all your help, > Tom > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: Clay C. <cla...@gm...> - 2021-11-05 02:42:25
|
Hi, I've compiled lives from git, and was a bit disappointed to find that Files->Add webcam/tv card... menu option showed no options. Thinking it was a missing dependency I dug into the source code and found that maybe if I had libunicap I would be able to see it. So I went and compiled the latest git version of unicap which wasn't very straightforward but I managed to do it. I recompiled lives making sure the output of ./configure had unicap set to yes. To my surprise I didn't have the option, I feel like I'm close but I would like to know if someone here can help me figure it out. Thank you in advance for all your help, Tom |
|
From: salsaman <sal...@gm...> - 2016-10-20 17:19:00
|
On Thu, Oct 20, 2016 at 1:14 PM, Doug Webb <Dou...@sh...> wrote: > In screen 1 the top row of colors has a purple square. In screen 2 I have > clicked on this square and it is changed to brown which is the color I was > using previously, however the color I picked would be purple. Lives is > drawing brown over the purple in error. > > Here's a link to the images. > > https://drive.google.com/open?id=0B1vkg_sxbq-RMGc3dmlYTTVvaEk > > > https://drive.google.com/open?id=0B1vkg_sxbq-RbjFpaURVWWlHN1k > > > Ah OK. I see the same thing, but it's a GTK+ issue - LiVES just uses the colour picker from GTK. Also it is going brown because that is your "selected" colour in the gtk+ theme (not because brown was the previous colour). > > > On 2016-10-16 08:41 PM, salsaman wrote: > > > On Sun, Oct 16, 2016 at 4:45 PM, Doug Webb <Dou...@sh...> wrote: > >> In the Text Overlay Color Picker, if a second choice is made, the first >> color overwrites the second however after confirming, the correct color >> is displayed. >> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > > > Hi Doug, > I am not sure what you mean by "the first color overwrites the second". > Can you send a screenshot to illustrate it ? > > > Regards, > Gabriel. > > > > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Lives-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/lives-devel > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > > |
|
From: Doug W. <Dou...@sh...> - 2016-10-20 16:30:08
|
In screen 1 the top row of colors has a purple square. In screen 2 I have clicked on this square and it is changed to brown which is the color I was using previously, however the color I picked would be purple. Lives is drawing brown over the purple in error. Here's a link to the images. https://drive.google.com/open?id=0B1vkg_sxbq-RMGc3dmlYTTVvaEk https://drive.google.com/open?id=0B1vkg_sxbq-RbjFpaURVWWlHN1k On 2016-10-16 08:41 PM, salsaman wrote: > > On Sun, Oct 16, 2016 at 4:45 PM, Doug Webb <Dou...@sh... > <mailto:Dou...@sh...>> wrote: > > In the Text Overlay Color Picker, if a second choice is made, the > first > color overwrites the second however after confirming, the correct > color > is displayed. > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Lives-devel mailing list > Liv...@li... > <mailto:Liv...@li...> > https://lists.sourceforge.net/lists/listinfo/lives-devel > <https://lists.sourceforge.net/lists/listinfo/lives-devel> > > > > Hi Doug, > I am not sure what you mean by "the first color overwrites the > second". Can you send a screenshot to illustrate it ? > > > Regards, > Gabriel. > > > > > > http://lives-video.com > https://www.openhub.net/accounts/salsaman > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel |
|
From: salsaman <sal...@gm...> - 2016-10-17 03:41:54
|
On Sun, Oct 16, 2016 at 4:45 PM, Doug Webb <Dou...@sh...> wrote: > In the Text Overlay Color Picker, if a second choice is made, the first > color overwrites the second however after confirming, the correct color > is displayed. > > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > Hi Doug, I am not sure what you mean by "the first color overwrites the second". Can you send a screenshot to illustrate it ? Regards, Gabriel. http://lives-video.com https://www.openhub.net/accounts/salsaman |
|
From: Doug W. <Dou...@sh...> - 2016-10-16 19:45:28
|
In the Text Overlay Color Picker, if a second choice is made, the first color overwrites the second however after confirming, the correct color is displayed. |
|
From: salsaman <sal...@gm...> - 2015-06-23 00:05:11
|
Hi all, initial documentation for this exciting new way of working with LiVES is now up on the new site. C++ scripting with LiVES is now a reality ! PDF here: http://lives-video.com/docs/c++-bindings.pdf liblives itself is documented here: http://lives-video.com/doxygen/liblives/ Feedback welcome ! I hope some people find this useful. Regards, Gabriel. http://lives-video.com https://www.openhub.net/accounts/salsaman |
|
From: salsaman <sal...@gm...> - 2015-03-11 23:52:08
|
On Wed, Mar 11, 2015 at 11:20 AM, cjl...@pa... <cjl...@pa...> wrote: > I'm not much of a programmer, but I do understand a bit. I was a > mainframe programmer in an earlier life. I like your new features and your > constant attention to fix bugs and make improvements. Thanks. That's good to hear ! > Lives is my main editing software because it breaks it down into frames > and allows scrubbing at that level. I make videos for such things as > charity events and educational purposes. I sometimes use old film as > source. I like being able to edit and render from the frame level. Also, > I like the support for so many addons and formats. Thanks. I'll have to > see how to use it with the C++ you mentioned for 2.4 > > Cool. I am having a lot of fun with it already. I can see it as being quite useful in LiVES, for example for adding custom menu entries, these could be written as scriptlets and compiled with the main LiVES application. Also it could be very useful for things like automating workflows and for creating tutorials to guide users through various activities, as well as for special purposes, for example installations or shows. I am not so familiar with C++, more so with plain C, so it would be nice if someone who is more au=fait with C++ could take a look at the classes and methods and tell me if it looks OK. The idea is also to make the LiVES code more accessible to other programmers. Gabriel. > |
|
From: salsaman <sal...@gm...> - 2015-03-11 00:25:14
|
Since it seems like nobody had anything at all to say about this amazing new feature, I will just continue as I see fit then. Here is the up-to-date version of the document, in case anybody is inclined to follow this: https://sourceforge.net/p/lives/code/HEAD/tree/trunk/docs/c++-bindings.odt Hope I am not interrupting the lively discussion going on in here. Regards, Gabriel. http://lives.sourceforge.net https://www.openhub.net/accounts/salsaman On Thu, Feb 26, 2015 at 10:56 AM, salsaman <sal...@gm...> wrote: > Hi folks, > here is a sneak preview of one of the new features which I am developing > for 2.4: > namely, C++ language bindings for LiVES. > > It's now possible to compile LiVES as a library (liblives) and link it in > to your own C++ programs, giving you programatic control over the operation > of the program. > > Attached are the first few sections of the documentation, which is very > much a work in progress. However it should be possible to run all of the > examples using the current SVN version. > > > Any comments or suggestions are welcome. If you have any ideas for the > development of this feature now is your chance to voice them. > > Regards, > Gabriel. > > > > http://lives.sourceforge.net > https://www.openhub.net/accounts/salsaman > |
|
From: salsaman <sal...@gm...> - 2013-07-04 22:47:28
|
configure should check if you have those dev packages installed and if not then flv_decoder will not be built. They are optional requirements. Sounds like you have a broken pkg-config on your system. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman On Thu, Jul 4, 2013 at 5:22 PM, VJ pixel <vj...@gm...> wrote: > it seems that some -dev packages are needed in LiVES, but aren't listed on > the site. > > first I needed to install libavformat, now libavcodec. > > > > > On Thu, Jul 4, 2013 at 5:18 PM, VJ pixel <vj...@gm...> wrote: >> >> I solved the previous problem. now I got: >> >> flv_decoder.c:59:34: fatal error: libavformat/avformat.h: No such file or >> directory >> compilation terminated. >> make[3]: ** [flv_decoder_la-flv_decoder.lo] Erro 1 >> make[3]: Saindo do diretório >> `/home/pixel/lives-2.0.5/lives-plugins/plugins/decoders' >> make[2]: ** [all-recursive] Erro 1 >> make[2]: Saindo do diretório >> `/home/pixel/lives-2.0.5/lives-plugins/plugins' >> make[1]: ** [all-recursive] Erro 1 >> make[1]: Saindo do diretório `/home/pixel/lives-2.0.5/lives-plugins' >> make: ** [all-recursive] Erro 1 >> >> >> >> >> On Thu, Jul 4, 2013 at 5:13 PM, salsaman <sal...@gm...> wrote: >>> >>> Are you running it offline ? Sounds like autopoint is failing to >>> download some required gettext files. >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jul 4, 2013 at 2:44 PM, VJ pixel <vj...@gm...> wrote: >>> > I'm trying to compile LiVES. when I run ./autogen.sh I got: >>> > >>> > Preparing build ... configure.in:98: required file `./config.rpath' not >>> > found >>> > configure.in:830: required file `intl/Makefile.in' not found >>> > configure.in:98: required file `./ABOUT-NLS' not found >>> > Makefile.am:30: required directory ./intl does not exist >>> > ERROR: automake failed >>> > >>> > >>> > >>> > >>> > On Wed, Jul 3, 2013 at 9:49 AM, VJ pixel <vj...@gm...> wrote: >>> >> >>> >> I think that a way to show foreground clip is to show it over the >>> >> other, >>> >> like this: >>> >> >>> >> https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg >>> >> >>> >> maybe the better way to show parameters in the way that you proposed >>> >> is to >>> >> use a checkbox that but them in a horizontal scrooling list. >>> >> >>> >> I'm in FISL right now. I'll try to download the svn version, but maybe >>> >> I'll only can do that next week. >>> >> >>> >> >>> >> >>> >> >>> >> On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: >>> >>> >>> >>> On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: >>> >>> > I think your mail did'n came to the list because of the attachment. >>> >>> >>> >>> OK, I will see if I can liberate it ! >>> >>> >>> >>> > >>> >>> > in my opinion, the name and number of frames of the clip isn't >>> >>> > necessary. >>> >>> > >>> >>> >>> >>> Maybe not number of frames, but I think it is useful to show the clip >>> >>> name at least. Maybe it could show as a tooltip if the mouse is >>> >>> hovered over it. >>> >>> >>> >>> >>> >>> > I know that the effects are applied in a specific order (ie. >>> >>> > doesn't >>> >>> > matter >>> >>> > with order I activate effects, they will be always applied to the >>> >>> > video >>> >>> > in >>> >>> > the same order). I think that the the order of the effects in the >>> >>> > list >>> >>> > should be the same they are applied. also, should be good to have >>> >>> > the >>> >>> > effects arranged in categories (generative, transition, etc). >>> >>> >>> >>> >>> >>> >>> >>> One possibility would be to allow the user to click on an effect and >>> >>> drag it to another position in the list. Then the effects would >>> >>> always >>> >>> be applied in order from top to bottom, but you could change the >>> >>> order. I think that could be done without changing the existing >>> >>> functionality too much. >>> >>> >>> >>> Again, a tooltip could be added so hovering the mouse over would show >>> >>> the effect type (effect, transition, generator). >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > >>> >>> > would be good to have a indication of what clip is in the >>> >>> > foreground, >>> >>> > what's >>> >>> > in the background. >>> >>> > >>> >>> >>> >>> Yes I agree. But i couldnt think of any good way to show that >>> >>> visually. The forground clip could be highlighted in some way, but >>> >>> what should be done to indicate the background clip ? >>> >>> >>> >>> >>> >>> >>> >>> > I think that better than having a checkbox to choose the effects >>> >>> > that >>> >>> > will >>> >>> > have their parameters shown, would be showing the parameters of the >>> >>> > last >>> >>> > effect clicked in the reserved area for parameters. >>> >>> > >>> >>> >>> >>> Thats possible, but I was thinking maybe it would be good to show >>> >>> parameters from more that one effect. Maybe you could somehow "pin" >>> >>> the parameters so they stay there and the next effect just adds its >>> >>> own parameters as well. But again, what is a good way to "pin" them ? >>> >>> >>> >>> >>> >>> > also, would be good to have buttons for the some shortcuts (at >>> >>> > least >>> >>> > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, >>> >>> > ctrl-backspace, >>> >>> > n) >>> >>> > >>> >>> >>> >>> Yes, that could be cool. I'm not so sure about ctrl-left and >>> >>> ctrl-right because these are used for scratching, which is much >>> >>> better >>> >>> done by the keyboard or MIDI/joystick than by clicking buttons. >>> >>> >>> >>> Did you download the svn version yet ? It would be good if you could >>> >>> test things out. >>> >>> >>> >>> >>> >>> Gabriel. >>> >>> >>> >>> >>> >>> >>> >>> > ++ >>> >>> > >>> >>> > Yes agreed, that would be nice. I'm attaching a screenshot of the >>> >>> > current layout, which is in svn. I was thinking maybe the left hand >>> >>> > side could show the effect keys arranged vertically in a scrolled >>> >>> > window. Then each key would have a combo box for the effect modes. >>> >>> > Each key would also have a checkbox for "show parameters". >>> >>> > Activating >>> >>> > the checkbox would add a box with the parameters at the bottom half >>> >>> > of >>> >>> > the screen, which would be reserved for parameters. >>> >>> > >>> >>> > Do you have any better suggestions ? >>> >>> > >>> >>> > >>> >>> > Gabriel. >>> >>> > >>> >>> > >>> >>> > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: >>> >>> >> >>> >>> >> I think that to have a list of effects assigned to keys, with >>> >>> >> options >>> >>> >> to >>> >>> >> enable/dislabe and change values of every paremeter would be very >>> >>> >> good. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> >>> >>> >> wrote: >>> >>> >>> >>> >>> >>> OK folks, >>> >>> >>> so I have decided to implement a new feature in LiVES. >>> >>> >>> >>> >>> >>> When playing back in the clip editor in fullscreen, separate >>> >>> >>> window >>> >>> >>> mode, and the playback monitor and gui monitor are set to >>> >>> >>> different >>> >>> >>> values (i.e. dual head mode), LiVES will optionally show clip >>> >>> >>> thumbnails in the gui window (in plcae of the normal gui window). >>> >>> >>> By >>> >>> >>> clicking on the thumbnails it will be possible to change clips >>> >>> >>> (so it >>> >>> >>> will be something like Resolume I think). >>> >>> >>> >>> >>> >>> Does anybody have any suggestions for how this should look ? >>> >>> >>> Apart >>> >>> >>> from thumbnails of clips, what other features would be useful in >>> >>> >>> this >>> >>> >>> mode ? Maybe effects on / off, effect parameters, fps....how >>> >>> >>> about a >>> >>> >>> button to select whether the next clip change affects forgeground >>> >>> >>> or >>> >>> >>> background clip ? Maybe more than two clips (foreground and >>> >>> >>> background) could be selected...i.e some kind of video mapping. >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> Gabriel. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> http://lives.sourceforge.net >>> >>> >>> https://www.ohloh.net/accounts/salsaman >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> This SF.net email is sponsored by Windows: >>> >>> >>> >>> >>> >>> Build for Windows Store. >>> >>> >>> >>> >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> >>> >>> _______________________________________________ >>> >>> >>> Lives-devel mailing list >>> >>> >>> Liv...@li... >>> >>> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> -- >>> >>> >> VJ pixel >>> >>> >> >>> >>> >> http://memelab.com.br >>> >>> >> R. Vitorino Carmilo, 459 - Barra Funda >>> >>> >> São Paulo - SP - Brasil >>> >>> >> +55 11 3662 5702 >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > VJ pixel >>> >>> > >>> >>> > http://memelab.com.br >>> >>> > R. Vitorino Carmilo, 459 - Barra Funda >>> >>> > São Paulo - SP - Brasil >>> >>> > +55 11 3662 5702 >>> >>> > >>> >>> > >>> >>> > >>> >>> > ------------------------------------------------------------------------------ >>> >>> > This SF.net email is sponsored by Windows: >>> >>> > >>> >>> > Build for Windows Store. >>> >>> > >>> >>> > http://p.sf.net/sfu/windows-dev2dev >>> >>> > _______________________________________________ >>> >>> > Lives-devel mailing list >>> >>> > Liv...@li... >>> >>> > https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> This SF.net email is sponsored by Windows: >>> >>> >>> >>> Build for Windows Store. >>> >>> >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> >>> _______________________________________________ >>> >>> Lives-devel mailing list >>> >>> Liv...@li... >>> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> VJ pixel >>> >> >>> >> http://memelab.com.br >>> >> R. Vitorino Carmilo, 459 - Barra Funda >>> >> São Paulo - SP - Brasil >>> >> +55 11 3662 5702 >>> > >>> > >>> > >>> > >>> > -- >>> > VJ pixel >>> > >>> > http://memelab.com.br >>> > R. Vitorino Carmilo, 459 - Barra Funda >>> > São Paulo - SP - Brasil >>> > +55 11 3662 5702 >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > This SF.net email is sponsored by Windows: >>> > >>> > Build for Windows Store. >>> > >>> > http://p.sf.net/sfu/windows-dev2dev >>> > _______________________________________________ >>> > Lives-devel mailing list >>> > Liv...@li... >>> > https://lists.sourceforge.net/lists/listinfo/lives-devel >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >> >> >> >> >> -- >> VJ pixel >> >> http://memelab.com.br >> R. Vitorino Carmilo, 459 - Barra Funda >> São Paulo - SP - Brasil >> +55 11 3662 5702 > > > > > -- > VJ pixel > > http://memelab.com.br > R. Vitorino Carmilo, 459 - Barra Funda > São Paulo - SP - Brasil > +55 11 3662 5702 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: VJ p. <vj...@gm...> - 2013-07-04 20:22:37
|
it seems that some -dev packages are needed in LiVES, but aren't listed on the site. first I needed to install libavformat, now libavcodec. On Thu, Jul 4, 2013 at 5:18 PM, VJ pixel <vj...@gm...> wrote: > I solved the previous problem. now I got: > > flv_decoder.c:59:34: fatal error: libavformat/avformat.h: No such file or > directory > compilation terminated. > make[3]: ** [flv_decoder_la-flv_decoder.lo] Erro 1 > make[3]: Saindo do diretório > `/home/pixel/lives-2.0.5/lives-plugins/plugins/decoders' > make[2]: ** [all-recursive] Erro 1 > make[2]: Saindo do diretório > `/home/pixel/lives-2.0.5/lives-plugins/plugins' > make[1]: ** [all-recursive] Erro 1 > make[1]: Saindo do diretório `/home/pixel/lives-2.0.5/lives-plugins' > make: ** [all-recursive] Erro 1 > > > > > On Thu, Jul 4, 2013 at 5:13 PM, salsaman <sal...@gm...> wrote: > >> Are you running it offline ? Sounds like autopoint is failing to >> download some required gettext files. >> >> >> >> >> >> >> >> On Thu, Jul 4, 2013 at 2:44 PM, VJ pixel <vj...@gm...> wrote: >> > I'm trying to compile LiVES. when I run ./autogen.sh I got: >> > >> > Preparing build ... configure.in:98: required file `./config.rpath' not >> > found >> > configure.in:830: required file `intl/Makefile.in' not found >> > configure.in:98: required file `./ABOUT-NLS' not found >> > Makefile.am:30: required directory ./intl does not exist >> > ERROR: automake failed >> > >> > >> > >> > >> > On Wed, Jul 3, 2013 at 9:49 AM, VJ pixel <vj...@gm...> wrote: >> >> >> >> I think that a way to show foreground clip is to show it over the >> other, >> >> like this: >> >> >> https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg >> >> >> >> maybe the better way to show parameters in the way that you proposed >> is to >> >> use a checkbox that but them in a horizontal scrooling list. >> >> >> >> I'm in FISL right now. I'll try to download the svn version, but maybe >> >> I'll only can do that next week. >> >> >> >> >> >> >> >> >> >> On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: >> >>> >> >>> On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: >> >>> > I think your mail did'n came to the list because of the attachment. >> >>> >> >>> OK, I will see if I can liberate it ! >> >>> >> >>> > >> >>> > in my opinion, the name and number of frames of the clip isn't >> >>> > necessary. >> >>> > >> >>> >> >>> Maybe not number of frames, but I think it is useful to show the clip >> >>> name at least. Maybe it could show as a tooltip if the mouse is >> >>> hovered over it. >> >>> >> >>> >> >>> > I know that the effects are applied in a specific order (ie. doesn't >> >>> > matter >> >>> > with order I activate effects, they will be always applied to the >> video >> >>> > in >> >>> > the same order). I think that the the order of the effects in the >> list >> >>> > should be the same they are applied. also, should be good to have >> the >> >>> > effects arranged in categories (generative, transition, etc). >> >>> >> >>> >> >>> >> >>> One possibility would be to allow the user to click on an effect and >> >>> drag it to another position in the list. Then the effects would always >> >>> be applied in order from top to bottom, but you could change the >> >>> order. I think that could be done without changing the existing >> >>> functionality too much. >> >>> >> >>> Again, a tooltip could be added so hovering the mouse over would show >> >>> the effect type (effect, transition, generator). >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> > >> >>> > would be good to have a indication of what clip is in the >> foreground, >> >>> > what's >> >>> > in the background. >> >>> > >> >>> >> >>> Yes I agree. But i couldnt think of any good way to show that >> >>> visually. The forground clip could be highlighted in some way, but >> >>> what should be done to indicate the background clip ? >> >>> >> >>> >> >>> >> >>> > I think that better than having a checkbox to choose the effects >> that >> >>> > will >> >>> > have their parameters shown, would be showing the parameters of the >> >>> > last >> >>> > effect clicked in the reserved area for parameters. >> >>> > >> >>> >> >>> Thats possible, but I was thinking maybe it would be good to show >> >>> parameters from more that one effect. Maybe you could somehow "pin" >> >>> the parameters so they stay there and the next effect just adds its >> >>> own parameters as well. But again, what is a good way to "pin" them ? >> >>> >> >>> >> >>> > also, would be good to have buttons for the some shortcuts (at least >> >>> > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, >> ctrl-backspace, >> >>> > n) >> >>> > >> >>> >> >>> Yes, that could be cool. I'm not so sure about ctrl-left and >> >>> ctrl-right because these are used for scratching, which is much better >> >>> done by the keyboard or MIDI/joystick than by clicking buttons. >> >>> >> >>> Did you download the svn version yet ? It would be good if you could >> >>> test things out. >> >>> >> >>> >> >>> Gabriel. >> >>> >> >>> >> >>> >> >>> > ++ >> >>> > >> >>> > Yes agreed, that would be nice. I'm attaching a screenshot of the >> >>> > current layout, which is in svn. I was thinking maybe the left hand >> >>> > side could show the effect keys arranged vertically in a scrolled >> >>> > window. Then each key would have a combo box for the effect modes. >> >>> > Each key would also have a checkbox for "show parameters". >> Activating >> >>> > the checkbox would add a box with the parameters at the bottom half >> of >> >>> > the screen, which would be reserved for parameters. >> >>> > >> >>> > Do you have any better suggestions ? >> >>> > >> >>> > >> >>> > Gabriel. >> >>> > >> >>> > >> >>> > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: >> >>> >> >> >>> >> I think that to have a list of effects assigned to keys, with >> options >> >>> >> to >> >>> >> enable/dislabe and change values of every paremeter would be very >> >>> >> good. >> >>> >> >> >>> >> >> >>> >> >> >>> >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> >> wrote: >> >>> >>> >> >>> >>> OK folks, >> >>> >>> so I have decided to implement a new feature in LiVES. >> >>> >>> >> >>> >>> When playing back in the clip editor in fullscreen, separate >> window >> >>> >>> mode, and the playback monitor and gui monitor are set to >> different >> >>> >>> values (i.e. dual head mode), LiVES will optionally show clip >> >>> >>> thumbnails in the gui window (in plcae of the normal gui window). >> By >> >>> >>> clicking on the thumbnails it will be possible to change clips >> (so it >> >>> >>> will be something like Resolume I think). >> >>> >>> >> >>> >>> Does anybody have any suggestions for how this should look ? Apart >> >>> >>> from thumbnails of clips, what other features would be useful in >> this >> >>> >>> mode ? Maybe effects on / off, effect parameters, fps....how >> about a >> >>> >>> button to select whether the next clip change affects forgeground >> or >> >>> >>> background clip ? Maybe more than two clips (foreground and >> >>> >>> background) could be selected...i.e some kind of video mapping. >> >>> >>> >> >>> >>> Regards, >> >>> >>> Gabriel. >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> http://lives.sourceforge.net >> >>> >>> https://www.ohloh.net/accounts/salsaman >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> ------------------------------------------------------------------------------ >> >>> >>> This SF.net email is sponsored by Windows: >> >>> >>> >> >>> >>> Build for Windows Store. >> >>> >>> >> >>> >>> http://p.sf.net/sfu/windows-dev2dev >> >>> >>> _______________________________________________ >> >>> >>> Lives-devel mailing list >> >>> >>> Liv...@li... >> >>> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> VJ pixel >> >>> >> >> >>> >> http://memelab.com.br >> >>> >> R. Vitorino Carmilo, 459 - Barra Funda >> >>> >> São Paulo - SP - Brasil >> >>> >> +55 11 3662 5702 >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > VJ pixel >> >>> > >> >>> > http://memelab.com.br >> >>> > R. Vitorino Carmilo, 459 - Barra Funda >> >>> > São Paulo - SP - Brasil >> >>> > +55 11 3662 5702 >> >>> > >> >>> > >> >>> > >> ------------------------------------------------------------------------------ >> >>> > This SF.net email is sponsored by Windows: >> >>> > >> >>> > Build for Windows Store. >> >>> > >> >>> > http://p.sf.net/sfu/windows-dev2dev >> >>> > _______________________________________________ >> >>> > Lives-devel mailing list >> >>> > Liv...@li... >> >>> > https://lists.sourceforge.net/lists/listinfo/lives-devel >> >>> > >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF.net email is sponsored by Windows: >> >>> >> >>> Build for Windows Store. >> >>> >> >>> http://p.sf.net/sfu/windows-dev2dev >> >>> _______________________________________________ >> >>> Lives-devel mailing list >> >>> Liv...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >> >> >> >> >> >> >> >> >> >> -- >> >> VJ pixel >> >> >> >> http://memelab.com.br >> >> R. Vitorino Carmilo, 459 - Barra Funda >> >> São Paulo - SP - Brasil >> >> +55 11 3662 5702 >> > >> > >> > >> > >> > -- >> > VJ pixel >> > >> > http://memelab.com.br >> > R. Vitorino Carmilo, 459 - Barra Funda >> > São Paulo - SP - Brasil >> > +55 11 3662 5702 >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Windows: >> > >> > Build for Windows Store. >> > >> > http://p.sf.net/sfu/windows-dev2dev >> > _______________________________________________ >> > Lives-devel mailing list >> > Liv...@li... >> > https://lists.sourceforge.net/lists/listinfo/lives-devel >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > > > > -- > VJ pixel > > http://memelab.com.br > R. Vitorino Carmilo, 459 - Barra Funda > São Paulo - SP - Brasil > +55 11 3662 5702 > -- VJ pixel http://memelab.com.br R. Vitorino Carmilo, 459 - Barra Funda São Paulo - SP - Brasil +55 11 3662 5702 |
|
From: VJ p. <vj...@gm...> - 2013-07-04 20:18:39
|
I solved the previous problem. now I got: flv_decoder.c:59:34: fatal error: libavformat/avformat.h: No such file or directory compilation terminated. make[3]: ** [flv_decoder_la-flv_decoder.lo] Erro 1 make[3]: Saindo do diretório `/home/pixel/lives-2.0.5/lives-plugins/plugins/decoders' make[2]: ** [all-recursive] Erro 1 make[2]: Saindo do diretório `/home/pixel/lives-2.0.5/lives-plugins/plugins' make[1]: ** [all-recursive] Erro 1 make[1]: Saindo do diretório `/home/pixel/lives-2.0.5/lives-plugins' make: ** [all-recursive] Erro 1 On Thu, Jul 4, 2013 at 5:13 PM, salsaman <sal...@gm...> wrote: > Are you running it offline ? Sounds like autopoint is failing to > download some required gettext files. > > > > > > > > On Thu, Jul 4, 2013 at 2:44 PM, VJ pixel <vj...@gm...> wrote: > > I'm trying to compile LiVES. when I run ./autogen.sh I got: > > > > Preparing build ... configure.in:98: required file `./config.rpath' not > > found > > configure.in:830: required file `intl/Makefile.in' not found > > configure.in:98: required file `./ABOUT-NLS' not found > > Makefile.am:30: required directory ./intl does not exist > > ERROR: automake failed > > > > > > > > > > On Wed, Jul 3, 2013 at 9:49 AM, VJ pixel <vj...@gm...> wrote: > >> > >> I think that a way to show foreground clip is to show it over the other, > >> like this: > >> > https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg > >> > >> maybe the better way to show parameters in the way that you proposed is > to > >> use a checkbox that but them in a horizontal scrooling list. > >> > >> I'm in FISL right now. I'll try to download the svn version, but maybe > >> I'll only can do that next week. > >> > >> > >> > >> > >> On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: > >>> > >>> On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: > >>> > I think your mail did'n came to the list because of the attachment. > >>> > >>> OK, I will see if I can liberate it ! > >>> > >>> > > >>> > in my opinion, the name and number of frames of the clip isn't > >>> > necessary. > >>> > > >>> > >>> Maybe not number of frames, but I think it is useful to show the clip > >>> name at least. Maybe it could show as a tooltip if the mouse is > >>> hovered over it. > >>> > >>> > >>> > I know that the effects are applied in a specific order (ie. doesn't > >>> > matter > >>> > with order I activate effects, they will be always applied to the > video > >>> > in > >>> > the same order). I think that the the order of the effects in the > list > >>> > should be the same they are applied. also, should be good to have the > >>> > effects arranged in categories (generative, transition, etc). > >>> > >>> > >>> > >>> One possibility would be to allow the user to click on an effect and > >>> drag it to another position in the list. Then the effects would always > >>> be applied in order from top to bottom, but you could change the > >>> order. I think that could be done without changing the existing > >>> functionality too much. > >>> > >>> Again, a tooltip could be added so hovering the mouse over would show > >>> the effect type (effect, transition, generator). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > >>> > would be good to have a indication of what clip is in the foreground, > >>> > what's > >>> > in the background. > >>> > > >>> > >>> Yes I agree. But i couldnt think of any good way to show that > >>> visually. The forground clip could be highlighted in some way, but > >>> what should be done to indicate the background clip ? > >>> > >>> > >>> > >>> > I think that better than having a checkbox to choose the effects that > >>> > will > >>> > have their parameters shown, would be showing the parameters of the > >>> > last > >>> > effect clicked in the reserved area for parameters. > >>> > > >>> > >>> Thats possible, but I was thinking maybe it would be good to show > >>> parameters from more that one effect. Maybe you could somehow "pin" > >>> the parameters so they stay there and the next effect just adds its > >>> own parameters as well. But again, what is a good way to "pin" them ? > >>> > >>> > >>> > also, would be good to have buttons for the some shortcuts (at least > >>> > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, > ctrl-backspace, > >>> > n) > >>> > > >>> > >>> Yes, that could be cool. I'm not so sure about ctrl-left and > >>> ctrl-right because these are used for scratching, which is much better > >>> done by the keyboard or MIDI/joystick than by clicking buttons. > >>> > >>> Did you download the svn version yet ? It would be good if you could > >>> test things out. > >>> > >>> > >>> Gabriel. > >>> > >>> > >>> > >>> > ++ > >>> > > >>> > Yes agreed, that would be nice. I'm attaching a screenshot of the > >>> > current layout, which is in svn. I was thinking maybe the left hand > >>> > side could show the effect keys arranged vertically in a scrolled > >>> > window. Then each key would have a combo box for the effect modes. > >>> > Each key would also have a checkbox for "show parameters". Activating > >>> > the checkbox would add a box with the parameters at the bottom half > of > >>> > the screen, which would be reserved for parameters. > >>> > > >>> > Do you have any better suggestions ? > >>> > > >>> > > >>> > Gabriel. > >>> > > >>> > > >>> > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: > >>> >> > >>> >> I think that to have a list of effects assigned to keys, with > options > >>> >> to > >>> >> enable/dislabe and change values of every paremeter would be very > >>> >> good. > >>> >> > >>> >> > >>> >> > >>> >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> > wrote: > >>> >>> > >>> >>> OK folks, > >>> >>> so I have decided to implement a new feature in LiVES. > >>> >>> > >>> >>> When playing back in the clip editor in fullscreen, separate window > >>> >>> mode, and the playback monitor and gui monitor are set to different > >>> >>> values (i.e. dual head mode), LiVES will optionally show clip > >>> >>> thumbnails in the gui window (in plcae of the normal gui window). > By > >>> >>> clicking on the thumbnails it will be possible to change clips (so > it > >>> >>> will be something like Resolume I think). > >>> >>> > >>> >>> Does anybody have any suggestions for how this should look ? Apart > >>> >>> from thumbnails of clips, what other features would be useful in > this > >>> >>> mode ? Maybe effects on / off, effect parameters, fps....how about > a > >>> >>> button to select whether the next clip change affects forgeground > or > >>> >>> background clip ? Maybe more than two clips (foreground and > >>> >>> background) could be selected...i.e some kind of video mapping. > >>> >>> > >>> >>> Regards, > >>> >>> Gabriel. > >>> >>> > >>> >>> > >>> >>> > >>> >>> http://lives.sourceforge.net > >>> >>> https://www.ohloh.net/accounts/salsaman > >>> >>> > >>> >>> > >>> >>> > >>> >>> > ------------------------------------------------------------------------------ > >>> >>> This SF.net email is sponsored by Windows: > >>> >>> > >>> >>> Build for Windows Store. > >>> >>> > >>> >>> http://p.sf.net/sfu/windows-dev2dev > >>> >>> _______________________________________________ > >>> >>> Lives-devel mailing list > >>> >>> Liv...@li... > >>> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> VJ pixel > >>> >> > >>> >> http://memelab.com.br > >>> >> R. Vitorino Carmilo, 459 - Barra Funda > >>> >> São Paulo - SP - Brasil > >>> >> +55 11 3662 5702 > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > VJ pixel > >>> > > >>> > http://memelab.com.br > >>> > R. Vitorino Carmilo, 459 - Barra Funda > >>> > São Paulo - SP - Brasil > >>> > +55 11 3662 5702 > >>> > > >>> > > >>> > > ------------------------------------------------------------------------------ > >>> > This SF.net email is sponsored by Windows: > >>> > > >>> > Build for Windows Store. > >>> > > >>> > http://p.sf.net/sfu/windows-dev2dev > >>> > _______________________________________________ > >>> > Lives-devel mailing list > >>> > Liv...@li... > >>> > https://lists.sourceforge.net/lists/listinfo/lives-devel > >>> > > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Windows: > >>> > >>> Build for Windows Store. > >>> > >>> http://p.sf.net/sfu/windows-dev2dev > >>> _______________________________________________ > >>> Lives-devel mailing list > >>> Liv...@li... > >>> https://lists.sourceforge.net/lists/listinfo/lives-devel > >> > >> > >> > >> > >> -- > >> VJ pixel > >> > >> http://memelab.com.br > >> R. Vitorino Carmilo, 459 - Barra Funda > >> São Paulo - SP - Brasil > >> +55 11 3662 5702 > > > > > > > > > > -- > > VJ pixel > > > > http://memelab.com.br > > R. Vitorino Carmilo, 459 - Barra Funda > > São Paulo - SP - Brasil > > +55 11 3662 5702 > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Lives-devel mailing list > > Liv...@li... > > https://lists.sourceforge.net/lists/listinfo/lives-devel > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > -- VJ pixel http://memelab.com.br R. Vitorino Carmilo, 459 - Barra Funda São Paulo - SP - Brasil +55 11 3662 5702 |
|
From: salsaman <sal...@gm...> - 2013-07-04 20:13:52
|
Are you running it offline ? Sounds like autopoint is failing to download some required gettext files. On Thu, Jul 4, 2013 at 2:44 PM, VJ pixel <vj...@gm...> wrote: > I'm trying to compile LiVES. when I run ./autogen.sh I got: > > Preparing build ... configure.in:98: required file `./config.rpath' not > found > configure.in:830: required file `intl/Makefile.in' not found > configure.in:98: required file `./ABOUT-NLS' not found > Makefile.am:30: required directory ./intl does not exist > ERROR: automake failed > > > > > On Wed, Jul 3, 2013 at 9:49 AM, VJ pixel <vj...@gm...> wrote: >> >> I think that a way to show foreground clip is to show it over the other, >> like this: >> https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg >> >> maybe the better way to show parameters in the way that you proposed is to >> use a checkbox that but them in a horizontal scrooling list. >> >> I'm in FISL right now. I'll try to download the svn version, but maybe >> I'll only can do that next week. >> >> >> >> >> On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: >>> >>> On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: >>> > I think your mail did'n came to the list because of the attachment. >>> >>> OK, I will see if I can liberate it ! >>> >>> > >>> > in my opinion, the name and number of frames of the clip isn't >>> > necessary. >>> > >>> >>> Maybe not number of frames, but I think it is useful to show the clip >>> name at least. Maybe it could show as a tooltip if the mouse is >>> hovered over it. >>> >>> >>> > I know that the effects are applied in a specific order (ie. doesn't >>> > matter >>> > with order I activate effects, they will be always applied to the video >>> > in >>> > the same order). I think that the the order of the effects in the list >>> > should be the same they are applied. also, should be good to have the >>> > effects arranged in categories (generative, transition, etc). >>> >>> >>> >>> One possibility would be to allow the user to click on an effect and >>> drag it to another position in the list. Then the effects would always >>> be applied in order from top to bottom, but you could change the >>> order. I think that could be done without changing the existing >>> functionality too much. >>> >>> Again, a tooltip could be added so hovering the mouse over would show >>> the effect type (effect, transition, generator). >>> >>> >>> >>> >>> >>> >>> >>> >>> > >>> > would be good to have a indication of what clip is in the foreground, >>> > what's >>> > in the background. >>> > >>> >>> Yes I agree. But i couldnt think of any good way to show that >>> visually. The forground clip could be highlighted in some way, but >>> what should be done to indicate the background clip ? >>> >>> >>> >>> > I think that better than having a checkbox to choose the effects that >>> > will >>> > have their parameters shown, would be showing the parameters of the >>> > last >>> > effect clicked in the reserved area for parameters. >>> > >>> >>> Thats possible, but I was thinking maybe it would be good to show >>> parameters from more that one effect. Maybe you could somehow "pin" >>> the parameters so they stay there and the next effect just adds its >>> own parameters as well. But again, what is a good way to "pin" them ? >>> >>> >>> > also, would be good to have buttons for the some shortcuts (at least >>> > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, ctrl-backspace, >>> > n) >>> > >>> >>> Yes, that could be cool. I'm not so sure about ctrl-left and >>> ctrl-right because these are used for scratching, which is much better >>> done by the keyboard or MIDI/joystick than by clicking buttons. >>> >>> Did you download the svn version yet ? It would be good if you could >>> test things out. >>> >>> >>> Gabriel. >>> >>> >>> >>> > ++ >>> > >>> > Yes agreed, that would be nice. I'm attaching a screenshot of the >>> > current layout, which is in svn. I was thinking maybe the left hand >>> > side could show the effect keys arranged vertically in a scrolled >>> > window. Then each key would have a combo box for the effect modes. >>> > Each key would also have a checkbox for "show parameters". Activating >>> > the checkbox would add a box with the parameters at the bottom half of >>> > the screen, which would be reserved for parameters. >>> > >>> > Do you have any better suggestions ? >>> > >>> > >>> > Gabriel. >>> > >>> > >>> > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: >>> >> >>> >> I think that to have a list of effects assigned to keys, with options >>> >> to >>> >> enable/dislabe and change values of every paremeter would be very >>> >> good. >>> >> >>> >> >>> >> >>> >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> wrote: >>> >>> >>> >>> OK folks, >>> >>> so I have decided to implement a new feature in LiVES. >>> >>> >>> >>> When playing back in the clip editor in fullscreen, separate window >>> >>> mode, and the playback monitor and gui monitor are set to different >>> >>> values (i.e. dual head mode), LiVES will optionally show clip >>> >>> thumbnails in the gui window (in plcae of the normal gui window). By >>> >>> clicking on the thumbnails it will be possible to change clips (so it >>> >>> will be something like Resolume I think). >>> >>> >>> >>> Does anybody have any suggestions for how this should look ? Apart >>> >>> from thumbnails of clips, what other features would be useful in this >>> >>> mode ? Maybe effects on / off, effect parameters, fps....how about a >>> >>> button to select whether the next clip change affects forgeground or >>> >>> background clip ? Maybe more than two clips (foreground and >>> >>> background) could be selected...i.e some kind of video mapping. >>> >>> >>> >>> Regards, >>> >>> Gabriel. >>> >>> >>> >>> >>> >>> >>> >>> http://lives.sourceforge.net >>> >>> https://www.ohloh.net/accounts/salsaman >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> This SF.net email is sponsored by Windows: >>> >>> >>> >>> Build for Windows Store. >>> >>> >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> >>> _______________________________________________ >>> >>> Lives-devel mailing list >>> >>> Liv...@li... >>> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> VJ pixel >>> >> >>> >> http://memelab.com.br >>> >> R. Vitorino Carmilo, 459 - Barra Funda >>> >> São Paulo - SP - Brasil >>> >> +55 11 3662 5702 >>> > >>> > >>> > >>> > >>> > -- >>> > VJ pixel >>> > >>> > http://memelab.com.br >>> > R. Vitorino Carmilo, 459 - Barra Funda >>> > São Paulo - SP - Brasil >>> > +55 11 3662 5702 >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > This SF.net email is sponsored by Windows: >>> > >>> > Build for Windows Store. >>> > >>> > http://p.sf.net/sfu/windows-dev2dev >>> > _______________________________________________ >>> > Lives-devel mailing list >>> > Liv...@li... >>> > https://lists.sourceforge.net/lists/listinfo/lives-devel >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> _______________________________________________ >>> Lives-devel mailing list >>> Liv...@li... >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >> >> >> >> >> -- >> VJ pixel >> >> http://memelab.com.br >> R. Vitorino Carmilo, 459 - Barra Funda >> São Paulo - SP - Brasil >> +55 11 3662 5702 > > > > > -- > VJ pixel > > http://memelab.com.br > R. Vitorino Carmilo, 459 - Barra Funda > São Paulo - SP - Brasil > +55 11 3662 5702 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > |
|
From: VJ p. <vj...@gm...> - 2013-07-04 17:44:20
|
I'm trying to compile LiVES. when I run ./autogen.sh I got: Preparing build ... configure.in:98: required file `./config.rpath' not found configure.in:830: required file `intl/Makefile.in' not found configure.in:98: required file `./ABOUT-NLS' not found Makefile.am:30: required directory ./intl does not exist ERROR: automake failed On Wed, Jul 3, 2013 at 9:49 AM, VJ pixel <vj...@gm...> wrote: > I think that a way to show foreground clip is to show it over the other, > like this: > https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg > > maybe the better way to show parameters in the way that you proposed is to > use a checkbox that but them in a horizontal scrooling list. > > I'm in FISL right now. I'll try to download the svn version, but maybe > I'll only can do that next week. > > > > > On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: > >> On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: >> > I think your mail did'n came to the list because of the attachment. >> >> OK, I will see if I can liberate it ! >> >> > >> > in my opinion, the name and number of frames of the clip isn't >> necessary. >> > >> >> Maybe not number of frames, but I think it is useful to show the clip >> name at least. Maybe it could show as a tooltip if the mouse is >> hovered over it. >> >> >> > I know that the effects are applied in a specific order (ie. doesn't >> matter >> > with order I activate effects, they will be always applied to the video >> in >> > the same order). I think that the the order of the effects in the list >> > should be the same they are applied. also, should be good to have the >> > effects arranged in categories (generative, transition, etc). >> >> >> >> One possibility would be to allow the user to click on an effect and >> drag it to another position in the list. Then the effects would always >> be applied in order from top to bottom, but you could change the >> order. I think that could be done without changing the existing >> functionality too much. >> >> Again, a tooltip could be added so hovering the mouse over would show >> the effect type (effect, transition, generator). >> >> >> >> >> >> >> >> >> > >> > would be good to have a indication of what clip is in the foreground, >> what's >> > in the background. >> > >> >> Yes I agree. But i couldnt think of any good way to show that >> visually. The forground clip could be highlighted in some way, but >> what should be done to indicate the background clip ? >> >> >> >> > I think that better than having a checkbox to choose the effects that >> will >> > have their parameters shown, would be showing the parameters of the last >> > effect clicked in the reserved area for parameters. >> > >> >> Thats possible, but I was thinking maybe it would be good to show >> parameters from more that one effect. Maybe you could somehow "pin" >> the parameters so they stay there and the next effect just adds its >> own parameters as well. But again, what is a good way to "pin" them ? >> >> >> > also, would be good to have buttons for the some shortcuts (at least >> > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, ctrl-backspace, >> n) >> > >> >> Yes, that could be cool. I'm not so sure about ctrl-left and >> ctrl-right because these are used for scratching, which is much better >> done by the keyboard or MIDI/joystick than by clicking buttons. >> >> Did you download the svn version yet ? It would be good if you could >> test things out. >> >> >> Gabriel. >> >> >> >> > ++ >> > >> > Yes agreed, that would be nice. I'm attaching a screenshot of the >> > current layout, which is in svn. I was thinking maybe the left hand >> > side could show the effect keys arranged vertically in a scrolled >> > window. Then each key would have a combo box for the effect modes. >> > Each key would also have a checkbox for "show parameters". Activating >> > the checkbox would add a box with the parameters at the bottom half of >> > the screen, which would be reserved for parameters. >> > >> > Do you have any better suggestions ? >> > >> > >> > Gabriel. >> > >> > >> > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: >> >> >> >> I think that to have a list of effects assigned to keys, with options >> to >> >> enable/dislabe and change values of every paremeter would be very good. >> >> >> >> >> >> >> >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> wrote: >> >>> >> >>> OK folks, >> >>> so I have decided to implement a new feature in LiVES. >> >>> >> >>> When playing back in the clip editor in fullscreen, separate window >> >>> mode, and the playback monitor and gui monitor are set to different >> >>> values (i.e. dual head mode), LiVES will optionally show clip >> >>> thumbnails in the gui window (in plcae of the normal gui window). By >> >>> clicking on the thumbnails it will be possible to change clips (so it >> >>> will be something like Resolume I think). >> >>> >> >>> Does anybody have any suggestions for how this should look ? Apart >> >>> from thumbnails of clips, what other features would be useful in this >> >>> mode ? Maybe effects on / off, effect parameters, fps....how about a >> >>> button to select whether the next clip change affects forgeground or >> >>> background clip ? Maybe more than two clips (foreground and >> >>> background) could be selected...i.e some kind of video mapping. >> >>> >> >>> Regards, >> >>> Gabriel. >> >>> >> >>> >> >>> >> >>> http://lives.sourceforge.net >> >>> https://www.ohloh.net/accounts/salsaman >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF.net email is sponsored by Windows: >> >>> >> >>> Build for Windows Store. >> >>> >> >>> http://p.sf.net/sfu/windows-dev2dev >> >>> _______________________________________________ >> >>> Lives-devel mailing list >> >>> Liv...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/lives-devel >> >> >> >> >> >> >> >> >> >> -- >> >> VJ pixel >> >> >> >> http://memelab.com.br >> >> R. Vitorino Carmilo, 459 - Barra Funda >> >> São Paulo - SP - Brasil >> >> +55 11 3662 5702 >> > >> > >> > >> > >> > -- >> > VJ pixel >> > >> > http://memelab.com.br >> > R. Vitorino Carmilo, 459 - Barra Funda >> > São Paulo - SP - Brasil >> > +55 11 3662 5702 >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net email is sponsored by Windows: >> > >> > Build for Windows Store. >> > >> > http://p.sf.net/sfu/windows-dev2dev >> > _______________________________________________ >> > Lives-devel mailing list >> > Liv...@li... >> > https://lists.sourceforge.net/lists/listinfo/lives-devel >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> _______________________________________________ >> Lives-devel mailing list >> Liv...@li... >> https://lists.sourceforge.net/lists/listinfo/lives-devel >> > > > > -- > VJ pixel > > http://memelab.com.br > R. Vitorino Carmilo, 459 - Barra Funda > São Paulo - SP - Brasil > +55 11 3662 5702 > -- VJ pixel http://memelab.com.br R. Vitorino Carmilo, 459 - Barra Funda São Paulo - SP - Brasil +55 11 3662 5702 |
|
From: VJ p. <vj...@gm...> - 2013-07-03 12:49:29
|
I think that a way to show foreground clip is to show it over the other, like this: https://si0.twimg.com/profile_images/504871923/2-Squares-Solutions-twitter.jpg maybe the better way to show parameters in the way that you proposed is to use a checkbox that but them in a horizontal scrooling list. I'm in FISL right now. I'll try to download the svn version, but maybe I'll only can do that next week. On Tue, Jul 2, 2013 at 9:07 PM, salsaman <sal...@gm...> wrote: > On Tue, Jul 2, 2013 at 11:04 AM, VJ pixel <vj...@gm...> wrote: > > I think your mail did'n came to the list because of the attachment. > > OK, I will see if I can liberate it ! > > > > > in my opinion, the name and number of frames of the clip isn't necessary. > > > > Maybe not number of frames, but I think it is useful to show the clip > name at least. Maybe it could show as a tooltip if the mouse is > hovered over it. > > > > I know that the effects are applied in a specific order (ie. doesn't > matter > > with order I activate effects, they will be always applied to the video > in > > the same order). I think that the the order of the effects in the list > > should be the same they are applied. also, should be good to have the > > effects arranged in categories (generative, transition, etc). > > > > One possibility would be to allow the user to click on an effect and > drag it to another position in the list. Then the effects would always > be applied in order from top to bottom, but you could change the > order. I think that could be done without changing the existing > functionality too much. > > Again, a tooltip could be added so hovering the mouse over would show > the effect type (effect, transition, generator). > > > > > > > > > > > > would be good to have a indication of what clip is in the foreground, > what's > > in the background. > > > > Yes I agree. But i couldnt think of any good way to show that > visually. The forground clip could be highlighted in some way, but > what should be done to indicate the background clip ? > > > > > I think that better than having a checkbox to choose the effects that > will > > have their parameters shown, would be showing the parameters of the last > > effect clicked in the reserved area for parameters. > > > > Thats possible, but I was thinking maybe it would be good to show > parameters from more that one effect. Maybe you could somehow "pin" > the parameters so they stay there and the next effect just adds its > own parameters as well. But again, what is a good way to "pin" them ? > > > > also, would be good to have buttons for the some shortcuts (at least > > ctrl-left, ctrl-right, ctrl-up, ctrl-down, ctrl-space, ctrl-backspace, n) > > > > Yes, that could be cool. I'm not so sure about ctrl-left and > ctrl-right because these are used for scratching, which is much better > done by the keyboard or MIDI/joystick than by clicking buttons. > > Did you download the svn version yet ? It would be good if you could > test things out. > > > Gabriel. > > > > > ++ > > > > Yes agreed, that would be nice. I'm attaching a screenshot of the > > current layout, which is in svn. I was thinking maybe the left hand > > side could show the effect keys arranged vertically in a scrolled > > window. Then each key would have a combo box for the effect modes. > > Each key would also have a checkbox for "show parameters". Activating > > the checkbox would add a box with the parameters at the bottom half of > > the screen, which would be reserved for parameters. > > > > Do you have any better suggestions ? > > > > > > Gabriel. > > > > > > On Mon, Jul 1, 2013 at 6:22 PM, VJ pixel <vj...@gm...> wrote: > >> > >> I think that to have a list of effects assigned to keys, with options to > >> enable/dislabe and change values of every paremeter would be very good. > >> > >> > >> > >> On Sat, Jun 29, 2013 at 12:12 AM, salsaman <sal...@gm...> wrote: > >>> > >>> OK folks, > >>> so I have decided to implement a new feature in LiVES. > >>> > >>> When playing back in the clip editor in fullscreen, separate window > >>> mode, and the playback monitor and gui monitor are set to different > >>> values (i.e. dual head mode), LiVES will optionally show clip > >>> thumbnails in the gui window (in plcae of the normal gui window). By > >>> clicking on the thumbnails it will be possible to change clips (so it > >>> will be something like Resolume I think). > >>> > >>> Does anybody have any suggestions for how this should look ? Apart > >>> from thumbnails of clips, what other features would be useful in this > >>> mode ? Maybe effects on / off, effect parameters, fps....how about a > >>> button to select whether the next clip change affects forgeground or > >>> background clip ? Maybe more than two clips (foreground and > >>> background) could be selected...i.e some kind of video mapping. > >>> > >>> Regards, > >>> Gabriel. > >>> > >>> > >>> > >>> http://lives.sourceforge.net > >>> https://www.ohloh.net/accounts/salsaman > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> This SF.net email is sponsored by Windows: > >>> > >>> Build for Windows Store. > >>> > >>> http://p.sf.net/sfu/windows-dev2dev > >>> _______________________________________________ > >>> Lives-devel mailing list > >>> Liv...@li... > >>> https://lists.sourceforge.net/lists/listinfo/lives-devel > >> > >> > >> > >> > >> -- > >> VJ pixel > >> > >> http://memelab.com.br > >> R. Vitorino Carmilo, 459 - Barra Funda > >> São Paulo - SP - Brasil > >> +55 11 3662 5702 > > > > > > > > > > -- > > VJ pixel > > > > http://memelab.com.br > > R. Vitorino Carmilo, 459 - Barra Funda > > São Paulo - SP - Brasil > > +55 11 3662 5702 > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Lives-devel mailing list > > Liv...@li... > > https://lists.sourceforge.net/lists/listinfo/lives-devel > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Lives-devel mailing list > Liv...@li... > https://lists.sourceforge.net/lists/listinfo/lives-devel > -- VJ pixel http://memelab.com.br R. Vitorino Carmilo, 459 - Barra Funda São Paulo - SP - Brasil +55 11 3662 5702 |
4 messages has been excluded from this view by a project administrator.