Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

Sorry,  my bad: I forgot to update the constants in the .h files. I was
looking in the .c files by mistake.

Also, I think it should be AV_CODEC_ID_* in the headers (although
AV_CODEC_* seemed to work too).
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

Please check that you are compiling with the current versions of those
files. There are no instances of CODEC_* any more in those files.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

I believe all the issues noted should be fixed now. You will need to
replace the follwoing files:
configure.ac
libweed/weed-compat.h
libweed/weed-compat.pc
plugins/decoders/*

(the weed-compat changes are unrelated, but you will need to update them to
compile the current decoder plugins).
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#888348: lives: FTBFS with FFmpeg 3.5

[salsaman]

If you have a moment, perhaps you could pull the newly updated files from
lives/lives-plugins/plugins/decoders in subversion (
http://svn.code.sf.net/p/lives/code/trunk) and recompile. It should fix the
FTBFS.

Gabriel.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#853520: lives: ftbfs with GCC-7

[salsaman]

OK, all errors / warnings fixed I believe (with exception of the gtk+
warning). Will update after checking in to svn.

Regarding the gtk+ warning - the code calls a wrapper function which in
turn calls gtk_widget_set_valign() / gtk_widget_set_halign() which
presumably contain deprecated calls to  gtk_alignment_get_type(). As noted
this appears to be a gtk+ issue.






On Tue, Jan 31, 2017 at 11:33 AM, salsaman <salsaman+li...@gmail.com> wrote:

> Ah OK, got it - inlines now need to be explicitly static or declared in
> the header.
>
>
>
>
> On Tue, Jan 31, 2017 at 8:32 AM, Matthias Klose <d...@debian.org> wrote:
>
>> On 31.01.2017 12:04, salsaman wrote:
>> > The gcc error makes no sense as the function get_time_from_x() is
>> defined
>> > (inline) earlier in multitrack.c at line 971.
>> > You should report this as a bug in gcc.
>>
>> no. define it as static inline like the other zillions of inline
>> functions.
>>
>>
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#853520: lives: ftbfs with GCC-7

[salsaman]

Ah OK, got it - inlines now need to be explicitly static or declared in the
header.



On Tue, Jan 31, 2017 at 8:32 AM, Matthias Klose <d...@debian.org> wrote:

> On 31.01.2017 12:04, salsaman wrote:
> > The gcc error makes no sense as the function get_time_from_x() is defined
> > (inline) earlier in multitrack.c at line 971.
> > You should report this as a bug in gcc.
>
> no. define it as static inline like the other zillions of inline functions.
>
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#853520: lives: ftbfs with GCC-7

[salsaman]

The gcc error makes no sense as the function get_time_from_x() is defined
(inline) earlier in multitrack.c at line 971.
You should report this as a bug in gcc.

The warning regarding  gtk_alignment_get_type() is internal to gtk+. You
should open a bug report there
.
The other warnings are vaid for LiVES but are trivial to fix.

Gabriel.


On Tue, Jan 31, 2017 at 6:33 AM, Matthias Klose  wrote:

> Package: src:lives
> Version: 2.8.3-1
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
>
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
>
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/lives_
> 2.8.3-1_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
>   apt-get -t=experimental install g++
>
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-7/porting_to.html
>
> [...]
> callbacks.c:5975:15: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>  if (height*width) {
>  ~~^~
> callbacks.c:6006:15: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>if (!(height*width)&_type!=LIVES_PREVIEW_TYPE_IMAGE_ONLY) {
> ~~~^~~
> callbacks.c:6123:7: warning: 'gtk_alignment_get_type' is deprecated
> [-Wdeprecated-declarations]
>lives_alignment_set(LIVES_ALIGNMENT(mainw->fs_playalign),0.5,
>^~~
> In file included from /usr/include/gtk-3.0/gtk/gtk.h:251:0,
>  from main.h:74,
>  from callbacks.c:21:
> /usr/include/gtk-3.0/gtk/deprecated/gtkalignment.h:77:12: note: declared
> here
>  GType  gtk_alignment_get_type   (void) G_GNUC_CONST;
> ^~
> callbacks.c: In function 'on_full_screen_activate':
> callbacks.c:6716:33: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>  if (!(mainw->vpp->fwidth*mainw->vpp->fheight)) {
>   ~~~^
> callbacks.c: In function 'on_double_size_activate':
> callbacks.c:6903:29: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>  } while (!(mainw->pwidth*mainw->pheight));
>~~^~~~
> callbacks.c: In function 'on_sepwin_activate':
> callbacks.c:7088:35: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>if (!(mainw->vpp->fwidth*mainw->vpp->fheight)) {
> ~~~^
> main.c: In function 'switch_to_file':
> main.c:7105:19: warning: '*' in boolean context, suggest '&&' instead
> [-Wint-in-bool-context]
>if (old_file*new_file) mainw->preview_frame=0;
>^
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -Wstrict-aliasing=0 -Wall
> -DHAVE_YUV4MPEG=1 -DHAVE_LDVGRAB=1 -I libavc1394/avc1394.h -I
> libraw1394/raw1394.h -I libraw1394/rom1394.h -DIS_LINUX_GNU=1
> -DENABLE_OSC=1  -I/usr/include/alsa -DALSA_MIDI=1 -I/usr/include/libpng16
> -DUSE_LIBPNG=1 -I/usr/include/x86_64-linux-gnu
> -I/usr/include/x86_64-linux-gnu -DUSE_SWSCALE=1 -DENABLE_JACK
> -DENABLE_JACK_TRANSPORT -lpulse -DHAVE_PULSE_AUDIO=1 -DENABLE_GIW=1
> -DHAVE_UNICAP=1   -DLIVES_LIBDIR=\""/usr/lib/x86_64-linux-gnu"\"
> -DHAVE_WEBM=1  -g -O2 -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -Wall -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0
> -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0
> -lglib-2.0 -pthread -shared  -Wl,-z,relro -o lives-exe widget-helper.o
> main.o support.o effects.o plugins.o effects-weed.o effects-data.o
> framedraw.o interface.o paramspecial.o paramwindow.o rfx-builder.o
> lives-yuv4mpeg.o preferences.o rte_window.o gui.o ce_thumbs.o htmsocket.o
> merge.o dialogs.o saveplay.o audio.o events.o resample.o osc.o omc-learn.o
> callbacks.o colourspace.o keyboard.o utils.o multitrack.o stream.o
> cvirtual.o startup.o pangotext.o videodev.o jack.o pulse.o ldvgrab.o
> ldvcallbacks.o ldvinterface.o 

Bug#798043:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#810146:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756565:

[salsaman]

This bug can be closed with the release of LiVES 2.8.1
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#810146: lives: encoding fails because empty audio wav file beyond some specific length

[salsaman]

Thankyou for your detailed investigation Lionel. This issue has now been
addressed in version 2.8.1 of LiVES which should be in the debian
repositiries shortly.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#798043:

[salsaman]

3 more patches - implementing the permissions change as discussed and also
ensuring that umask is employed correctly throughout.

I think these will be the final patches for this issue, assuming there are
no bugs found during testing.

https://sourceforge.net/p/lives/code/2587/
https://sourceforge.net/p/lives/code/2588/
https://sourceforge.net/p/lives/code/2590/
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#798043: lives: creates (and uses) world-writeable directory

[salsaman]

James, I was wondering what action should be taken regarding
directory/subdirectory permissions for existing users. The options I can
think of (from simplest to most complex): a) do nothing, only new users get
the benefit. b) add a note in Release Notes informing users how to update
the directory permissions manually, or c) Show a one time pop-up when LiVES
is upgraded asking the user if they want the program to update permissions
for the working directory for them, and if they click Yes, do the update
for them.

Which of the options do you recommend ?
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#798043:

[salsaman]

Relevant patches:

https://sourceforge.net/p/lives/code/2574/
https://sourceforge.net/p/lives/code/2576/
https://sourceforge.net/p/lives/code/2578/
https://sourceforge.net/p/lives/code/2579/
https://sourceforge.net/p/lives/code/2580/
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756565: lives: Numerous insecure temporary files used in smogrify

[salsaman]

All issues noted above have been fixed. In addition:

- the terminology has been changed throughout to try to be less confusing.
The directory is now referred to as the "LiVES working directory"
everywhere.
For example prefs->tmpdir is now prefs->workdir in the C code, and $tmpdir
is now $workdir in Perl. The only exception is in the .lives config file
where the text  and  must be retained for backwards
compatilbility.

- there were a couple of playback plugins where /tmp was the default for
creating a fifo file inside. Even though the user could overwrite this, the
default has now been changed to create these files in the LiVES working
directory.

- the command "smogrify get_tempdir" has been left alone for backwards
compatibility but is marked as deprecated in the source file. A new
directive "smogrify get_workdir" has been created, this latter version
writes to stdout and other applications may read this with popen().

- a couple of places where LiVES was creating temporary files in /tmp have
been altered to create these in the working directory instead.

I believe that all issues have been addressed. I will continue testing and
examining the code over the next few days to confirm this.


Relevant patches:
https://sourceforge.net/p/lives/code/2570
https://sourceforge.net/p/lives/code/2571
https://sourceforge.net/p/lives/code/2572
https://sourceforge.net/p/lives/code/2573
https://sourceforge.net/p/lives/code/2577
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#798043:

[salsaman]

This has now been fixed. The problem was that the backend (smogrify) needs
to communicate some information to the front end (LiVES) at startup, and to
do so it was creating ~/livestmp (the default working directory on first
time startup) to write some temporary files in.

The default is now set to be $HOME, and this directory is not created by
the software (it is presumed to exist already.)

The second part of the problem has been resolved. The default permissions
are now used when creating the working directory and any subdrectories of
this.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756565: lives: Numerous insecure temporary files used in smogrify

[salsaman]

On Thu, Sep 22, 2016 at 7:56 PM, James Cowgill  wrote:


>
> Thinking about this some more, there is a slight race condition here if
> the user deletes the file after the checks, but before it's written. I
> think the best fix would break the smogrify API unfortunately. One
> alternative is to use to use open(2)'s O_CREATE | O_EXCL flags, but this
> will only work if the file does not exist beforehand.
>


Actually I just had a much simpler idea. Since we are only interested in
getting the value, I can alter this function so that the value is written
to stdout instead of to /tmp.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756565: lives: Numerous insecure temporary files used in smogrify

[salsaman]

On Tue, Sep 20, 2016 at 1:03 PM, James Cowgill <jcowg...@debian.org> wrote:

> Hi,
>
> [please don't change the subject to 'bug update' - it makes it harder to
> follow threads and is totally pointless]
>
>
I wasnt aware I was changing the subject - it seems like one can only add
comments to this bug by sending email and of course I would need to add a
topic to the email. Hopefully just replying will leave it alone then




> On 20/09/16 15:51, salsaman wrote:
> > I would prefer to keep $tmpdir as it is, I dont see any reason to change
> > it to $XDG_CACHE_HOME as this variable is only used internally to
> > smogrify. Also using /lives would be confusing as there is already a
> > .lives file and lives-dir which are both created in $HOME. Also the user
> > can select the location of $tmpdir at install time so it may be outside
> > $HOME.
>
> I was referring to moving the ~/livestmp directory, not the $tmpdir
> variable which is just an implementation detail. Incidentally since this
> directory is world writable, it's probably vulnerable to the same
> security bugs that /tmp is. Maybe what I said before is wrong and all
> files in $tmpdir are also vulnerable?
>
>

As I mentioned already, the location of this directory is selected by the
user the first time that LiVES is run.
There is nothing forcing it to be ~/livestmp.

The directory being world writeable is a separate bug which will be
addressed there.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798043



> > Regarding the other files:
> >
> > /tmp/lives-symlinks is only used in the Dynebolic bootable disk.
> > Effectively this can be ignored, since it is not used in normal
> operation.
>
> Why does the code still exist then? Can you confirm that it can never
> ever be executed?
>
>



> I have not investigated much, but if it can be executed then it could
> quite easily be used to allow editing of any file in a user's home
> directory.
>
> Attacker: ln -s $HOME_OTHER /tmp/lives-symlinks/$ALL_HANDLES
>
> $linksdir = "/tmp/lives-symlinks/$handle/";
> [some lines]
> $com="/bin/mkdir -p \"$linksdir\"";
> [above command exits without error]
> smog_system("/bin/chmod -R 777 \"$linksdir\"");
>
> [boom]
>
> In this particular case the kernel default security settings will
> probably stop you doing this, but that doesn't mean you can ignore the
> issue. As the kernel reports an error when doing this, smogrify will
> probably fail as well.
>
>

I rechecked and you may be correct in this case. I started reworking this
code now. /tmp will no longer used, instead all the symlinks will be
created in the individual clip directories. In addition, the directory was
set with chmod 777, now it will be created with mode 700.




> > /tmp/.smogrify.* is intended to be used when an external script calls
> > "smogrify get_tempdir ". This may be employed by external scripts
> > to get the working directory location for LiVES. The token  is
> > appended to the end of the filename so this can be considered secure.
> > The LiVES application itself never calls this.
>
> Even using a random  doesn't make it secure. You have to ensure any
> files in /tmp exist and are owned by the user running lives, before
> attempting to read or write to them. Otherwise an attacker could put a
> symlink there and cause the lives user to write to an arbitrary location.
>
>

OK. I will do as you recommend.



> For example, simply grepping the lives source reveals:
> lives-plugins/plugins/playback/video/oggstream.c:
> dummyvar=system("smogrify get_tempdir oggstream");
>
> This allows any user to truncate any file owned by the lives user by
> simply creating a symlink, and waiting for smogrify to be run.
>  ln -s $IMPORTANT_FILE /tmp/.smogrify.oggstream
>
>
Thanks for pointing that out.
The only other place where I know /tmp is used is in
lives-plugins/marcos-encoders. For example in lives_mkv_encoder we have:
temp_dir = tempfile.mkdtemp('', '.lives-', '/tmp/')

However the description of (Python) mkdtemp suggests that this should be
safe:
https://docs.python.org/2/library/tempfile.html

"Creates a temporary directory in the most secure manner possible. There
are no race conditions in the directory’s creation. The directory is
readable, writable, and searchable only by the creating user ID."



>
> > Actually I have a TODO there: allow a (optional) second parameter to
> > override the default directory location (/tmp); so I shall implement
> > this so that scripts can provide an alternative to /tmp if they wish.
> >
> >
> > /tmp/.smogval : this is not used, I believe you are again confused by
> > $tmpdir w

Bug#756565: bug update

[salsaman]

I would prefer to keep $tmpdir as it is, I dont see any reason to change it
to $XDG_CACHE_HOME as this variable is only used internally to smogrify.
Also using /lives would be confusing as there is already a .lives file and
lives-dir which are both created in $HOME. Also the user can select the
location of $tmpdir at install time so it may be outside $HOME.



Regarding the other files:

/tmp/lives-symlinks is only used in the Dynebolic bootable disk.
Effectively this can be ignored, since it is not used in normal operation.


/tmp/.smogrify.* is intended to be used when an external script calls
"smogrify get_tempdir ". This may be employed by external scripts to
get the working directory location for LiVES. The token  is appended
to the end of the filename so this can be considered secure. The LiVES
application itself never calls this.

Actually I have a TODO there: allow a (optional) second parameter to
override the default directory location (/tmp); so I shall implement this
so that scripts can provide an alternative to /tmp if they wish.


/tmp/.smogval : this is not used, I believe you are again confused by
$tmpdir which as noted points to the working directory (e.g. ~/livestmp).
There IS a minor bug where "/tmp/.smogval*" is removed by a cleanup
operation. This code should be removed as it is no longer relevant.


The above changes are trivial and I will update here as soon as they are
done.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#803839:

[salsaman]

I believe it may be possible to use FF_API_PIX_FMT to determine the older
version complatibility. Somebody please confirm this if possible.

Attached is a (I think correct) patch for the current svn version of LiVES.
With some minor adjustment it should be possible to apply it to older
versions of LiVES.
Index: libweed/weed-compat.h
===
--- libweed/weed-compat.h   (revision 2352)
+++ libweed/weed-compat.h   (working copy)
@@ -42,7 +42,7 @@
 
 */
 
-/* (C) Gabriel "Salsaman" Finch, 2005 - 2012 */
+/* (C) Gabriel "Salsaman" Finch, 2005 - 2016 */
 
 #ifndef __WEED_COMPAT_H__
 #define __WEED_COMPAT_H__
@@ -595,6 +595,8 @@
 #include 
 #endif
 
+#ifdef FF_API_PIX_FMT
+
 int avi_pix_fmt_to_weed_palette(enum PixelFormat pix_fmt, int *clamped) {
   // clamped may be set to NULL if you are not interested in the value
 
@@ -635,7 +637,7 @@
   case PIX_FMT_YUVJ420P:
 if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
 return WEED_PALETTE_YUV420P;
-
+
   default:
 return WEED_PALETTE_END;
   }
@@ -642,10 +644,7 @@
 }
 
 
-
-
 enum PixelFormat weed_palette_to_avi_pix_fmt(int pal, int *clamped) {
-
   switch (pal) {
   case WEED_PALETTE_RGB24:
   return PIX_FMT_RGB24;
@@ -684,11 +683,100 @@
   default:
 return PIX_FMT_NONE;
   }
+}
 
-  return PIX_FMT_NONE;
+#else
 
+int avi_pix_fmt_to_weed_palette(enum AVPixelFormat pix_fmt, int *clamped) {
+  // clamped may be set to NULL if you are not interested in the value
+
+  switch (pix_fmt) {
+  case AV_PIX_FMT_RGB24:
+return WEED_PALETTE_RGB24;
+  case AV_PIX_FMT_BGR24:
+return WEED_PALETTE_BGR24;
+  case AV_PIX_FMT_RGBA:
+return WEED_PALETTE_RGBA32;
+  case AV_PIX_FMT_BGRA:
+return WEED_PALETTE_BGRA32;
+  case AV_PIX_FMT_ARGB:
+return WEED_PALETTE_ARGB32;
+  case AV_PIX_FMT_YUV444P:
+return WEED_PALETTE_YUV444P;
+  case AV_PIX_FMT_YUV422P:
+return WEED_PALETTE_YUV422P;
+  case AV_PIX_FMT_YUV420P:
+return WEED_PALETTE_YUV420P;
+  case AV_PIX_FMT_YUYV422:
+return WEED_PALETTE_YUYV;
+  case AV_PIX_FMT_UYVY422:
+return WEED_PALETTE_UYVY;
+  case AV_PIX_FMT_UYYVYY411:
+return WEED_PALETTE_YUV411;
+  case AV_PIX_FMT_GRAY8:
+return WEED_PALETTE_A8;
+  case AV_PIX_FMT_MONOWHITE:
+  case AV_PIX_FMT_MONOBLACK:
+return WEED_PALETTE_A1;
+  case AV_PIX_FMT_YUVJ422P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV422P;
+  case AV_PIX_FMT_YUVJ444P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV444P;
+  case AV_PIX_FMT_YUVJ420P:
+if (clamped) *clamped=WEED_YUV_CLAMPING_UNCLAMPED;
+return WEED_PALETTE_YUV420P;
+
+  default:
+return WEED_PALETTE_END;
+  }
 }
 
+
+enum AVPixelFormat weed_palette_to_avi_pix_fmt(int pal, int *clamped) {
+  switch (pal) {
+  case WEED_PALETTE_RGB24:
+  return AV_PIX_FMT_RGB24;
+  case WEED_PALETTE_BGR24:
+return AV_PIX_FMT_BGR24;
+  case WEED_PALETTE_RGBA32:
+return AV_PIX_FMT_RGBA;
+  case WEED_PALETTE_BGRA32:
+return AV_PIX_FMT_BGRA;
+  case WEED_PALETTE_ARGB32:
+return AV_PIX_FMT_ARGB;
+  case WEED_PALETTE_YUV444P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ444P;
+return AV_PIX_FMT_YUV444P;
+  case WEED_PALETTE_YUV422P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ422P;
+return AV_PIX_FMT_YUV422P;
+  case WEED_PALETTE_YUV420P:
+if (clamped && *clamped==WEED_YUV_CLAMPING_UNCLAMPED)
+  return AV_PIX_FMT_YUVJ420P;
+return AV_PIX_FMT_YUV420P;
+  case WEED_PALETTE_YUYV:
+return AV_PIX_FMT_YUYV422;
+  case WEED_PALETTE_UYVY:
+return AV_PIX_FMT_UYVY422;
+  case WEED_PALETTE_YUV411:
+return AV_PIX_FMT_UYYVYY411;
+
+  case WEED_PALETTE_A8:
+return AV_PIX_FMT_GRAY8;
+  case WEED_PALETTE_A1:
+return AV_PIX_FMT_MONOBLACK;
+
+  default:
+return AV_PIX_FMT_NONE;
+  }
+}
+  
+#endif
+  
 #endif // HAVE_AVUTIL
 #endif // HAVE_AVCODEC
 
Index: lives-plugins/plugins/decoders/mkv_decoder.c
===
--- lives-plugins/plugins/decoders/mkv_decoder.c(revision 2406)
+++ lives-plugins/plugins/decoders/mkv_decoder.c(working copy)
@@ -1,5 +1,5 @@
 // LiVES - mkv decoder plugin
-// (c) G. Finch 2011 <salsa...@xs4all.nl,salsa...@gmail.com>
+// (c) G. Finch 2011 - 2016 <salsa...@gmail.com>
 
 /*
  * This file is free software; you can redistribute it and/or
@@ -40,7 +40,7 @@
 #include 
 #include 
 
-const char *plugin_version="LiVES mkv decoder version 1.2";
+const char *plugin_version="LiVES mkv decoder version 1.3";
 
 #ifdef HAVE_AV_CONFIG_H
 #undef HAVE_AV_CONFIG_H
@@ -901,7 +901,7 @@
   out->data = newdata;
   memcpy(out->data+out->size, in->data, in->size);
   out->size += in->size;
-  av_destruct_packet(in);
+  av_packet_

Bug#803839: compile time check

[salsaman]

1) The patch as it stands is completely invalid. Each change needs to have
a version / feature check for backwards compatibility.
2) The change in mkv_decoder.c is not done like that. The correct way is to
#define either av_free_packet or av_destruct_packet in libavhelper.h
. Again a #ifdef is needed to identify this change.






On Tue, Mar 8, 2016 at 11:15 AM, salsaman <salsa...@gmail.com> wrote:

> Is there a compile time check for this version (e.g.
> LIBAVCODEC_VERSION_MAJOR) or even #ifdef AV_PIX_FMT_RGB24 ?
>
>
>
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#803839: compile time check

[salsaman]

Is there a compile time check for this version (e.g.
LIBAVCODEC_VERSION_MAJOR) or even #ifdef AV_PIX_FMT_RGB24 ?
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#762770: lives cannot find any encoders on startup

[salsaman]

If you use a library path other than /usr/lib, (or to be more precise,
$PREFIX/lib) for the plugins you need to do two things:

1) ./configure --libdir=path_to_lib
e.g. ./configure --libdir=/usr/lib/libx86_64-linux-gnu/



Assuming the libweed libs are also in the same directory:

2) Adjust the library paths in libweed/*.pc


A warning about the second change is printed at configure time, the first
is not documented, but it quite likely should be.


Please test and let me know if this fixes the problem for you.





http://lives.sourceforge.net
https://www.openhub.net/accounts/salsaman

On Thu, Oct 23, 2014 at 11:08 AM, Alessio Treglia ales...@debian.org
wrote:

 On Thu, Sep 25, 2014 at 11:20 AM, Wookey woo...@wookware.org wrote:
  Changing the lib_dir in the ~/.lives file from
  /usr/lib/
  to
  /usr/lib/x86_64-linux-gnu/  (on this machine)
  solves the issue:

 So, essentially you're saying that the very first time you launch
 lives, it creates the config file and then stores file a wrong plugins
 path into it.
 I can't reproduce it now but it sounds likely to me.

 I'm CC'ing the upstream maintainer to get his opinion on this.

 Cheers!

 --
 Alessio Treglia  | www.alessiotreglia.com
 Debian Developer | ales...@debian.org
 Ubuntu Core Developer|  quadris...@ubuntu.com
 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#720805: Not a good fix

[salsaman]

I don't think this fix can be correct. On my system (Fedora 17), both
AV_OPT_TYPE_INT and FF_OPT_TYPE_INT are defined as distinct values of the
enum AVOptionType in libavutil/opt.h. Thus adding this #define before
including opt.h causes an error: redeclaration of enumerator
'FF_OPT_TYPE_INT'

The purpose of the #defines in LiVES is to define AV_OPT_TYPE_INT on older
versions of libavutil which did not have AV_OPT_TYPE_INT.

It seems the problem in Sid is due to Debian's use of libavutils from libav
rather than from ffmpeg.

I believe the correct fix may be the following (which I hope will work in
all cases):

- #ifndef AV_OPT_TYPE_INT
+ #if FF_API_OLD_AVOPTIONS

leaving the lines in the same place as the original.




Regards
Salsaman.

http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#664523: Version of lives to be tested

[salsaman]

I am no the packager, I am the upstream developer. Better to ask
Alessio, Current .debs do not have the patch.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#664523: Bugfix patch

[salsaman]

Yes, as I stated earlier in the comments, you will need the patch
which I indicated.

Salsaman.

main developer, LiVES
http://lives.sourceforge.net



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#664523: Bugfix patch

[salsaman]

Can we try to get 1.6.2 with this patch into testing ? I understand
there was a freeze very recently for the next stable release.

1.6.2 with this patch would be much better than the existing 1.6.1 version.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#664523: Bugfix patch

[salsaman]

http://lives.svn.sourceforge.net/viewvc/lives/trunk/src/startup.c?r1=1446r2=1509



Regards,
Salsaman.

http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

LiVES error

[salsaman]

http://qa.debian.org/debcheck.php?dist=unstablepackage=lives

Package is optional and has a Depends on libavc1394-0

Incorrect. LiVES *recommends* libavc1394, but will function just fine
without it.


Please correct this when possible.


Regards,
Salsaman.



http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: LiVES 1.3.3 failing to build

[salsaman]

On Tue, May 11, 2010 17:27, Harry Rickards wrote:
 On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote:
 Hi,

 From https://buildd.debian.org/status/package.php?p=lives I can see
 that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on
 alpha, hurd-i386, i386, ia64, mips, powerpc, s390 and sparc the build
 failed. On my local machine (i386), the Ubuntu Launchpad PPA builders
 (i386, amd64 and lpia) and I assume Alessio's machine (amd64) 1.3.3-1
 built fine. All of the errors seem to be with pgrep being missing. I
 assume these can be fixed by adding pgrep as a build-dependency.
 Gabriel, was there something new in 1.3.3 that requires pgrep? Does
 anyone know why these errors didn't occur on the Launchpad PPA
 builders (is pgrep maybe installed by default??).


 I see that pgrep is provided by procps. This is a package with
 standard priority, so shouldn't it be in buildd by default? The Ubuntu
 version of procps is 1:3.2.8-1ubuntu4, compared to the higher Debian
 version of 1:3.2.8-9 so is it possible an unreported (I had a quick
 look through the bug list and couldn't find anything) bug has somehow
 got into the package between these two Debian revisions?

 --
 Harry Rickards - ha...@linux.com
 Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk



pgrep is required at runtime, but not for building.


Gabriel.


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: LiVES 1.3.3 failing to build

[salsaman]

On Tue, May 11, 2010 17:27, Harry Rickards wrote:
 On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote:
 Hi,

 From https://buildd.debian.org/status/package.php?p=lives I can see
 that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on
 alpha, hurd-i386, i386, ia64, mips, powerpc, s390 and sparc the build
 failed. On my local machine (i386), the Ubuntu Launchpad PPA builders
 (i386, amd64 and lpia) and I assume Alessio's machine (amd64) 1.3.3-1
 built fine. All of the errors seem to be with pgrep being missing. I
 assume these can be fixed by adding pgrep as a build-dependency.
 Gabriel, was there something new in 1.3.3 that requires pgrep? Does
 anyone know why these errors didn't occur on the Launchpad PPA
 builders (is pgrep maybe installed by default??).


 I see that pgrep is provided by procps. This is a package with
 standard priority, so shouldn't it be in buildd by default? The Ubuntu
 version of procps is 1:3.2.8-1ubuntu4, compared to the higher Debian
 version of 1:3.2.8-9 so is it possible an unreported (I had a quick
 look through the bug list and couldn't find anything) bug has somehow
 got into the package between these two Debian revisions?

 --
 Harry Rickards - ha...@linux.com
 Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk


pkill is also required at runtime (normally it would be in the same
package as pgrep). Is it a mistake to include runtime dependencies in the
config files ? (I guess I should remove these checks and add a runtime
check instead).

The manpage for pgrep and pkill mentions procps.


Gabriel.





Gabriel.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: LiVES 1.3.3 failing to build

[salsaman]

On Tue, May 11, 2010 17:58, Harry Rickards wrote:
 On 11 May 2010 16:53,  salsa...@xs4all.nl wrote:
 On Tue, May 11, 2010 17:27, Harry Rickards wrote:
 On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote:
 Hi,

 From https://buildd.debian.org/status/package.php?p=lives I can see
 that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on
 alpha, hurd-i386, i386, ia64, mips, powerpc, s390 and sparc the build
 failed. On my local machine (i386), the Ubuntu Launchpad PPA builders
 (i386, amd64 and lpia) and I assume Alessio's machine (amd64) 1.3.3-1
 built fine. All of the errors seem to be with pgrep being missing. I
 assume these can be fixed by adding pgrep as a build-dependency.
 Gabriel, was there something new in 1.3.3 that requires pgrep? Does
 anyone know why these errors didn't occur on the Launchpad PPA
 builders (is pgrep maybe installed by default??).


 I see that pgrep is provided by procps. This is a package with
 standard priority, so shouldn't it be in buildd by default? The Ubuntu
 version of procps is 1:3.2.8-1ubuntu4, compared to the higher Debian
 version of 1:3.2.8-9 so is it possible an unreported (I had a quick
 look through the bug list and couldn't find anything) bug has somehow
 got into the package between these two Debian revisions?

 --
 Harry Rickards - ha...@linux.com
 Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk



 pgrep is required at runtime, but not for building.



 Are you sure? ./configure seems to be checking for pgrep and failing
 if it is not installed.


Yes, that is probably an error on my part. Feel free to remove the
relevant lines for pgrep and pkill from configure.in and add a runtime
dependency on procps.


Gabriel.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: LiVES 1.3.3 failing to build

[salsaman]

On Tue, May 11, 2010 18:02, Harry Rickards wrote:
 On 11 May 2010 17:00,  salsa...@xs4all.nl wrote:
 On Tue, May 11, 2010 17:27, Harry Rickards wrote:
 On 11 May 2010 16:22, Harry Rickards ha...@linux.com wrote:
 Hi,

 From https://buildd.debian.org/status/package.php?p=lives I can see
 that armel, hppa and both kfreebsds built 1.3.3-1 fine, whereas on
 alpha, hurd-i386, i386, ia64, mips, powerpc, s390 and sparc the build
 failed. On my local machine (i386), the Ubuntu Launchpad PPA builders
 (i386, amd64 and lpia) and I assume Alessio's machine (amd64) 1.3.3-1
 built fine. All of the errors seem to be with pgrep being missing. I
 assume these can be fixed by adding pgrep as a build-dependency.
 Gabriel, was there something new in 1.3.3 that requires pgrep? Does
 anyone know why these errors didn't occur on the Launchpad PPA
 builders (is pgrep maybe installed by default??).


 I see that pgrep is provided by procps. This is a package with
 standard priority, so shouldn't it be in buildd by default? The Ubuntu
 version of procps is 1:3.2.8-1ubuntu4, compared to the higher Debian
 version of 1:3.2.8-9 so is it possible an unreported (I had a quick
 look through the bug list and couldn't find anything) bug has somehow
 got into the package between these two Debian revisions?

 --
 Harry Rickards - ha...@linux.com
 Vote Lib Dem - Building a fairer Britain - http://libdems.org.uk


 pkill is also required at runtime (normally it would be in the same
 package as pgrep). Is it a mistake to include runtime dependencies in
 the
 config files ? (I guess I should remove these checks and add a runtime
 check instead).

 The manpage for pgrep and pkill mentions procps.

 AFAICT both pkill and pgrep are provided in the procps package. I
 thought config files should only include build-time checks, but I
 could be wrong. Please could someone on the list clarify?



No, I think you are right. What confused me was that there is a check for
perl in the config.in. But now I realise that perl is required for
building.


Gabriel.



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers