Re: ffmpeg
On Saturday, 19 August 2017 at 02:50:44 UTC, Johnson Jones wrote: Trying to get it to work. You could just try to use/call the ffmeg executable as wrapper. For sure, not the best, but proabably the easiest solution. Afaik it also supports pipes.
ffmpeg
Trying to get it to work. 1. The libraries from the main download site seem to be in coff format for x86. This means they don't really work for dmd. I use omf and I tried to use coffimplib on the lib files and it says they are not import libraries. 2. The x64 version works without issue. (I was able to run the test version after adding the dll's, since the libs seem to require them for some oddball reason) 3. When I use -m32mscoff I get Win32\Debug DMD\test.obj Offset 0H Record Type 004C Error 138: Module or Dictionary corrupt 4. Also, visual Studio cannot launch the x64 program with the debugger attached so I have to run it from the command line. It was working before, but when I started messing with the ffmpeg stuff it broke. So at this point the only way I can use ffmpeg is x64 and running stuff from the command line... This is not the way I want to go.
Re: Using ffmpeg in command line with D
On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote: Will this work Yes. and is it the right approach used by video convertor front-ends? Well, yes, provisionally. When you invoke "ffmpeg" via spawnProcess, that isolates ffmpeg as its own process, obviously. From a security and maintenance standpoint, that is very, very good. None of the code in ffmpeg has to be considered when writing your own code, other than how it acts when you call it. If ffmpeg scrambles its own memory, your program won't get messed up. If your program scrambles its own memory, ffmpeg won't get corrupted, and neither will your video file. There are a few downsides though. It's expensive to set up that very restricted, isolated interface (executing a process) but considering the amount of number crunching involved in processing videos it's a pretty negligible cost. If you're doing some sort of web server that serves up a million generated pages a minute though, all that executing can bog it down. But you wouldn't use ffmpeg for that. The extreme isolation of a separate process means that you're restricted in what you can do with the video. You can do anything that ffmpeg devs write in their interface, but that's it. If they change the format of their command, all your stuff will break until you fix that, but considering how old ffmpeg is, that's probably not going to happen any time soon. In some cases, there are resources that cannot be reused between two processes, that are very expensive to set up and tear down. You wouldn't use mpv like ffmpeg for instance, because it would have to recreate the video display window every execution. Instead, mpv has a "socket" interface that you can connect to after launching one process, and use that to control the player. So, for video conversion, yes it's the right approach. Your mileage may vary if you want to display that video, or generate videos on-demand from a high performance webserver. (in which case the video processing will still be 99.999% of what slows you down, not process execution).
Re: Using ffmpeg in command line with D
On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote: I am new to this kind of multimedia stuff and all this is currently theoretical. Will this work and is it the right approach used by video convertor front-ends? Eh, it is how I did it before, it works and is pretty easy to do.
Using ffmpeg in command line with D
Hi all, I'm trying to convert an array of video filenames to another format using spawnProcess() from std.process. I want to convert all files in sequence with the command "ffmpeg -i filename.mp4 -o outputfile.webm" where process will be run one process after the other. I am new to this kind of multimedia stuff and all this is currently theoretical. Will this work and is it the right approach used by video convertor front-ends?
Re: FFMPEG Bindings
On Tuesday, 7 July 2015 at 03:05:11 UTC, ketmar wrote: How stable has the FFMPEG API since beginning 2015? don't know, but various players stop bundling ffmpeg long time ago. i assume that API is stable enough to stop worrying about it. Ok, thanks.
Re: FFMPEG Bindings
p.s. "stop bundling" means "stop bundling their own private versions in source tree, and started to use system version" here. signature.asc Description: PGP signature
Re: FFMPEG Bindings
On Mon, 06 Jul 2015 16:42:08 +, Per Nordlöw wrote: > How stable has the FFMPEG API since beginning 2015? don't know, but various players stop bundling ffmpeg long time ago. i assume that API is stable enough to stop worrying about it. warning. information deduced, but not checked. signature.asc Description: PGP signature
FFMPEG Bindings
Have anybody used the FFMPEG bindings at https://bitbucket.org/sumitraja/ffmpeg-d ? Specifically do I have to check for a specific version of the libraries to stay in sync with the version bindings? How stable has the FFMPEG API since beginning 2015? What's the policy on future API breaking Changes?
Re: Linking with FFmpeg
Am Mon, 07 Jan 2013 03:31:51 +0100 schrieb "MrOrdinaire" : > > I agree with you. > > One quick question, why do you need a pair of parentheses in > these declarations, ref (ubyte*)[4] and (ubyte*)[4]? The compiler > doesn't complain if I remove it. I wasn't sure if it's necessary. Imho it makes the code easier to read but that's probably just a personal preference.
Re: Linking with FFmpeg
On Sunday, 6 January 2013 at 18:39:32 UTC, Johannes Pfau wrote: Am Sun, 06 Jan 2013 09:43:11 -0800 schrieb Ali Çehreli : Ali P.S. To prove the point that that 4 in the signature has no meaning, I tested the C function also with the following C program: With C's arrays are pointers thing, that might be true. But the signature (and ffmpeg) documentation suggest that the av_image_alloc function will always write 4 ubyte* pointers to the pointers parameter. So you can't use an array smaller than 4 pointers. You can use more, as it doesn't matter for the ABI, but av_image_alloc will only use 4 pointers. So I'd argue that ((ubyte*)[4])* is better as a type than ubyte** as it allows the D compiler to do more checks. And the Interfacing to C page recommends using ref for static arrays instead of a pointer, as that allows using the code as in C: void av_image_alloc(ref (ubyte*)[4]); (ubyte*)[4] ptr; av_image_alloc(ptr); void av_image_alloc((ubyte*)[4]*); (ubyte*)[4] ptr; av_image_alloc(&ptr); //need & void av_image_alloc(ubyte**); (ubyte*)[3] ptr; ubyte* test; //overwritten, BUG! av_image_alloc(&ptr); //need &, and accepts to small arrays, bug prone I agree with you. One quick question, why do you need a pair of parentheses in these declarations, ref (ubyte*)[4] and (ubyte*)[4]? The compiler doesn't complain if I remove it.
Re: Linking with FFmpeg
Am Sun, 06 Jan 2013 09:43:11 -0800 schrieb Ali Çehreli : > > Ali > > P.S. To prove the point that that 4 in the signature has no meaning, > I tested the C function also with the following C program: With C's arrays are pointers thing, that might be true. But the signature (and ffmpeg) documentation suggest that the av_image_alloc function will always write 4 ubyte* pointers to the pointers parameter. So you can't use an array smaller than 4 pointers. You can use more, as it doesn't matter for the ABI, but av_image_alloc will only use 4 pointers. So I'd argue that ((ubyte*)[4])* is better as a type than ubyte** as it allows the D compiler to do more checks. And the Interfacing to C page recommends using ref for static arrays instead of a pointer, as that allows using the code as in C: void av_image_alloc(ref (ubyte*)[4]); (ubyte*)[4] ptr; av_image_alloc(ptr); void av_image_alloc((ubyte*)[4]*); (ubyte*)[4] ptr; av_image_alloc(&ptr); //need & void av_image_alloc(ubyte**); (ubyte*)[3] ptr; ubyte* test; //overwritten, BUG! av_image_alloc(&ptr); //need &, and accepts to small arrays, bug prone
Re: Linking with FFmpeg
On 01/06/2013 01:48 AM, MrOrdinaire wrote:
> My question is how this function declaration is written in D.
> int av_image_alloc(uint8_t *pointers[4], int linesizes[4],
> int w, int h, enum AVPixelFormat pix_fmt, int align);
1) No array is passed to a function as-is in C. Even though there seem
to be arrays of 4 elements above, they are both passed as pointers to
their first elements. (That 4 has no bearing at all.)
2) uint8_t *pointers[4] means an array of elements of type 'uint8_t*'.
3) int linesizes[4] means an array of ints.
4) uint8_t and friends are defined in the std.stdint module in Phobos.
5) enum should not be used in that signature in D.
6) align is a keyword and cannot be used.
This is the declaration of that function in D:
extern(C)
int av_image_alloc(uint8_t** pointers, int* linesizes,
int w, int h, AVPixelFormat pix_fmt, int alignment);
Here is a program that I used to test it:
import std.stdint;
extern(C)
{
enum AVPixelFormat
{
one, two
}
int av_image_alloc(uint8_t** pointers, int* linesizes,
int w, int h, AVPixelFormat pix_fmt, int alignment);
}
void main()
{
uint8_t ui0 = 7;
uint8_t ui1 = 8;
uint8_t*[] pointers = [ &ui0, &ui1 ];
// Ditto
int[] linesizes = [ 20, 30, 40 ];
int result = av_image_alloc(pointers.ptr, linesizes.ptr,
44, 55, AVPixelFormat.two, 100);
assert(result == 42);
}
I tested it with the following C file:
#include
#include
enum AVPixelFormat
{
AVPixelFormat_one, AVPixelFormat_two
};
int av_image_alloc(uint8_t *pointers[4], int linesizes[4],
int w, int h, enum AVPixelFormat pix_fmt, int align)
{
assert(*pointers[0] == 7);
assert(*pointers[1] == 8);
assert(linesizes[0] == 20);
assert(linesizes[1] == 30);
assert(linesizes[2] == 40);
assert(w == 44);
assert(h == 55);
assert(pix_fmt == AVPixelFormat_two);
assert(align == 100);
return 42;
}
I compiled the C file like this:
$ gcc -c deneme.c
Then compiled the D program like this (note that the C .o was in a
different directory):
$ dmd ../c/deneme.o deneme.d
And ran it like this:
$ ./deneme
All assertions passed. Yay! :)
Ali
P.S. To prove the point that that 4 in the signature has no meaning, I
tested the C function also with the following C program:
int main()
{
uint8_t ui0 = 7;
uint8_t ui1 = 8;
// Deliberately 10 (not 4) to prove a point
uint8_t* pointers[10] = { &ui0, &ui1 };
// Ditto
int linesizes[10] = { 20, 30, 40 };
av_image_alloc(pointers, linesizes, 44, 55, AVPixelFormat_two, 100);
}
Re: Linking with FFmpeg
Johannes Pfau: also says C int is the same as D int. How is this possible? Bye, bearophile
Re: Linking with FFmpeg
On Sunday, 6 January 2013 at 11:54:34 UTC, bearophile wrote: MrOrdinaire: For the symbol "*", do you mean I should write something like this? uint8_t[4]* ptrs In D "ubyte" is probably enough, instead of "uint8_t". Bye, bearophile Thanks for noting that. I know that in std.stdint, uint8_t is an alias for ubyte. However, I want to keep to the original source so that people can do a diff more easily. - Minh
Re: Linking with FFmpeg
On Sunday, 6 January 2013 at 12:46:05 UTC, Johannes Pfau wrote: Am Sun, 06 Jan 2013 10:48:25 +0100 schrieb "MrOrdinaire" : Hi, I am working on D bindings for FFmpeg. I am trying to port the official examples of FFmpeg to D so that the bindings can be tested. My question is how this function declaration is written in D. int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt, int align); My C is pretty bad, is uint8_t *pointers[4] a static array with 4 elements of uint8_t* or is it a pointer to a static array with 4 uint8_t elements? I guess it's the former, so in D it's (uint8_t*)[4] or better (ubyte*)[4]. In D static arrays are passed by value, in C by reference, so you have to do this: extern(C) int av_image_alloc(ref (ubyte*)[4] pointers, ref int[4] linesizes, int w, int h, AVPixelFormat pix_fmt, int align_); Some more information is here: http://dlang.org/interfaceToC.html According to this (http://c-faq.com/decl/spiral.anderson.html), I think pointers is an array of 4 pointers to uint8_t. So in D, you read declarations from right to left? - Minh
Re: Linking with FFmpeg
On Sun, Jan 06, 2013 at 10:48:25AM +0100, MrOrdinaire wrote:
> Hi,
>
> I am working on D bindings for FFmpeg. I am trying to port the
> official examples of FFmpeg to D so that the bindings can be tested.
>
> My question is how this function declaration is written in D.
> int av_image_alloc(uint8_t *pointers[4], int linesizes[4],
>int w, int h, enum AVPixelFormat pix_fmt, int
> align);
>
> My best guess is the following.
> extern(C) int av_image_alloc(ref uint8_t[4] *pointers, ref int[4]
> linesizes,
> int w, int h, AVPixelFormat pix_fmt,
> int align_);
The first parameter should be: uint8_t* pointers, and you need to call
it like this:
uint8_t[4] pointers;
int[4] linesizes;
auto ret = av_image_alloc(pointers.ptr, linesizes.ptr, ...);
To make it D-friendly, you might want to consider using a wrapper
function that takes ref uint8_t[4] and ref int[4] instead.
> However, calling this would give nonsense value for the array passed
> as linesizes. I don't know how to look at the variable passed as
> pointers yet.
[...]
Just write *ptr to dereference a pointer. You can also take advantage of
D's auto-dereferencing:
struct S {
int val = 123;
}
S s;
S* ptr = &s;
writeln(s.val); // prints 123
writeln(ptr.val); // also prints 123 (ptr is automatically
// dereferenced)
Finally, please note that in D, the * in pointer types associate with
the _type_ rather than the variable name (as in C/C++), so you should
always write "int* x,y" instead of "int *x, *y". Similarly, an array of
pointers is written as "int*[] arr", whereas writing "int[]* arr" is
actually declaring a pointer to an array. (In D, pointers and arrays are
not the same thing.)
T
--
I don't trust computers, I've spent too long programming to think that
they can get anything right. -- James Miller
Re: Linking with FFmpeg
Am Sun, 06 Jan 2013 10:48:25 +0100 schrieb "MrOrdinaire" : > Hi, > > I am working on D bindings for FFmpeg. I am trying to port the > official examples of FFmpeg to D so that the bindings can be > tested. > > My question is how this function declaration is written in D. > int av_image_alloc(uint8_t *pointers[4], int linesizes[4], > int w, int h, enum AVPixelFormat pix_fmt, int > align); > My C is pretty bad, is uint8_t *pointers[4] a static array with 4 elements of uint8_t* or is it a pointer to a static array with 4 uint8_t elements? I guess it's the former, so in D it's (uint8_t*)[4] or better (ubyte*)[4]. In D static arrays are passed by value, in C by reference, so you have to do this: extern(C) int av_image_alloc(ref (ubyte*)[4] pointers, ref int[4] linesizes, int w, int h, AVPixelFormat pix_fmt, int align_); Some more information is here: http://dlang.org/interfaceToC.html
Re: Linking with FFmpeg
Am Sun, 06 Jan 2013 12:51:33 +0100 schrieb "bearophile" : > MrOrdinaire: > > > I cannot find "cint_t" nor "cint" in the d standard modules > > (mine are at /usr/include/d/). > > I don't remember the correct name. > Are you sure about c_int? I never heard of that before, I only know c_long and c_ulong (in core.stdc.config). http://dlang.org/interfaceToC.html also says C int is the same as D int.
Re: Linking with FFmpeg
MrOrdinaire: For the symbol "*", do you mean I should write something like this? uint8_t[4]* ptrs In D "ubyte" is probably enough, instead of "uint8_t". Bye, bearophile
Re: Linking with FFmpeg
MrOrdinaire: I cannot find "cint_t" nor "cint" in the d standard modules (mine are at /usr/include/d/). I don't remember the correct name. For the symbol "*", do you mean I should write something like this? uint8_t[4]* ptrs Right. It's a D coding style convention that has a practical base. In C this means a is a pointer and b is an integer, while in D it means both are pointers: int *a, b; In C this means a is an int and b is a pointer, while in D it's thankfully an error (Error: multiple declarations must have the same type, not int and int*): int a, *b; Bye, bearophile
Re: Linking with FFmpeg
On Sunday, 6 January 2013 at 10:21:56 UTC, bearophile wrote: MrOrdinaire: My question is how this function declaration is written in D. int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt, int align); My best guess is the following. extern(C) int av_image_alloc(ref uint8_t[4] *pointers, ref int[4] linesizes, int w, int h, AVPixelFormat pix_fmt, int align_); D ints are 32 bit long, while the length of C ints varies across different architectures. So you can't use int in your D signature. sizediff_t is better, but I remember there is a more specific type for this purpose, something like cint_t, I don't remember. In D the pointer symbol "*" is better (more meaningful) written justified on the right. If you use a D ref, you can't put a null there. Others will give you a better answer. Bye, bearophile Thank you for your reply. I cannot find "cint_t" nor "cint" in the d standard modules (mine are at /usr/include/d/). For the symbol "*", do you mean I should write something like this? uint8_t[4]* ptrs - Minh
Re: Linking with FFmpeg
MrOrdinaire: My question is how this function declaration is written in D. int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt, int align); My best guess is the following. extern(C) int av_image_alloc(ref uint8_t[4] *pointers, ref int[4] linesizes, int w, int h, AVPixelFormat pix_fmt, int align_); D ints are 32 bit long, while the length of C ints varies across different architectures. So you can't use int in your D signature. sizediff_t is better, but I remember there is a more specific type for this purpose, something like cint_t, I don't remember. In D the pointer symbol "*" is better (more meaningful) written justified on the right. If you use a D ref, you can't put a null there. Others will give you a better answer. Bye, bearophile
Linking with FFmpeg
Hi, I am working on D bindings for FFmpeg. I am trying to port the official examples of FFmpeg to D so that the bindings can be tested. My question is how this function declaration is written in D. int av_image_alloc(uint8_t *pointers[4], int linesizes[4], int w, int h, enum AVPixelFormat pix_fmt, int align); My best guess is the following. extern(C) int av_image_alloc(ref uint8_t[4] *pointers, ref int[4] linesizes, int w, int h, AVPixelFormat pix_fmt, int align_); However, calling this would give nonsense value for the array passed as linesizes. I don't know how to look at the variable passed as pointers yet. The whole source of the port is at https://gist.github.com/4466289, there you can also find the link to the original source. Thanks, Minh
Re: Anybody ever tried to work with ffmpeg?
On Tue, 03 Feb 2009 23:25:29 +0100, Mike wrote: Never mind - as it usually is, 5 minutes after sending a question to a NG (after 2 hours of wasted time) you have the correct idea. In this case, I called "avcodec_register_all" instead of "av_register_all" before "avformat_open_input_file". Works now. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Anybody ever tried to work with ffmpeg?
Hi! I'm trying to get ffmpeg to work with D; I've got some stuff running, but ... well. av_open_input_file gives me -2 as an error and I can't figure out what this means (the #defines for the error codes are impossible to understand, much less translate to D). Anybody ever done that and can give me any hint? The documentation for ffmpeg is really not too ... wordy. Or: does anybody know a good decoding library to use with D? I'm very open to the idea of not using ffmpeg, but there's not much alternatives as far as I could find. -Mike -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
