From: Amitha P. <ami...@us...> - 2008-08-12 22:49:46
|
Folks, I'd like your thoughts on some ffmpeg- related issues. For the time constrained, a key question below is: can I check in a Windows DLL binary into the CVS source tree? We are currently using ffmpeg to read and write videos in vidl2. It is a incredible library for that purpose, and we should continue to use it. However, it changes its API, file layout, include paths, etc, quite often. (And it has no official releases to track.) Right now, vidl2 tries to support multiple versions by having #ifdef's in the code. With this, it is quite a pain to write a wrapper supporting multiple versions of ffmpeg. The recent versions of ffmpeg changed the layout of the include paths, so what used to be #include <avformat.h> is now #include <avformat/avformat.h> Supporting both options, while not increasing the include path length, creates a lot of work. Now, all of these issues can be worked around, given enough effort. Instead, I'd like to follow the lead of other projects using ffmpeg, by including a snapshot of ffmpeg in v3p. The problem is that ffmpeg will not build with the Visual C compiler. The source code uses a lot of C99isms that are hard to work around, and Visual C does not support C99. In fact, it is likely that ffmpeg will only build with gcc. Now, ffmpeg *can* be built for windows, using MingW and gcc. The resulting libraries can be used in Visual C projects. So, one option to build ffmpeg when possible, and to have pre-built binary version for the other cases. What do folks think of checking in binary support libraries like this? Instead of checking in the binary libraries into the vxl tree, we could make a separate checkout for the vxl-friendly ffmpeg, and this will contain binary libraries. What I want is for the ability to update vxl's ffmpeg wrapper relatively easily, and to make sure that the corresponding actual ffmpeg library can be updated just as easily. Thoughts? Amitha. |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2008-08-13 00:32:00
|
On Tue, Aug 12, 2008 at 6:49 PM, Amitha Perera wrote: <snip> > Now, ffmpeg *can* be built for windows, using MingW and gcc. The > resulting libraries can be used in Visual C projects. So, one option to > build ffmpeg when possible, and to have pre-built binary version for the > other cases. Amitha, By no means I am suggesting that this is a bad idea, but I would like to clarify some doubts out of curiosity. Does anyone know if there is any advantage in using FFMPEG in windows over DirectShow? Besides the fact that the output stream is not written and that in my experience it has been a pain... However, it has the advantage of supporting whatever is installed and registered in the system. In your opinion, would it be worth investing time in implementing complete DirectShow support rather than trying to make FFMPEG available in windows? Should we stick with FFMPEG instead of DirectShow? or is there significant advantage in having both DirectShow and FFMPEG pursued? --Miguel |
From: Amitha P. <ami...@us...> - 2008-08-13 11:54:30
|
Miguel A. Figueroa-Villanueva wrote: > Does anyone know if there is any advantage in using FFMPEG in windows > over DirectShow? Besides the fact that the output stream is not > written and that in my experience it has been a pain... However, it > has the advantage of supporting whatever is installed and registered > in the system. FFMPEG implements both encoding and decoding of video codecs that are often not available on typical Windows environments. Some of these codecs are not available for free on Windows, even if you were to download additional codecs. Not all encoders and decoder implementations are equal. (In general, the FFMPEG implementations are of good quality.) It's useful to have the *same* encoder and decoder on multiple platforms, so you know your program will produce the same output on multiple platforms, for a fixed input. > In your opinion, would it be worth investing time in implementing > complete DirectShow support rather than trying to make FFMPEG > available in windows? Should we stick with FFMPEG instead of > DirectShow? or is there significant advantage in having both > DirectShow and FFMPEG pursued? I think it's worthwhile to pursue both. In the same way that video4linux should be also pursued on Linux. As you say, the two give access to different code paths from which to access video. In particular, directshow on Windows will allow far more hardware devices to be used (webcams, etc), because the manufacturers often include Windows drivers. This is becoming less of an issue as the USB-video standard matures, but there are always higher-end/custom video hardware. Note also that directshow development files (headers, etc) are not trivially available on Windows. (At least, they weren't the last time I looked.) So, enabling directshow on Windows would require the user to download and install the directshow SDK. I also don't know how Vista has changed the directshow APIs. I know that Vista has done a complete rewrite of the graphics pipeline, but the API may be backwards compatible. Amitha. |
From: Matt L. <mat...@gm...> - 2008-08-13 13:44:10
|
Amitha and Miguel, I think there is a use for both FFMPEG and DirectShow on the Windows side. vidl2 was designed to allow for multiple types of input streams, even if they can handle the same data. I see no problem with Amitha adding support for FFMPEG on Windows, and it would also be great if Miguel (or any other Window guru) added the DirectShow output stream. People can choose which they would like to use or use both at once. It sounds like neither will build right out of the box without downloading something extra. In regard to the DLL, I prefer the separate repository for binaries. We don't need to bog down the source repository anymore than it is. However, I do think that this is a good idea. The other issue I see with putting FFMPEG in v3p is that code in v3p tends to go stale. While FFMPEG's continually changing API is a hassle, it also has some advantages. They are continually adding support for more video formats. In most Linux distributions a snapshot of FFMPEG is packaged and released every six months to a year or so. While it's a pain to support all of these "versions", it also means vidl2 gets support for more and more video formats. I imagine it requires a bit of work to VXLify a library for v3p (I've never done it myself). I'm worried that the v3p version won't be updated much if at all. A v3p version of FFMPEG would be useful in that it would provide a guaranteed-to-work-with-VXL version. It would also be easier to get up and running for many users. However, I would still like to allow external builds of FFMPEG to be used (I think most v3p libraries allow for this anyway). In vidl2, we can support the v3p version and optionally one or more newer versions. At some point we can bring a new snapshot into v3p and remove support for older versions. I don't see any any reason to support FFMPEG versions older than what is in v3p. Let me know what you plan to do. I'll try to help a bit if I can find some time. --Matt On Wed, Aug 13, 2008 at 7:54 AM, Amitha Perera <ami...@us...> wrote: > Miguel A. Figueroa-Villanueva wrote: >> Does anyone know if there is any advantage in using FFMPEG in windows >> over DirectShow? Besides the fact that the output stream is not >> written and that in my experience it has been a pain... However, it >> has the advantage of supporting whatever is installed and registered >> in the system. > > FFMPEG implements both encoding and decoding of video codecs that are > often not available on typical Windows environments. Some of these > codecs are not available for free on Windows, even if you were to > download additional codecs. > > Not all encoders and decoder implementations are equal. (In general, > the FFMPEG implementations are of good quality.) It's useful to have > the *same* encoder and decoder on multiple platforms, so you know your > program will produce the same output on multiple platforms, for a fixed > input. > >> In your opinion, would it be worth investing time in implementing >> complete DirectShow support rather than trying to make FFMPEG >> available in windows? Should we stick with FFMPEG instead of >> DirectShow? or is there significant advantage in having both >> DirectShow and FFMPEG pursued? > > I think it's worthwhile to pursue both. In the same way that > video4linux should be also pursued on Linux. As you say, the two give > access to different code paths from which to access video. In > particular, directshow on Windows will allow far more hardware devices > to be used (webcams, etc), because the manufacturers often include > Windows drivers. This is becoming less of an issue as the USB-video > standard matures, but there are always higher-end/custom video hardware. > > Note also that directshow development files (headers, etc) are not > trivially available on Windows. (At least, they weren't the last time I > looked.) So, enabling directshow on Windows would require the user to > download and install the directshow SDK. > > I also don't know how Vista has changed the directshow APIs. I know > that Vista has done a complete rewrite of the graphics pipeline, but the > API may be backwards compatible. > > Amitha. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Amitha P. <ami...@us...> - 2008-08-13 15:02:24
|
Matt Leotta wrote: > In regard to the DLL, I prefer the separate repository for binaries. > We don't need to bog down the source repository anymore than it is. > However, I do think that this is a good idea. The only issue with this is that a single cvs update will not keep the binary-cvs tree in sync with the source tree. So, "cvs update" on the vxl tree could cause the vidl2 wrapper to not match the v3p binary checkout. However, it should be straight-forward to spit out an error message in this case. > I'm worried that the v3p version won't be updated much if > at all. That's a valid concern. I certainly intend to keep up with ffmpeg, but my particular update speed may not match your needs. One issue with updating ffmpeg often is regression: things that worked before may not work in the newer version. I guess the only solution to that is regression testing. > However, I would still like to allow > external builds of FFMPEG to be used (I think most v3p libraries allow > for this anyway). I think this always has to be an option, but with the condition that the user is responsible for API mismatches. The problem with the current approach is that we don't actually know if the ffmpeg wrapper in vidl2 actually works, because each developer has a different version of the API. And if I "fix" it to work with mine, it might break for you, and we won't really know. A v3p'd version would give the stable version which is guaranteed to work. > In vidl2, we can support the v3p version and > optionally one or more newer versions. I like this idea. And to refine it a little further, and option might be to have two versions in v3p: a "stable" version that is only updated, say, once a year; and a "current" version that is updated more frequently. That way, you could rely on the "stable" version for a year before worrying about the same input producing different output because of bugfixes and changes in the video codecs. In addition to these two versions, you can use a system version, but you'd be responsible for any issues with it. > At some point we can bring a > new snapshot into v3p and remove support for older versions. I don't > see any any reason to support FFMPEG versions older than what is in > v3p. Agreed. Given the two tiers above, I see #ifdefs in the code for the "stable" version, and for versions >= "current". Nothing for versions < "stable", nor for versions > "stable" and < "current". (Better names for "stable" and "current" are welcome.) > Let me know what you plan to do. I'll try to help a bit if I can > find some time. My thinking is to create a directory at the "vxl" level called v3pbin, so that cvs co :pserver:vxl.cvs.sourceforge.net:/cvsroot/vxl co v3pbin will get you all the binary support stuff. cvs co :pserver:vxl.cvs.sourceforge.net:/cvsroot/vxl co v3pbin/ffmpeg/current will get you just ffmpeg support. The FindFFMPEG CMake files will understand that this v3pbin might exist, and will try to make it "just work" for folks that have both vxl and v3pbin checked out. Amitha. |
From: Amitha P. <ami...@us...> - 2008-08-13 21:16:45
|
Amitha Perera wrote: > Matt Leotta wrote: >> In regard to the DLL, I prefer the separate repository for binaries. >> We don't need to bog down the source repository anymore than it is. >> However, I do think that this is a good idea. > > The only issue with this is that a single cvs update will not keep the > binary-cvs tree in sync with the source tree. Actually, this will be somewhat of a bigger issue, unless we change the layout of the repository: for the dashboard builds, we want a single checkout that is completely in sync. Perhaps this layout change can be done along with the switch to subversion. Amitha. |
From: Ian S. <ian...@st...> - 2008-08-13 15:34:37
|
Amitha, I'm assuming that 1. The binary would sit alongside a full source version of ffmpeg in v3p - which would be compiled and used if possible. 2. vidl2 is successfully proposed and supported for upgrading to core, and someone commits to actually moving it, and writing a book chapter for it. (Only libraries in core should get their dependencies into v3p - to prevent bloating.) 3. There are not lots of other libraries out there that people want to use and have similar problems. In this special case it does seem like adding a BLOB to the repository is the least worst idea. However it is still not currently a good idea because CVS's performance with binaries is awful, and repository access is slow enough already. Perhaps this is the time to upgrade to subversion - we have been using at imorphics for over a year now, and are very happy with it. I would be happy to do the main cvs2svn conversion in a month or two's time. I've done two large conversions already and I have lots of script lines to clean up permissions, check binary/text flags, test for problems, etc. I would need someone else to volunteer to handle the dashboard changes, and someone to install scripts on the repository to mail vxl-commits, and check that the metadata properties, etc of future commits are correct. Ian. Amitha Perera wrote: > Folks, > > I'd like your thoughts on some ffmpeg- related issues. For the time > constrained, a key question below is: can I check in a Windows DLL > binary into the CVS source tree? > > We are currently using ffmpeg to read and write videos in vidl2. It is > a incredible library for that purpose, and we should continue to use it. > However, it changes its API, file layout, include paths, etc, quite > often. (And it has no official releases to track.) Right now, vidl2 > tries to support multiple versions by having #ifdef's in the code. With > this, it is quite a pain to write a wrapper supporting multiple versions > of ffmpeg. > > The recent versions of ffmpeg changed the layout of the include paths, > so what used to be > #include <avformat.h> > is now > #include <avformat/avformat.h> > Supporting both options, while not increasing the include path length, > creates a lot of work. > > Now, all of these issues can be worked around, given enough effort. > Instead, I'd like to follow the lead of other projects using ffmpeg, by > including a snapshot of ffmpeg in v3p. > > The problem is that ffmpeg will not build with the Visual C compiler. > The source code uses a lot of C99isms that are hard to work around, and > Visual C does not support C99. In fact, it is likely that ffmpeg will > only build with gcc. > > Now, ffmpeg *can* be built for windows, using MingW and gcc. The > resulting libraries can be used in Visual C projects. So, one option to > build ffmpeg when possible, and to have pre-built binary version for the > other cases. > > What do folks think of checking in binary support libraries like this? > > Instead of checking in the binary libraries into the vxl tree, we could > make a separate checkout for the vxl-friendly ffmpeg, and this will > contain binary libraries. > > What I want is for the ability to update vxl's ffmpeg wrapper relatively > easily, and to make sure that the corresponding actual ffmpeg library > can be updated just as easily. > > Thoughts? > > Amitha. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Matt L. <mat...@gm...> - 2008-08-13 16:13:33
|
On Wed, Aug 13, 2008 at 11:34 AM, Ian Scott <ian...@st...> wrote: > 1. The binary would sit alongside a full source version of ffmpeg in v3p > - which would be compiled and used if possible. This was my understanding of the proposal. > 2. vidl2 is successfully proposed and supported for upgrading to core, > and someone commits to actually moving it, and writing a book chapter > for it. (Only libraries in core should get their dependencies into v3p - > to prevent bloating.) Let me formally propose that vidl2 be promoted to core. I will take responsibility for it as lead maintainer. I will start writing a book chapter and I can handle the move when the time comes. The book chapter may take a little time since I have a lot on my plate right now. I'll document the overall usage and design of the library, but maybe the authors of specialized stream classes can contribute sections on each of those? > Perhaps this is the time to upgrade to subversion - we have been using > at imorphics for over a year now, and are very happy with it. I'm all for subversion, but I don't have time to volunteer for that effort as well. --Matt |
From: Peter V. <pet...@ya...> - 2008-08-14 07:42:49
|
> Let me formally propose that vidl2 be promoted to core. Would this also be a good moment to rename vidl to vild1 (as we did with vil/vil2/vil1) ? Is core/vidl still actively being used anymore, or is vidl2 "the" replacement for it? -- Peter. __________________________________________________________ Går det långsamt? Skaffa dig en snabbare bredbandsuppkoppling. Sök och jämför priser hos Kelkoo. http://www.kelkoo.se/c-100015813-bredband.html?partnerId=96914325 |
From: Wheeler, F. W (G. Research) <wh...@cr...> - 2008-08-14 10:33:09
|
> Would this also be a good moment to rename vidl to vild1 (as > we did with vil/vil2/vil1) ? > Is core/vidl still actively being used anymore, or is vidl2 > "the" replacement for it? It might be easier to rename vidl to vidl1 after the switch to subversion, which allows file moving and renaming. Fred |
From: Ian S. <ian...@st...> - 2008-08-14 11:05:18
|
Wheeler, Frederick W (GE, Research) wrote: >> Would this also be a good moment to rename vidl to vild1 (as >> we did with vil/vil2/vil1) ? >> Is core/vidl still actively being used anymore, or is vidl2 >> "the" replacement for it? > > It might be easier to rename vidl to vidl1 after the switch to > subversion, which allows file moving and renaming. Definitely wait for subversion (if everyone agrees) before attempting moves or renames. It was a real pain to rename vil->vil1 and vil2->vil, and still maintain history in CVS. Ian. |
From: Brendan M. <bre...@gm...> - 2008-08-14 21:56:20
|
I vote for subversion too. 2008/8/14 Ian Scott <ian...@st...>: > Wheeler, Frederick W (GE, Research) wrote: >>> Would this also be a good moment to rename vidl to vild1 (as >>> we did with vil/vil2/vil1) ? >>> Is core/vidl still actively being used anymore, or is vidl2 >>> "the" replacement for it? >> >> It might be easier to rename vidl to vidl1 after the switch to >> subversion, which allows file moving and renaming. > > Definitely wait for subversion (if everyone agrees) before attempting > moves or renames. It was a real pain to rename vil->vil1 and vil2->vil, > and still maintain history in CVS. > > Ian. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Gehua Y. <yan...@gm...> - 2008-08-14 22:05:05
|
I vote for subversion. Gehua |
From: Amitha P. <ami...@us...> - 2008-08-13 16:34:25
|
Ian Scott wrote: > Perhaps this is the time to upgrade to subversion - we have been using > at imorphics for over a year now, and are very happy with it. I vote in favor. > I would need someone else to volunteer to handle the > dashboard changes, and someone to install scripts on the repository to > mail vxl-commits, and check that the metadata properties, etc of future > commits are correct. I can volunteer for this. Assuming we will have permission to install/edit the necessary scripts on the server side. As a side effect of this conversion, I think it'd be nice to clean up the developer list for vxl. I'm not against giving people write access---it hasn't caused any issues so far---but most of the people on that list probably don't even use vxl, let alone contribute code. Amitha. |
From: Matt L. <mat...@gm...> - 2008-08-13 15:56:02
|
On Wed, Aug 13, 2008 at 11:02 AM, Amitha Perera <ami...@us...> wrote: >> However, I would still like to allow >> external builds of FFMPEG to be used (I think most v3p libraries allow >> for this anyway). > > I think this always has to be an option, but with the condition that the > user is responsible for API mismatches. Agreed >> In vidl2, we can support the v3p version and >> optionally one or more newer versions. > > I like this idea. And to refine it a little further, and option might be to > have two versions in v3p: a "stable" version that is only updated, say, once > a year; and a "current" version that is updated more frequently. That way, > you could rely on the "stable" version for a year before worrying about the > same input producing different output because of bugfixes and changes in the > video codecs. > > In addition to these two versions, you can use a system version, but you'd > be responsible for any issues with it. > > >> At some point we can bring a >> >> new snapshot into v3p and remove support for older versions. I don't >> see any any reason to support FFMPEG versions older than what is in >> v3p. > > Agreed. Given the two tiers above, I see #ifdefs in the code for the > "stable" version, and for versions >= "current". Nothing for versions < > "stable", nor for versions > "stable" and < "current". Originally I was thinking it might be useful to support a few builds > "stable" but < "current". These would be the prepackaged versions for current releases of various Linux distributions. Now I'm thinking it might just be simpler to build FFMPEG from source from the current CVS version. Then VXL only has to support the "stable" and "current" versions you mention. My only questions now is how current is "current"? I could update and build FFMPEG as part of a nightly build. I don't know how stable FFMPEG is on a daily basis and I don't want to propagate errors compiling FFMPEG to the VXL Dashboard. But maybe it's stable enough to do that. Another option is that manually update the "current" version when it is stable and I see a reason to update it. Thoughts on this? > My thinking is to create a directory at the "vxl" level called v3pbin, so > that > cvs co :pserver:vxl.cvs.sourceforge.net:/cvsroot/vxl co v3pbin > will get you all the binary support stuff. > cvs co :pserver:vxl.cvs.sourceforge.net:/cvsroot/vxl co > v3pbin/ffmpeg/current > will get you just ffmpeg support. > > The FindFFMPEG CMake files will understand that this v3pbin might exist, and > will try to make it "just work" for folks that have both vxl and v3pbin > checked out. This is exactly what I had in mind when I said separate repository. You can checkout vxl and not get v3pbin, but if you do checkout v3pbin into the vxl source directory an update of the vxl root will also update v3pbin. --Matt |
From: Amitha P. <ami...@us...> - 2008-08-13 16:29:39
|
Matt Leotta wrote: > My only questions now is how current is > "current"? I could update and build FFMPEG as part of a nightly > build. I don't know how stable FFMPEG is on a daily basis and I don't > want to propagate errors compiling FFMPEG to the VXL Dashboard. But > maybe it's stable enough to do that. I don't think it's stable enough to track daily. > Another option is that manually > update the "current" version when it is stable and I see a reason to > update it. Thoughts on this? This concept is what I have in mind. As soon as there is a new feature or capability in a newer ffmpeg that does something I want, I'll update the "current" version in v3pbin/current. All capabilities that are required in "current" will be captured by regression tests, so we can make sure that we aren't spoiling things for someone else. (If it does break something for someone, they'd have to (help) write a regression test to capture their requirements.) > This is exactly what I had in mind when I said separate repository. > You can checkout vxl and not get v3pbin, but if you do checkout v3pbin > into the vxl source directory an update of the vxl root will also > update v3pbin. I think this will work with some, but not all, cvs clients. Even if it doesn't, all it involves is a second cvs update, and CMake can prompt you to do it. Amitha. |