I want to retrieve metadata from a converted video using FFmpeg web assembly package.
I tried to extract a metadata.txt file to my current directory but nothing was return from my command
in my index.js file:
const { createFFmpeg, fetchFile } = require('#ffmpeg/ffmpeg')
const ffmpeg = createFFmpeg({ log: true })
await ffmpeg.load()
await ffmpeg.run('-i', "myvideo.avi'", '-f', 'ffmetadata', 'metadata.txt')
I got error :
Output file is empty, nothing was encoded.
Is this kind of command available on this wasm package? Found nothing relevant on their documentation and I want to avoid the global FFmpeg installation
Wasm doesn't read from the file system. You need to copy files into wasm virtual file system for it to be able to reference files.
I am deploying a web server, and after I finish compiling.There are the executing documents;
01client.c client epoll_server.c server
Then I try to run server
./server
There is an error which I cant fix it. I have search ways for solving but still can't fix it.
load error: No such file or directory
Maybe some one can help me,please!
Thanks a lot!!!!
System utilities print the program generating the error at the beginning of the line followed by other useful information such as the name of the missing file, so this is probably an error from a user program. I can duplicate the error as follows:
errno = 2;
perror("load error");
which prints:
load error: No such file or directory
Look for the perror line in the server code. If it isn't clear what file it can't find, print the string from the failed command it is reporting.
I have implemented custom object detector using YOLO for offline on CPU.
When I run this command on CPU:
!./darknet detector demo data/obj.data cfg/yolov4-obj.cfg yolov4-obj_final.weights -dont_show MVI_1615_VIS.avi -i 0 -out_filename results.avi
I get the following error:
GPU isn't used
OpenCV version: 3.2.0
names: Using default 'data/names.list'
Couldn't open file: data/names.list
Kindly help.
I came across this error recently. For me, it was a simple mistake in the obj.data file.
Instead of the correct version which is:
names = obj.names
I had:
names - obj.names
Hence why it couldnt find the obj.names file
Make sure there aren't any errors in the obj.data file. For more info, check out: https://github.com/AlexeyAB/darknet#how-to-train-to-detect-your-custom-objects
I am trying to run AddJar in my new notebook in ibm bluemix.
%AddJar https://github.com/ibm-cds-labs/spark.samples/blob/master/dist/helloSpark-assembly-2.1.jar -f
However, I keep receiving this error -
Starting download from https://github.com/ibm-cds-labs/spark.samples/blob/master/dist/helloSpark-assembly-2.1.jar
Finished download of helloSpark-assembly-2.1.jar
Out[8]:
Name: java.util.zip.ZipException
Message: error in opening zip file
StackTrace: java.util.zip.ZipFile.open(Native Method)
java.util.zip.ZipFile.<init>(ZipFile.java:235)
java.util.zip.ZipFile.<init>(ZipFile.java:165)
java.util.zip.ZipFile.<init>(ZipFile.java:179)
I tried all sort of URLs - raw, file etc. as specified in this other link, but no help.
%AddJar for hellospark_2.10-1.0.jar giving Name: java.util.zip.ZipException Message: error in opening zip file
Please advice.
Thanks
Raj
Your URL points to an HTML page with a download button. You must use a URL that points to the actual JAR file instead. I got it by right-clicking on the download button and selecting "Copy Link Address". The URL has /raw/ instead of /blob/ in the path:
%AddJar https://github.com/ibm-cds-labs/spark.samples/raw/master/dist/helloSpark-assembly-2.1.jar -f
That line "worked" for me, in the sense that I got a totally different error messages on the first try: Assertion failed. After restarting the kernel and re-executing the %AddJar, the error was gone. Maybe my service didn't have the download directory yet when I executed the line for the first time.
I am developing application where user can upload some drawings in pdf format. Uploaded files are stored on S3. After uploading, files has to be converted to images. For this purpose I have created lambda function which downloads file from S3 to /tmp folder in lambda execution environment and then I call ‘convert’ command from imagemagick.
convert sourceFile.pdf targetFile.png
Lambda runtime environment is nodejs 4.3. Memory is set to 128MB, timeout 30 sec.
Now the problem is that some files are converted successfully while others are failing with the following error:
{ [Error: Command failed: /bin/sh -c convert /tmp/sourceFile.pdf
/tmp/targetFile.png convert: %s' (%d) "gs" -q -dQUIET -dSAFER -dBATCH
-dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" "-sOutputFile=/tmp/magick-QRH6nVLV--0000001" "-f/tmp/magick-B610L5uo"
"-f/tmp/magick-tIe1MjeR" # error/utility.c/SystemCommand/1890.
convert: Postscript delegate failed/tmp/sourceFile.pdf': No such
file or directory # error/pdf.c/ReadPDFImage/678. convert: no images
defined `/tmp/targetFile.png' #
error/convert.c/ConvertImageCommand/3046. ] killed: false, code: 1,
signal: null, cmd: '/bin/sh -c convert /tmp/sourceFile.pdf
/tmp/targetFile.png' }
At first I did not understand why this happens, then I tried to convert problematic files on my local Ubuntu machine with the same command. This is the output from terminal:
**** Warning: considering '0000000000 XXXXX n' as a free entry.
**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> Mac OS X 10.10.5 Quartz PDFContext <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.
So the message was very clear, but the file gets converted to png anyway. If I try to do convert source.pdf target.pdf and after that convert target.pdf image.png, file is repaired and converted without any errors. This doesn’t work with lambda.
Since the same thing works on one environment but not on the other, my best guess is that the version of Ghostscript is the problem. Installed version on AMI is 8.70. On my local machine Ghostsript version is 9.18.
My questions are:
Is the version of ghostscript problem? Is this a bug with older
version of ghostscript? If not, how can I tell ghostscript (with or
without using imagemagick) to repair or ignore errors like it does on
my local environment?
If the old version is a problem, is it possible to build ghostscript
from source, create nodejs module and then use that version of
ghostscript instead the one that is installed?
Is there an easier way to convert pdf to image without using
imagemagick and ghostscript?
UPDATE
Relevant part of lambda code:
var exec = require('child_process').exec;
var AWS = require('aws-sdk');
var fs = require('fs');
...
var localSourceFile = '/tmp/sourceFile.pdf';
var localTargetFile = '/tmp/targetFile.png';
var writeStream = fs.createWriteStream(localSourceFile);
writeStream.write(body);
writeStream.end();
writeStream.on('error', function (err) {
console.log("Error writing data from s3 to tmp folder.");
context.fail(err);
});
writeStream.on('finish', function () {
var cmd = 'convert ' + localSourceFile + ' ' + localTargetFile;
exec(cmd, function (err, stdout, stderr ) {
if (err) {
console.log("Error executing convert command.");
context.fail(err);
}
if (stderr) {
console.log("Command executed successfully but returned error.");
context.fail(stderr);
}else{
//file converted successfully - do something...
}
});
});
You can find a compiled version of Ghostscript for Lambda in the following repository.
You should add the files to the zip file that you are uploading as the source code to AWS Lambda.
https://github.com/sina-masnadi/lambda-ghostscript
This is an npm package to call Ghostscript functions:
https://github.com/sina-masnadi/node-gs
After copying the compiled Ghostscript files to your project and adding the npm package, you can use the executablePath('path to ghostscript') function to point the package to the compiled Ghostscript files that you added earlier.
Its almost certainly a bug, or perhaps limitation, with the older version of Ghostscript.
Many PDF producers create PDF files which do not conform to the specification, and yet will open without complain in Adobe Acrobat. Ghostscript endeavours to do the same, but obviously we can't know what Acrobat is going to allow, so we are continually chasing this nebulous target. (FWIW that warning is a legitimate out-of-spec PDF file).
There's nothing you can do with the old version other than replace it.
Yes you can build Ghostscript from source, I have no idea about a nodejs module, not sure why that's relevant.
There are numerous other applications which will render a PDF file, MuPDF is another one I know of. And, of course, you can use Ghostscript directly without using ImageMagick. Of course, if you can load another application, then you should simply be able to replace your Ghostscript installation too.
The version of GS on aws is an old version with known bugs. We can get around this by uploading an x64 GS file, compiled specifically for Linux. Then upload that using new AWS lambda layers. I have written a node function that does just this here:
https://github.com/rcastoro/PDFImagine
Make sure you have that GS layer for your lambda, however!