Fix for drawtext under FreeBSD
Hi there -- I'm not a developer but I just came across an problem using drawtext vhook under FreeBSD that I managed to fix. Basically drawtext was complaining that I was not passing the parameters -t and -f, although I was. The vhook module has the following lines to parse it's command line parameters: optind = 0; while ((c = getopt(argc, argv, "f:t:T:x:y:s:c:C:bo")) > 0) { On FreeBSD, getopt() will return -1 when the first non-argument is found. So, if optind is set to ZERO, the first string it will check will be the module's filename, which of course is not considered an argument (as it doesn't have "-" on the beginning). So, regardless of the parameters I was passing, it was always failing. See getopt() manpage for FreeBSD[1]. On Linux, getopt() permutes the contents of argv during scan to make sure all non-argument strings are at the end, so having optind set to ZERO doesn't really make any difference as the module's filename would be shifted to the end and the parameters would be properly parsed. See getopt() manpage for Linux[2]. The solution is simply change: optind = 1; That way, both Linux and FreeBSD will skip the vhook's filename and will check only the parameters as we want. By the way, the vhook watermark.c uses this same approach I'm suggesting here (setting optind=1). I have tested the module with this little modification both on Linux and FreeBSD and it now works. Best regards, Eduardo M. Bragatto.
I've sent this message a while ago and had no feedback so far.. Do I need to create a patch form the latest snapshot in order to have my change being applied to the next release? That's a very serious problem for those running drawtext vhook under FreeBSD (it simply does not work at all!!!). The fix couldn't be more simple, other vhook modules work the same way as I'm suggesting here, it's just drawtext module that has a problem with the portability to other OSes where getopt() does not behaviour the same way as under Linux. (I do like British english, behaviour is not misspelled). If you guys don't care about portability to other OSes than Linux, let me know so I can contact the FreeBSD development list and having them patching the source under the ports system. Regards, Eduardo M. Bragatto. Eduardo M. Bragatto wrote:
Hi there --
I'm not a developer but I just came across an problem using drawtext vhook under FreeBSD that I managed to fix. Basically drawtext was complaining that I was not passing the parameters -t and -f, although I was.
The vhook module has the following lines to parse it's command line parameters:
optind = 0; while ((c = getopt(argc, argv, "f:t:T:x:y:s:c:C:bo")) > 0) {
On FreeBSD, getopt() will return -1 when the first non-argument is found. So, if optind is set to ZERO, the first string it will check will be the module's filename, which of course is not considered an argument (as it doesn't have "-" on the beginning). So, regardless of the parameters I was passing, it was always failing. See getopt() manpage for FreeBSD[1].
On Linux, getopt() permutes the contents of argv during scan to make sure all non-argument strings are at the end, so having optind set to ZERO doesn't really make any difference as the module's filename would be shifted to the end and the parameters would be properly parsed. See getopt() manpage for Linux[2].
The solution is simply change:
optind = 1;
That way, both Linux and FreeBSD will skip the vhook's filename and will check only the parameters as we want.
By the way, the vhook watermark.c uses this same approach I'm suggesting here (setting optind=1).
I have tested the module with this little modification both on Linux and FreeBSD and it now works.
Best regards, Eduardo M. Bragatto.
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hello, This seems like a simple change and you appear to have done your research but I don't know if your solution is correct, I'll let others comment on that. On 02/01/2008, Eduardo M. Bragatto <eduardo at bragatto.com> wrote:
I've sent this message a while ago and had no feedback so far..
A few days isn't that long.
Do I need to create a patch form the latest snapshot in order to have my change being applied to the next release?
FFmpeg doesn't really have releases, unless you consider every svn revision a release. :) Make a patch against an svn checkout using svn diff.
That's a very serious problem for those running drawtext vhook under FreeBSD (it simply does not work at all!!!). The fix couldn't be more simple, other vhook modules work the same way as I'm suggesting here, it's just drawtext module that has a problem with the portability to other OSes where getopt() does not behaviour the same way as under Linux. (I do like British english, behaviour is not misspelled).
Yey! We need more British English lovers! :) vhook is essentially deprecated as far as I am aware and libavfilter is just being polished to be pulled in to trunk though I'm not sure how much work remains to be done. However, as you say, it does seem like a very small change, would be in favour of consistency with other vhooks modules and you present a reasonable argument.
If you guys don't care about portability to other OSes than Linux, let me know so I can contact the FreeBSD development list and having them patching the source under the ports system.
I think portability is generally high on the agenda of FFmpeg developers if the flame wars on these mailing lists are anything to go by, it's somewhat a gold standard. I expect someone will look at this shortly and give it a response. Please be patient and if no one has responded in a few more days then maybe no one is interested in vhooks. Regards, Rob
vhook is essentially deprecated as far as I am aware and libavfilter is just being polished to be pulled in to trunk though I'm not sure how much work remains to be done. However, as you say, it does seem like a very small change, would be in favour of consistency with other vhooks modules and you present a reasonable argument.
From my point of view, it doesn't matter it is "deprecated" or not, it's still a part of the package that people use and it has an error, thus it should be fixed. There's no arguing about that. If it was truly deprecated, it would have been already removed from the package! I also have a very good amount of customers using vhook functions, so if the change was added to the official code, it would definitely make my life easier (and a lot of other people's life that use the same vhook too). I'm just trying to help here... If it's not welcome just let me know, I hate flame wars, specially starting a new one...
I expect someone will look at this shortly and give it a response. Please be patient and if no one has responded in a few more days then maybe no one is interested in vhooks.
I'm not really concerned about time response as I'm able to fix the problem myself when needed, I only contacted the list because I thought it would interest other people too. But, if the developers are aware of such a simple error but are not willing to fix it (it doesn't even take one minute), then I'll have to think the ffmpeg project is not really that serious or committed to produce good quality software. But, as I said, I don't start a flame war... I'll patiently wait for a reply before considering the development group a bunch of slack programmers hehehehe :) --- hey, just kidding ok? don't take it seriously! :D []s Eduardo.
I'm not really concerned about time response as I'm able to fix the problem myself when needed, I only contacted the list because I thought it would interest other people too.
But, if the developers are aware of such a simple error but are not willing to fix it (it doesn't even take one minute), then I'll have to think the ffmpeg project is not really that serious or committed to produce good quality software.
But, as I said, I don't start a flame war... I'll patiently wait for a reply before considering the development group a bunch of slack programmers hehehehe :) --- hey, just kidding ok? don't take it seriously! :D
dickhead.
[]s Eduardo. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi, Eduardo M. Bragatto said:
Hi there --
I'm not a developer but I just came across an problem using drawtext vhook under FreeBSD that I managed to fix. Basically drawtext was complaining that I was not passing the parameters -t and -f, although I was.
The vhook module has the following lines to parse it's command line parameters:
optind = 0; while ((c = getopt(argc, argv, "f:t:T:x:y:s:c:C:bo")) > 0) {
On FreeBSD, getopt() will return -1 when the first non-argument is found. So, if optind is set to ZERO, the first string it will check will be the module's filename, which of course is not considered an argument (as it doesn't have "-" on the beginning). So, regardless of the parameters I was passing, it was always failing. See getopt() manpage for FreeBSD[1].
On Linux, getopt() permutes the contents of argv during scan to make sure all non-argument strings are at the end, so having optind set to ZERO doesn't really make any difference as the module's filename would be shifted to the end and the parameters would be properly parsed. See getopt() manpage for Linux[2].
The solution is simply change:
optind = 1;
That way, both Linux and FreeBSD will skip the vhook's filename and will check only the parameters as we want.
By the way, the vhook watermark.c uses this same approach I'm suggesting here (setting optind=1).
I have tested the module with this little modification both on Linux and FreeBSD and it now works.
The OpenGroup says that optind shall be initialized to 1 by the system, so optind = 1 is probably correct. The vhook framework is deprecated but bug fixes are still accepted so please provide one patch in diff -Naur format for *all* the vhooks that set optind to zero. If no developer raises his voice against, I will apply it in a week. Regards, V?ctor
V?ctor Paesa wrote:
The vhook framework is deprecated but bug fixes are still accepted so please provide one patch in diff -Naur format for *all* the vhooks that set optind to zero.
If no developer raises his voice against, I will apply it in a week.
Hi Victor, thanks for your promptly reply. The only vhook that I could find such a problem was drawtext.c, so here it goes the patch as you requested for that file. I used the full checkout code from 2008-01-02 to create the patch. Btw, can you answer me a question? Why is vhook considered to be deprecated at this time if the substitute (libavfilter) is not stable yet? Wouldn't it make more sense to only mark vhook as deprecated after having a stable substitute? I'm just _asking_, I'm not suggesting anybody to change anything, I already got pretty bad comments here while just trying to help. Regards, Eduardo M. Bragatto.
Hello, On 02/01/2008, Eduardo M. Bragatto <eduardo at bragatto.com> wrote:
Btw, can you answer me a question? Why is vhook considered to be deprecated at this time if the substitute (libavfilter) is not stable yet? Wouldn't it make more sense to only mark vhook as deprecated after having a stable substitute?
As you said yourself, if code is existing, being distributed and needs fixing then it should be fixed even if it's going to be removed and I think that's reasonable. However, vhooks seems to be considered a poorly implemented filtering framework that is more of a bolt-on temporary solution for those that absolutely need it than anything that's intended to be significantly used or remain in the codebase in the long term. I'm mostly guessing here but this is the feel I get from the community. I get the feeling that vhooks was deprecated when it was implemented, it was just an easy way to do it at the time until a proper filter framework could be implemented.
I'm just _asking_, I'm not suggesting anybody to change anything, I already got pretty bad comments here while just trying to help.
I wasn't at all impolite to you in my initial response and I made the response so that you wouldn't think you were being ignored, but you proceeded to be rude to FFmpeg developers in general. If you received a bad comment, from my perspective, you provoked it. I was going to respond to your inflammatory e-mail but I refrained as I didn't see there being any gain in doing so. I would recommend you be more wary of insulting people who don't know you in future, especially if you're trying to get them to give some time to you. Anyway, vhooks isn't marked as deprecated, it's just considered deprecated as it is dirty and there is a shortly (hopefully) pending replacement. Regards, Rob
Hi, Eduardo M. Bragatto said:
V?ctor Paesa wrote:
The vhook framework is deprecated but bug fixes are still accepted so please provide one patch in diff -Naur format for *all* the vhooks that set optind to zero.
If no developer raises his voice against, I will apply it in a week.
Hi Victor,
thanks for your promptly reply. The only vhook that I could find such a problem was drawtext.c, so here it goes the patch as you requested for that file. I used the full checkout code from 2008-01-02 to create the patch.
I'd say there are more besides drawtext.c : $ grep 'optind.*=' *.c drawtext.c: optind = 0; fish.c: optind = 0; imlib2.c: optind = 0; watermark.c: optind = 1;
Btw, can you answer me a question? Why is vhook considered to be deprecated at this time if the substitute (libavfilter) is not stable yet? Wouldn't it make more sense to only mark vhook as deprecated after having a stable substitute?
Well, marking vhook as deprecated "motivates" people to start testing libavfilter, and then it will become stable sooner ... Regards, V?ctor
Hi, V?ctor Paesa wrote:
I'd say there are more besides drawtext.c :
$ grep 'optind.*=' *.c drawtext.c: optind = 0; fish.c: optind = 0; imlib2.c: optind = 0; watermark.c: optind = 1;
You're entirely right.. I did use the same grep command as you, but I'm a little bit sick today and didn't really paid attention to the other files (for some reason I thought 0 was OK and 1 was actually wrong). Here it goes the patch for fish.c, imlib2.c and drawtext.c. Regards, Eduardo M. Bragatto.
Hi, Eduardo M. Bragatto said:
Hi,
V?ctor Paesa wrote:
I'd say there are more besides drawtext.c :
$ grep 'optind.*=' *.c drawtext.c: optind = 0; fish.c: optind = 0; imlib2.c: optind = 0; watermark.c: optind = 1;
You're entirely right.. I did use the same grep command as you, but I'm
a little bit sick today and didn't really paid attention to the other files (for some reason I thought 0 was OK and 1 was actually wrong).
Here it goes the patch for fish.c, imlib2.c and drawtext.c.
This one looks OK. I'll apply it next Wednesday. By the way, there is no "drawtext" in libavfilter, so you are welcomed to submit a patch to add it ;-) Regards, V?ctor
Hi, V?ctor Paesa sai:
Hi,
Eduardo M. Bragatto said:
Hi,
V?ctor Paesa wrote:
I'd say there are more besides drawtext.c :
$ grep 'optind.*=' *.c drawtext.c: optind = 0; fish.c: optind = 0; imlib2.c: optind = 0; watermark.c: optind = 1;
You're entirely right.. I did use the same grep command as you, but I'm
a little bit sick today and didn't really paid attention to the other files (for some reason I thought 0 was OK and 1 was actually wrong).
Here it goes the patch for fish.c, imlib2.c and drawtext.c.
This one looks OK. I'll apply it next Wednesday. By the way, there is no "drawtext" in libavfilter, so you are welcomed to submit a patch to add it ;-)
Commited. Regards, V?ctor
participants (4)
-
eduardo＠bragatto.com -
melbournemark+ffmpeg＠gmail.com -
robert.swain＠gmail.com -
wzrlpy＠arsystel.com