[vlc-devel] Some requests - follow-up
Shelley Horwitz
shelley at sjcomm.com
Mon Jan 9 06:52:04 CET 2012
I have not seen any comments about my 3 requests:
1. To have bookmarks saved in a file so I may reuse them on subsequent viewings of video and movies.
2. To be able to name the bookmarks (like bookmarks in my browser).
3. To have a bookmark button in the controls so I don't have to go to the menu.
Any comments or opinions about the desirability of these features or priority for having them?
Shelley
________________________________
From: "vlc-devel-request at videolan.org" <vlc-devel-request at videolan.org>
To: vlc-devel at videolan.org
Sent: Sunday, January 8, 2012 7:04 AM
Subject: vlc-devel Digest, Vol 56, Issue 38
Send vlc-devel mailing list submissions to
vlc-devel at videolan.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.videolan.org/listinfo/vlc-devel
or, via email, send a message with subject or body 'help' to
vlc-devel-request at videolan.org
You can reach the person managing the list at
vlc-devel-owner at videolan.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vlc-devel digest..."
Today's Topics:
1. Re: vlc-devel Digest, Vol 56, Issue 37 (Shelley Horwitz)
2. Re: The case for 2.0 (Pierre Ynard)
3. Re: [PATCH] Avcodec: limit the number of threads
automatically selected to 12 (Jean-Baptiste Kempf)
4. Re: The case for 2.0 (Pierre Ynard)
----------------------------------------------------------------------
Message: 1
Date: Sun, 8 Jan 2012 05:17:45 -0800 (PST)
From: Shelley Horwitz <shelley at sjcomm.com>
To: "vlc-devel at videolan.org" <vlc-devel at videolan.org>
Subject: Re: [vlc-devel] vlc-devel Digest, Vol 56, Issue 37
Message-ID:
<1326028665.25084.YahooMailNeo at web83710.mail.sp1.yahoo.com>
Content-Type: text/plain; charset=iso-8859-1
Kaarlo,
I will try to remember to switch to plain text for all my messages. Thank you for the reminder.
Now... to our discussion. I do not want to make this a personal debate.... only to make VLC a better product in the world of players.
Even in volunteer organizations, and I have worked in several (Boy Scouts, Girl Scouts, for example), most people react well to goals, targets, and schedules. Actually, I believe the majority of people working on projects in volunteer organizations appreciate and work better in a scheduled environment. The schedule is NOT a threat, but a guide that helps them shape their work and pleasure hours to get the most out of their contributing energies. In my experience, a lot of people do not focus their minds and activities when they have no clear idea of when something is due. Because there is no "time-limit," there is no focus on performing a task. Because there is no time limit, there is no need to work today... there is all the time in the world to do it tomorrow. Everybody procrastinates when there is no well-defined finish line in sight. People don't procrastinate when they have a goal and a timeline... either given to them or they set it themselves.
With a roadmap and a project schedule, I believe exactly the reverse of what you suggest will happen! Volunteers will be happy to have a specific date to work with, they will welcome the schedule, and they will plan their own time and workload to MAKE IT HAPPEN. Every successful development environment I have ever worked in has always had a clear project plan and schedule with deadlines; the others have failed. That is fact... everything else is just someone's opinion. And this is just MHO.
________________________________
From: "vlc-devel-request at videolan.org" <vlc-devel-request at videolan.org>
To: vlc-devel at videolan.org
Sent: Sunday, January 8, 2012 4:29 AM
Subject: vlc-devel Digest, Vol 56, Issue 37
Send vlc-devel mailing list submissions to
??? vlc-devel at videolan.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.videolan.org/listinfo/vlc-devel
or, via email, send a message with subject or body 'help' to
??? vlc-devel-request at videolan.org
You can reach the person managing the list at
??? vlc-devel-owner at videolan.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vlc-devel digest..."
Today's Topics:
???1. Re: A respectful disagreement... (Kaarlo R?ih?)
----------------------------------------------------------------------
Message: 1
Date: Sun, 8 Jan 2012 14:29:45 +0200
From: Kaarlo R?ih? <kaarlo.raiha at gmail.com>
To: Mailing list for VLC media player developers
??? <vlc-devel at videolan.org>
Subject: Re: [vlc-devel] A respectful disagreement...
Message-ID:
??? <CAMKrNtzx0_wMscnORfzV8D0+8O9O-21XgRc-oqCe2VGqH48tkQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
2012/1/8 Shelley Horwitz <shelley at sjcomm.com>
> I respectfully disagree with Remi's point:
>
> "Feature-based versus time-based. The project history suggests that
> feature-
> based releases simply don't work because there is not enough commitment to
> finishing features, and time-based releases don't work because there is
> not
> enough commitment to stabilizing branches."
>
> I do not think there is any problem with either feature-based or
> time-based releases as long the development team agrees on what features
> will be included in each release and chooses a reasonable date for
> publishing that release. This is a planning and management issue.
> Professional developers look at requirements and priorities to define their
> workload to produce a schedule. The schedule is a target, and the target
> gives developers something to shoot at in making a commitment to finish
> on-time.
>
> A roadmap is the integration of feature-based and time-based releases. It
> is a PLAN... the studied, considered, reasonable, and organized way to
> accomplish product improvement. In fact, it eliminates all the adverse
> conditions that Remi raises. It recognizes necessary features, gives them
> appropriate priorities, assigns them to specific releases (and release
> dates), and gives developers strong motivation to produce good, working
> code in a reasonable timeframe.
>
> I cannot emphasize enough that this is what PROFESSIONAL developers do...
> this is the business of software development.
>
>
Please, don't use HTML emails in this mailing list, some people don't have
HTML enabled mail readers available 24/7.
And you are completely missing the point of volunteer vs. paid developers.
Since most people related to VLC development do this as a hobby, it isn't
feasible to make them work with any schedules or force them to do certain
features. Even current releases are stressful events because only few
people do release blocker bug fixing, and if someone would be forced to do
that, I think they would quit pretty fast.
IMHO roadmaps aren't useful if there isn't any guarantee for events in it
to happen. Bad/fake/broken promises are the cancer of software industry.
>
>???------------------------------
> *From:* "vlc-devel-request at videolan.org" <vlc-devel-request at videolan.org>
> *To:* vlc-devel at videolan.org
> *Sent:* Sunday, January 8, 2012 3:00 AM
> *Subject:* vlc-devel Digest, Vol 56, Issue 35
>
> Send vlc-devel mailing list submissions to
>? ? vlc-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>? ? http://mailman.videolan.org/listinfo/vlc-devel
> or, via email, send a message with subject or body 'help' to
>? ? vlc-devel-request at videolan.org
>
> You can reach the person managing the list at
>? ? vlc-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vlc-devel digest..."
>
>
> Today's Topics:
>
>???1. [PATCH] Allow for newer a52_init(void) call. take 2.
>? ? ???(Kelly Anderson)
>???2. Re: [PATCH] Fixed a crash caused by yadif deinterlacer on
>? ? ???Windows XP (Naohiro KORIYAMA)
>???3. Re: The case for 2.0 (John Freed)
>???4. Re: The case for 2.0 ( R?mi Denis-Courmont)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat,? 7 Jan 2012 21:47:27 -0700
> From: Kelly Anderson <kelly at silka.with-linux.com>
> To: vlc-devel at videolan.org
> Subject: [vlc-devel] [PATCH] Allow for newer a52_init(void) call. take
>? ???2.
> Message-ID:
>? ???<1325998047-4299-1-git-send-email-kelly at silka.with-linux.com>
>
> Fix compile with svn://svn.videolan.org/liba52/trunk.
>
> ---
> modules/audio_filter/converter/a52tofloat32.c |? ? 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/modules/audio_filter/converter/a52tofloat32.c
> b/modules/audio_filter/converter/a52tofloat32.c
> index 2980dd8..ec4a8f0 100644
> --- a/modules/audio_filter/converter/a52tofloat32.c
> +++ b/modules/audio_filter/converter/a52tofloat32.c
> @@ -205,7 +205,11 @@ static int Open( vlc_object_t *p_this, filter_sys_t
> *p_sys,
>? ???p_sys->i_flags |= A52_ADJUST_LEVEL;
>
>? ???/* Initialize liba52 */
> +#ifdef A52_ACCEL_DETECT
> +? ? p_sys->p_liba52 = a52_init();
> +#else
>? ???p_sys->p_liba52 = a52_init( 0 );
> +#endif
>? ???if( p_sys->p_liba52 == NULL )
>? ???{
>? ? ? ???msg_Err( p_this, "unable to initialize liba52" );
> --
> 1.7.8.3
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 8 Jan 2012 14:52:43 +0900
> From: Naohiro KORIYAMA <nkoriyama at gmail.com>
> To: Mailing list for VLC media player developers
>? ???<vlc-devel at videolan.org>
> Subject: Re: [vlc-devel] [PATCH] Fixed a crash caused by yadif
>? ???deinterlacer on Windows XP
> Message-ID:
>? ???<CAOa_K+sQay2ruGuK2JV0xMcsQfvZrWOUPuqTdiXEs61yhHsstw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The old patch, I sent to vlc-devel ML yesterday, didn't help the crash
> on Windows XP 32bit.
> I was wrong that I tested with the module that was compiled with a
> different patch.
>
> So I made a new patch and tested again
> (before applying old patch, after applying old patch, after applying
> new patch):
> - Windows XP 32bit using XP mode on Windows 7 (win32)
>???NG->NG->OK
> - Windows 7 64bit (win32/win64)
>???OK->OK->OK
> - Mac OS X Lion (intel64)
>???OK->OK->OK
> - Ubuntu 11.10 32bit using VirtualBox (32)
>???OK->OK->OK
> - Ubuntu 11.10 64bit using VirtualBox (64)
>???OK->OK->OK
>
> It's all OK with the new patch.
> But as jb mentioned on the ML few days ago, compiler warnings appear again
> on 32bit builds both Windows and Linux.
>
> --
> KORIYAMA, Naohiro
> nkoriyama at gmail.com
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-Fixed-a-crash-caused-by-yadif-on-Windows-XP-again-57.patch
> Type: application/octet-stream
> Size: 4741 bytes
> Desc: not available
> URL: <
> http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/f2dee75d/attachment-0001.obj
> >
>
> ------------------------------
>
> Message: 3
> Date: Sun, 8 Jan 2012 10:28:24 +0100
> From: John Freed <okvlc at johnfreed.com>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] The case for 2.0
> Message-ID:
>? ???<CAEVvu1PEz9PEkyx+yRVD3EojiY-L0UKw1YZzcTg6QZ_25JG3_A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Agree with Shelley's points, which go beyond the issue of 1.2 vs. 2.0. A
> roadmap with a target date for a 3.0 is definitely a marketing tool that
> provides an advantage to VLC beyond its quality and availability.
>
> >From a user perspective, a license change in and of itself would warrant a
> major version number. This affects not just how programmers interact with
> the product but also (potentially) the users themselves.
>
> I would also like to suggest adoption of a numbering system similar to the
> Linux kernel, to avoid the "pre-" and ".99" and such in the versions.
> Even-numbered minors are development branches; odd minors are released.
> Thus, the current development (Twoflowers) is 2.0, and when it's released
> it's 2.1. Rincewind would be 2.2, and the released version 2.3. (Or 3.0 and
> 3.1 if need be. On a side note, I generally associate new names, like
> Rincewind, with a major-version bump -- compare Ubuntu, Fedora, etc.) This
> has the advantage of never releasing ".0" versions, which as I have advised
> my clients in the past, should be avoided like the plague. :-)
>
>
>
> On Sun, Jan 8, 2012 at 5:27 AM, <vlc-devel-request at videolan.org> wrote:
> >
> >
> > Message: 5
> > Date: Sat, 7 Jan 2012 17:15:39 -0800 (PST)
> > From: Shelley Horwitz <shelley at sjcomm.com>
> > To: "vlc-devel at videolan.org" <vlc-devel at videolan.org>
> > Subject: Re: [vlc-devel] The case for 2.0
> > Message-ID:
> >? ? ? ? <1325985339.50472.YahooMailNeo at web83701.mail.sp1.yahoo.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > The reason for changing version numbers is as much a Marketing decision
> as
> > it is for features and functions. When versions do not change for a very
> > long time, users do not perceive any improvement in the product itself
> and
> > look for other "more modern" tools with better technology.
> >
> >
> > A good guideline for new versions is once every year. Some products go
> > every six months, some go every 1 1/2 years. A schedule of updates every
> > quarter, and a major release each year gives your users the idea that the
> > development team has a plan. The length of time is not as important as
> > consistency in updating and upgrading on a reasonable schedule. This is a
> > good example of a professional development environment, rather than a
> bunch
> > of hackers tinkering with a new toy.
> >
> >
> > Having such a schedule shows that you have a roadmap for developing your
> > software; it gives your users confidence that this product has a future
> > they can depend on. Continuous release of subversions only to fix
> problems
> > does exactly the reverse. It indicates that the program is going nowhere
> > and even after a long life, still has problems.
> >
> > This issue is about your customers PERCEPTION of the quality and
> longevity
> > of VLC; it is not about how much or how little changes. It is what your
> > users see about the future of VLC. It is what they believe, not about
> what
> > you change.
> >
> > It is time for VLC 2.0. It is time to start planning for all future
> > releases and updates for VLC. It is time to set goals and targets. It is
> > time to develop a ROADMAP!!! It is time to show both your users and your
> > developers that VLC has a future.
> >
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/01d4fb83/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 8 Jan 2012 11:52:34 +0200
> From: " R?mi Denis-Courmont" <remi at remlab.net>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] The case for 2.0
> Message-ID: <201201081152.34814.remi at remlab.net>
> Content-Type: Text/Plain;? charset="iso-8859-1"
>
> Le dimanche 8 janvier 2012 02:15:48 Pierre Ynard, vous avez ?crit :
> > So now we're not talking about just the next release, but all majors
> > releases from now on. Will all following releases bring as many features
> > as Twoflower, and be way beyond and different from the previous one, and
> > feature a license change, to warrant the same number bump?
>
> The current development process has three levels of release (major
> releases,
> bugfix releases and repackaging), yet the versioning scheme has four
> (major
> number, minor number, revision number and optional packaging letter). This
> is
> inconsistent, and that is why this is not the first time we debate whether
> to
> increment the major version or the minor one.
>
> Unless someone has a better idea on how to use the major version number, I
> think it would make sense to use it for stable branches / major release /
> whatever-you-want-to-call-them.
>
> (...)
> > Rather than trying to pin landmarks on an empty timeline, it would be
> > better to plan what big features we want in the next version. The fact
> > that this an opensource project driven by volunteers doesn't mean that
> > we can't at least try to do this.
>
> Feature-based versus time-based. The project history suggests that feature-
> based releases simply don't work because there is not enough commitment to
> finishing features, and time-based releases don't work because there is
> not
> enough commitment to stabilizing branches.
>
> So unless one of you turns into a VLCtropic billionaire, this is screwed
> either way.
>
> --
> R?mi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>
>
> ------------------------------
>
> _______________________________________________
> vlc-devel mailing list
> vlc-devel at videolan.org
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
> End of vlc-devel Digest, Vol 56, Issue 35
> *****************************************
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/52ff0cf7/attachment.html>
------------------------------
_______________________________________________
vlc-devel mailing list
vlc-devel at videolan.org
http://mailman.videolan.org/listinfo/vlc-devel
End of vlc-devel Digest, Vol 56, Issue 37
*****************************************???
------------------------------
Message: 2
Date: Sun, 8 Jan 2012 15:47:02 +0100
From: Pierre Ynard <linkfanel at yahoo.fr>
To: vlc-devel at videolan.org
Subject: Re: [vlc-devel] The case for 2.0
Message-ID: <20120108144702.GA8552 at via.ecp.fr>
Content-Type: text/plain; charset=iso-8859-1
> The current development process has three levels of release (major
> releases, bugfix releases and repackaging), yet the versioning scheme
> has four (major number, minor number, revision number and optional
> packaging letter). This is inconsistent, and that is why this is not
> the first time we debate whether to increment the major version or the
> minor one.
>
> Unless someone has a better idea on how to use the major version
> number, I think it would make sense to use it for stable branches /
> major release / whatever-you-want-to-call-them.
We could use the major versions for important amounts of changes like in
Twoflower. And not use them for releases that are just yet another bunch
of small improvements and additions to the codec list.
> Feature-based versus time-based. The project history suggests that
> feature-based releases simply don't work because there is not enough
> commitment to finishing features, and time-based releases don't work
> because there is not enough commitment to stabilizing branches.
>
> So unless one of you turns into a VLCtropic billionaire, this is
> screwed either way.
Alright, you convinced me, this is doomed so I give up on the project,
it's only logical.
--
Pierre Ynard
"Une ?me dans un corps, c'est comme un dessin sur une feuille de papier."
------------------------------
Message: 3
Date: Sun, 8 Jan 2012 15:48:29 +0100
From: Jean-Baptiste Kempf <jb at videolan.org>
To: Mailing list for VLC media player developers
<vlc-devel at videolan.org>
Subject: Re: [vlc-devel] [PATCH] Avcodec: limit the number of threads
automatically selected to 12
Message-ID: <20120108144829.GA25989 at videolan.org>
Content-Type: text/plain; charset=iso-8859-1
On Thu, Jan 05, 2012 at 10:12:24AM +0100, Denis Charmet wrote :
> Le mardi 03 janvier 2012 ? 11:41:09, Laurent Aimar a ?crit :
> > The value should be the dpb_size of the H264 streams (1-16, it depends
> > on the way the stream was created) + number of threads + a small value
> > (it depends on the way ffmpeg works and/or the way we use it, in my last
> > test it seems that 2 was good enough).
> >
>
> Wouldn't it be cleaner instead of freeing the oldest image in the pool
> to dynamically increase the pool if needed by vlc_get_cpu_count(),
> at least a limited number of times and then start the vout_FixLeak
> function?
What is the status of this?
Best,
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
------------------------------
Message: 4
Date: Sun, 8 Jan 2012 16:05:07 +0100
From: Pierre Ynard <linkfanel at yahoo.fr>
To: vlc-devel at videolan.org
Subject: Re: [vlc-devel] The case for 2.0
Message-ID: <20120108150507.GA8765 at via.ecp.fr>
Content-Type: text/plain; charset=iso-8859-1
> Having such a schedule shows that you have a roadmap for developing
> your software; it gives your users confidence that this product has a
> future they can depend on. Continuous release of subversions only to
> fix problems does exactly the reverse. It indicates that the program
> is going nowhere and even after a long life, still has problems.
>
> This issue is about your customers PERCEPTION of the quality and
> longevity of VLC; it is not about how much or how little changes.
> It is what your users see about the future of VLC. It is what they
> believe, not about what you change.
<sarcasm>But the project actually doesn't have a dependable
future.</sarcasm> And it's in our open-source culture not to deceive our
users, so you understand that we can't just lie to them and make them
believe all the good things you're talking about.
> It is time for VLC 2.0. It is time to start planning for all future
> releases and updates for VLC. It is time to set goals and targets. It is
> time to develop a ROADMAP!!! It is time to show both your users and your
> developers that VLC has a future.
Already two key developers don't intend on doing that unless we
magically get big funding. So what do you say now?
--
Pierre Ynard
"Une ?me dans un corps, c'est comme un dessin sur une feuille de papier."
------------------------------
_______________________________________________
vlc-devel mailing list
vlc-devel at videolan.org
http://mailman.videolan.org/listinfo/vlc-devel
End of vlc-devel Digest, Vol 56, Issue 38
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/93a5ea70/attachment.html>
More information about the vlc-devel
mailing list