I'm on Slamd64 using LiVES x86_64 version 0.9.9.3-1.
LiVES starts well and everything seems to be fine, but when I encode a clip with any encoder (multi_encoder, ffmpeg_encoder... etc) I get error, I just want to use multi_encoder, so, when I use it I get this error:
if abs(24000.0/1001.0 - float(fps)) < fpst: fpsc = '1'
ValueError: invalid literal for float(): 25,000
Thats in the terminal window, in LiVES I just get: Encoder error: No output file was created!
I'm going to explain how did I get this error with the video:
I open LiVES
I open 2 videos (15 FPS both) and 1 music track
I go to multitrack mode (output video will be 600 x 480 and 25 FPS)
I put the first video in the timeline and then the second one (just after the first) and I put the music as background music.
I render the video
I try to encode it with multi_encoder
I've tried any output format (lo_x.ogm, lo_h.avi...) in any quality and I get the same error
I've all dependencies for lives and its plugins installed, so I don't know why it fails...
hope u can help me, I'm really dissapointed with LiVES...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm...it seems the fix which I applied back in November, was only half of what was required...it turned out to be necessary to replace float() with locale.atof() as well.
Thanks for bringing this issue to my attention. It should be fixed properly in the next release !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this is a known issue in the multi_encoder - it can only handle decimal point as "." not ",". As a workaround you need to set your locale to one that uses ".", for example:
export LC_NUMERIC=C; lives
will probably fix the problem.
Gabriel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a big problem.
I'm on Slamd64 using LiVES x86_64 version 0.9.9.3-1.
LiVES starts well and everything seems to be fine, but when I encode a clip with any encoder (multi_encoder, ffmpeg_encoder... etc) I get error, I just want to use multi_encoder, so, when I use it I get this error:
if abs(24000.0/1001.0 - float(fps)) < fpst: fpsc = '1'
ValueError: invalid literal for float(): 25,000
Thats in the terminal window, in LiVES I just get: Encoder error: No output file was created!
I'm going to explain how did I get this error with the video:
I've tried any output format (lo_x.ogm, lo_h.avi...) in any quality and I get the same error
I've all dependencies for lives and its plugins installed, so I don't know why it fails...
hope u can help me, I'm really dissapointed with LiVES...
Hmmm...it seems the fix which I applied back in November, was only half of what was required...it turned out to be necessary to replace float() with locale.atof() as well.
Thanks for bringing this issue to my attention. It should be fixed properly in the next release !
This should be fixed completely now as of LiVES 1.0.0-pre2 which was released today.
Yes, this is a known issue in the multi_encoder - it can only handle decimal point as "." not ",". As a workaround you need to set your locale to one that uses ".", for example:
export LC_NUMERIC=C; lives
will probably fix the problem.
Gabriel.
so, if I execute this command anything will work or do I have to recompile lives using a new option in ./configure??
No, you shouldn't need to recompile anything.
Well, I continue getting exactly the same problem when execute the command you gave me
Thanks for the help and sorry for my ignorance
OK, ignore the preceding, this is the proper fix, I think:
as root, edit /usr/lib/lives/plugins/encoders/multi_encoder
add the following at the beginning:
!/usr/bin/env python
import locale
locale.setlocale(locale.LC_ALL,"C")
Please let me know if this fixes the problem.
Fix in above post works fine
Sorry to bring up an old post, but this is the first result when googling the error message and so this might be of some use.
lives-1.0.0-pre1 (ubuntu jaunty)
The fix should no longer be needed, since non-C locale support was added to all of the encoders.