<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:18pt"><div><span>I have not seen any comments about my 3 requests:</span></div><div><br><span></span></div><div>1. To have bookmarks saved in a file so I may reuse them on subsequent viewings of video and movies.</div><div>2. To be able to name the bookmarks (like bookmarks in my browser).</div><div>3. To have a bookmark button in the controls so I don't have to go to the menu.</div><div><br></div><div>Any comments or opinions about the desirability of these features or priority for having them?</div><div><br></div><div>Shelley<br><span></span></div><div><br></div>  <div style="font-family: times new roman, new york, times, serif; font-size: 18pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <font face="Arial" size="2"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b>

 "vlc-devel-request@videolan.org" <vlc-devel-request@videolan.org><br> <b><span style="font-weight: bold;">To:</span></b> vlc-devel@videolan.org <br> <b><span style="font-weight: bold;">Sent:</span></b> Sunday, January 8, 2012 7:04 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> vlc-devel Digest, Vol 56, Issue 38<br> </font> <br>Send vlc-devel mailing list submissions to<br>    <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>    <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>or, via email, send a message with subject or body 'help' to<br>    <a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a><br><br>You can

 reach the person managing the list at<br>    <a ymailto="mailto:vlc-devel-owner@videolan.org" href="mailto:vlc-devel-owner@videolan.org">vlc-devel-owner@videolan.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of vlc-devel digest..."<br><br><br>Today's Topics:<br><br>   1. Re: vlc-devel Digest, Vol 56, Issue 37 (Shelley Horwitz)<br>   2. Re: The case for 2.0 (Pierre Ynard)<br>   3. Re: [PATCH] Avcodec: limit the number of threads<br>      automatically selected to 12 (Jean-Baptiste Kempf)<br>   4. Re: The case for 2.0 (Pierre Ynard)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 8 Jan 2012 05:17:45 -0800 (PST)<br>From: Shelley Horwitz <<a ymailto="mailto:shelley@sjcomm.com" href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>><br>To: "<a

 ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>" <<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>Subject: Re: [vlc-devel] vlc-devel Digest, Vol 56, Issue 37<br>Message-ID:<br>    <<a ymailto="mailto:1326028665.25084.YahooMailNeo@web83710.mail.sp1.yahoo.com" href="mailto:1326028665.25084.YahooMailNeo@web83710.mail.sp1.yahoo.com">1326028665.25084.YahooMailNeo@web83710.mail.sp1.yahoo.com</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>Kaarlo,<br><br>I will try to remember to switch to plain text for all my messages. Thank you for the reminder.<br><br>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.<br><br>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.<br><br><br><br><br>________________________________<br>From: "<a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>" <<a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>><br>To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a> <br>Sent: Sunday, January 8, 2012 4:29 AM<br>Subject: vlc-devel Digest, Vol 56, Issue 37<br><br>Send vlc-devel mailing list

 submissions to<br>??? <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>or, via email, send a message with subject or body 'help' to<br>??? <a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a><br><br>You can reach the person managing the list at<br>??? <a ymailto="mailto:vlc-devel-owner@videolan.org" href="mailto:vlc-devel-owner@videolan.org">vlc-devel-owner@videolan.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of vlc-devel digest..."<br><br><br>Today's Topics:<br><br>???1. Re: A respectful disagreement... (Kaarlo

 R?ih?)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 8 Jan 2012 14:29:45 +0200<br>From: Kaarlo R?ih? <<a ymailto="mailto:kaarlo.raiha@gmail.com" href="mailto:kaarlo.raiha@gmail.com">kaarlo.raiha@gmail.com</a>><br>To: Mailing list for VLC media player developers<br>??? <<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>Subject: Re: [vlc-devel] A respectful disagreement...<br>Message-ID:<br>??? <CAMKrNtzx0_wMscnORfzV8D0+<a ymailto="mailto:8O9O-21XgRc-oqCe2VGqH48tkQ@mail.gmail.com" href="mailto:8O9O-21XgRc-oqCe2VGqH48tkQ@mail.gmail.com">8O9O-21XgRc-oqCe2VGqH48tkQ@mail.gmail.com</a>><br>Content-Type: text/plain; charset="iso-8859-1"<br><br>2012/1/8 Shelley Horwitz <<a ymailto="mailto:shelley@sjcomm.com" href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>><br><br>> I respectfully disagree with Remi's

 point:<br>><br>> "Feature-based versus time-based. The project history suggests that<br>> feature-<br>> based releases simply don't work because there is not enough commitment to<br>> finishing features, and time-based releases don't work because there is<br>> not<br>> enough commitment to stabilizing branches."<br>><br>> I do not think there is any problem with either feature-based or<br>> time-based releases as long the development team agrees on what features<br>> will be included in each release and chooses a reasonable date for<br>> publishing that release. This is a planning and management issue.<br>> Professional developers look at requirements and priorities to define their<br>> workload to produce a schedule. The schedule is a target, and the target<br>> gives developers something to shoot at in making a commitment to finish<br>> on-time.<br>><br>> A roadmap is the integration of

 feature-based and time-based releases. It<br>> is a PLAN... the studied, considered, reasonable, and organized way to<br>> accomplish product improvement. In fact, it eliminates all the adverse<br>> conditions that Remi raises. It recognizes necessary features, gives them<br>> appropriate priorities, assigns them to specific releases (and release<br>> dates), and gives developers strong motivation to produce good, working<br>> code in a reasonable timeframe.<br>><br>> I cannot emphasize enough that this is what PROFESSIONAL developers do...<br>> this is the business of software development.<br>><br>><br>Please, don't use HTML emails in this mailing list, some people don't have<br>HTML enabled mail readers available 24/7.<br><br>And you are completely missing the point of volunteer vs. paid developers.<br>Since most people related to VLC development do this as a hobby, it isn't<br>feasible to make them work with any

 schedules or force them to do certain<br>features. Even current releases are stressful events because only few<br>people do release blocker bug fixing, and if someone would be forced to do<br>that, I think they would quit pretty fast.<br><br>IMHO roadmaps aren't useful if there isn't any guarantee for events in it<br>to happen. Bad/fake/broken promises are the cancer of software industry.<br><br><br><br>><br>>???------------------------------<br>> *From:* "<a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>" <<a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>><br>> *To:* <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>> *Sent:* Sunday, January 8, 2012 3:00 AM<br>> *Subject:* vlc-devel Digest, Vol 56, Issue

 35<br>><br>> Send vlc-devel mailing list submissions to<br>>? ? <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>><br>> To subscribe or unsubscribe via the World Wide Web, visit<br>>? ? <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>> or, via email, send a message with subject or body 'help' to<br>>? ? <a ymailto="mailto:vlc-devel-request@videolan.org" href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a><br>><br>> You can reach the person managing the list at<br>>? ? <a ymailto="mailto:vlc-devel-owner@videolan.org" href="mailto:vlc-devel-owner@videolan.org">vlc-devel-owner@videolan.org</a><br>><br>> When replying, please edit your Subject line so it is more specific<br>> than "Re: Contents of vlc-devel digest..."<br>><br>><br>> Today's

 Topics:<br>><br>>???1. [PATCH] Allow for newer a52_init(void) call. take 2.<br>>? ? ???(Kelly Anderson)<br>>???2. Re: [PATCH] Fixed a crash caused by yadif deinterlacer on<br>>? ? ???Windows XP (Naohiro KORIYAMA)<br>>???3. Re: The case for 2.0 (John Freed)<br>>???4. Re: The case for 2.0 ( R?mi Denis-Courmont)<br>><br>><br>> ----------------------------------------------------------------------<br>><br>> Message: 1<br>> Date: Sat,? 7 Jan 2012 21:47:27 -0700<br>> From: Kelly Anderson <<a ymailto="mailto:kelly@silka.with-linux.com" href="mailto:kelly@silka.with-linux.com">kelly@silka.with-linux.com</a>><br>> To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>> Subject: [vlc-devel] [PATCH] Allow for newer a52_init(void) call. take<br>>? ???2.<br>> Message-ID:<br>>? ???<<a

 ymailto="mailto:1325998047-4299-1-git-send-email-kelly@silka.with-linux.com" href="mailto:1325998047-4299-1-git-send-email-kelly@silka.with-linux.com">1325998047-4299-1-git-send-email-kelly@silka.with-linux.com</a>><br>><br>> Fix compile with svn://svn.videolan.org/liba52/trunk.<br>><br>> ---<br>> modules/audio_filter/converter/a52tofloat32.c |? ? 4 ++++<br>> 1 files changed, 4 insertions(+), 0 deletions(-)<br>><br>> diff --git a/modules/audio_filter/converter/a52tofloat32.c<br>> b/modules/audio_filter/converter/a52tofloat32.c<br>> index 2980dd8..ec4a8f0 100644<br>> --- a/modules/audio_filter/converter/a52tofloat32.c<br>> +++ b/modules/audio_filter/converter/a52tofloat32.c<br>> @@ -205,7 +205,11 @@ static int Open( vlc_object_t *p_this, filter_sys_t<br>> *p_sys,<br>>? ???p_sys->i_flags |= A52_ADJUST_LEVEL;<br>><br>>? ???/* Initialize liba52 */<br>> +#ifdef A52_ACCEL_DETECT<br>> +? ?

 p_sys->p_liba52 = a52_init();<br>> +#else<br>>? ???p_sys->p_liba52 = a52_init( 0 );<br>> +#endif<br>>? ???if( p_sys->p_liba52 == NULL )<br>>? ???{<br>>? ? ? ???msg_Err( p_this, "unable to initialize liba52" );<br>> --<br>> 1.7.8.3<br>><br>><br>><br>> ------------------------------<br>><br>> Message: 2<br>> Date: Sun, 8 Jan 2012 14:52:43 +0900<br>> From: Naohiro KORIYAMA <<a ymailto="mailto:nkoriyama@gmail.com" href="mailto:nkoriyama@gmail.com">nkoriyama@gmail.com</a>><br>> To: Mailing list for VLC media player developers<br>>? ???<<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>> Subject: Re: [vlc-devel] [PATCH] Fixed a crash caused by yadif<br>>? ???deinterlacer on Windows XP<br>> Message-ID:<br>>? ???<CAOa_K+<a ymailto="mailto:sQay2ruGuK2JV0xMcsQfvZrWOUPuqTdiXEs61yhHsstw@mail.gmail.com"

 href="mailto:sQay2ruGuK2JV0xMcsQfvZrWOUPuqTdiXEs61yhHsstw@mail.gmail.com">sQay2ruGuK2JV0xMcsQfvZrWOUPuqTdiXEs61yhHsstw@mail.gmail.com</a>><br>> Content-Type: text/plain; charset="iso-8859-1"<br>><br>> The old patch, I sent to vlc-devel ML yesterday, didn't help the crash<br>> on Windows XP 32bit.<br>> I was wrong that I tested with the module that was compiled with a<br>> different patch.<br>><br>> So I made a new patch and tested again<br>> (before applying old patch, after applying old patch, after applying<br>> new patch):<br>> - Windows XP 32bit using XP mode on Windows 7 (win32)<br>>???NG->NG->OK<br>> - Windows 7 64bit (win32/win64)<br>>???OK->OK->OK<br>> - Mac OS X Lion (intel64)<br>>???OK->OK->OK<br>> - Ubuntu 11.10 32bit using VirtualBox (32)<br>>???OK->OK->OK<br>> - Ubuntu 11.10 64bit using VirtualBox (64)<br>>???OK->OK->OK<br>><br>> It's all OK

 with the new patch.<br>> But as jb mentioned on the ML few days ago, compiler warnings appear again<br>> on 32bit builds both Windows and Linux.<br>><br>> --<br>> KORIYAMA, Naohiro<br>> <a ymailto="mailto:nkoriyama@gmail.com" href="mailto:nkoriyama@gmail.com">nkoriyama@gmail.com</a><br>> -------------- next part --------------<br>> A non-text attachment was scrubbed...<br>> Name: 0001-Fixed-a-crash-caused-by-yadif-on-Windows-XP-again-57.patch<br>> Type: application/octet-stream<br>> Size: 4741 bytes<br>> Desc: not available<br>> URL: <<br>> <a href="http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/f2dee75d/attachment-0001.obj" target="_blank">http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/f2dee75d/attachment-0001.obj</a><br>> ><br>><br>> ------------------------------<br>><br>> Message: 3<br>> Date: Sun, 8 Jan 2012 10:28:24 +0100<br>> From:

 John Freed <<a ymailto="mailto:okvlc@johnfreed.com" href="mailto:okvlc@johnfreed.com">okvlc@johnfreed.com</a>><br>> To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>> Subject: Re: [vlc-devel] The case for 2.0<br>> Message-ID:<br>>? ???<CAEVvu1PEz9PEkyx+<a ymailto="mailto:yRVD3EojiY-L0UKw1YZzcTg6QZ_25JG3_A@mail.gmail.com" href="mailto:yRVD3EojiY-L0UKw1YZzcTg6QZ_25JG3_A@mail.gmail.com">yRVD3EojiY-L0UKw1YZzcTg6QZ_25JG3_A@mail.gmail.com</a>><br>> Content-Type: text/plain; charset="utf-8"<br>><br>> Agree with Shelley's points, which go beyond the issue of 1.2 vs. 2.0. A<br>> roadmap with a target date for a 3.0 is definitely a marketing tool that<br>> provides an advantage to VLC beyond its quality and availability.<br>><br>> >From a user perspective, a license change in and of itself would warrant a<br>> major version number. This affects not

 just how programmers interact with<br>> the product but also (potentially) the users themselves.<br>><br>> I would also like to suggest adoption of a numbering system similar to the<br>> Linux kernel, to avoid the "pre-" and ".99" and such in the versions.<br>> Even-numbered minors are development branches; odd minors are released.<br>> Thus, the current development (Twoflowers) is 2.0, and when it's released<br>> it's 2.1. Rincewind would be 2.2, and the released version 2.3. (Or 3.0 and<br>> 3.1 if need be. On a side note, I generally associate new names, like<br>> Rincewind, with a major-version bump -- compare Ubuntu, Fedora, etc.) This<br>> has the advantage of never releasing ".0" versions, which as I have advised<br>> my clients in the past, should be avoided like the plague. :-)<br>><br>><br>><br>> On Sun, Jan 8, 2012 at 5:27 AM, <<a ymailto="mailto:vlc-devel-request@videolan.org"

 href="mailto:vlc-devel-request@videolan.org">vlc-devel-request@videolan.org</a>> wrote:<br>> ><br>> ><br>> > Message: 5<br>> > Date: Sat, 7 Jan 2012 17:15:39 -0800 (PST)<br>> > From: Shelley Horwitz <<a ymailto="mailto:shelley@sjcomm.com" href="mailto:shelley@sjcomm.com">shelley@sjcomm.com</a>><br>> > To: "<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>" <<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>> > Subject: Re: [vlc-devel] The case for 2.0<br>> > Message-ID:<br>> >? ? ? ? <<a ymailto="mailto:1325985339.50472.YahooMailNeo@web83701.mail.sp1.yahoo.com" href="mailto:1325985339.50472.YahooMailNeo@web83701.mail.sp1.yahoo.com">1325985339.50472.YahooMailNeo@web83701.mail.sp1.yahoo.com</a>><br>> > Content-Type: text/plain; charset="us-ascii"<br>>

 ><br>> > The reason for changing version numbers is as much a Marketing decision<br>> as<br>> > it is for features and functions. When versions do not change for a very<br>> > long time, users do not perceive any improvement in the product itself<br>> and<br>> > look for other "more modern" tools with better technology.<br>> ><br>> ><br>> > A good guideline for new versions is once every year. Some products go<br>> > every six months, some go every 1 1/2 years. A schedule of updates every<br>> > quarter, and a major release each year gives your users the idea that the<br>> > development team has a plan. The length of time is not as important as<br>> > consistency in updating and upgrading on a reasonable schedule. This is a<br>> > good example of a professional development environment, rather than a<br>> bunch<br>> > of hackers tinkering with a new toy.<br>>

 ><br>> ><br>> > Having such a schedule shows that you have a roadmap for developing your<br>> > software; it gives your users confidence that this product has a future<br>> > they can depend on. Continuous release of subversions only to fix<br>> problems<br>> > does exactly the reverse. It indicates that the program is going nowhere<br>> > and even after a long life, still has problems.<br>> ><br>> > This issue is about your customers PERCEPTION of the quality and<br>> longevity<br>> > of VLC; it is not about how much or how little changes. It is what your<br>> > users see about the future of VLC. It is what they believe, not about<br>> what<br>> > you change.<br>> ><br>> > It is time for VLC 2.0. It is time to start planning for all future<br>> > releases and updates for VLC. It is time to set goals and targets. It is<br>> > time to develop a

 ROADMAP!!! It is time to show both your users and your<br>> > developers that VLC has a future.<br>> ><br>> ><br>> ><br>> ><br>> -------------- next part --------------<br>> An HTML attachment was scrubbed...<br>> URL: <<br>> <a href="http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/01d4fb83/attachment-0001.html" target="_blank">http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/01d4fb83/attachment-0001.html</a><br>> ><br>><br>> ------------------------------<br>><br>> Message: 4<br>> Date: Sun, 8 Jan 2012 11:52:34 +0200<br>> From: " R?mi Denis-Courmont" <<a ymailto="mailto:remi@remlab.net" href="mailto:remi@remlab.net">remi@remlab.net</a>><br>> To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>> Subject: Re: [vlc-devel] The case for 2.0<br>> Message-ID: <<a

 ymailto="mailto:201201081152.34814.remi@remlab.net" href="mailto:201201081152.34814.remi@remlab.net">201201081152.34814.remi@remlab.net</a>><br>> Content-Type: Text/Plain;? charset="iso-8859-1"<br>><br>> Le dimanche 8 janvier 2012 02:15:48 Pierre Ynard, vous avez ?crit :<br>> > So now we're not talking about just the next release, but all majors<br>> > releases from now on. Will all following releases bring as many features<br>> > as Twoflower, and be way beyond and different from the previous one, and<br>> > feature a license change, to warrant the same number bump?<br>><br>> The current development process has three levels of release (major<br>> releases,<br>> bugfix releases and repackaging), yet the versioning scheme has four<br>> (major<br>> number, minor number, revision number and optional packaging letter). This<br>> is<br>> inconsistent, and that is why this is not the first time we

 debate whether<br>> to<br>> increment the major version or the minor one.<br>><br>> Unless someone has a better idea on how to use the major version number, I<br>> think it would make sense to use it for stable branches / major release /<br>> whatever-you-want-to-call-them.<br>><br>> (...)<br>> > Rather than trying to pin landmarks on an empty timeline, it would be<br>> > better to plan what big features we want in the next version. The fact<br>> > that this an opensource project driven by volunteers doesn't mean that<br>> > we can't at least try to do this.<br>><br>> Feature-based versus time-based. The project history suggests that feature-<br>> based releases simply don't work because there is not enough commitment to<br>> finishing features, and time-based releases don't work because there is<br>> not<br>> enough commitment to stabilizing branches.<br>><br>> So unless one of you

 turns into a VLCtropic billionaire, this is screwed<br>> either way.<br>><br>> --<br>> R?mi Denis-Courmont<br>> <a href="http://www.remlab.net/" target="_blank">http://www.remlab.net/</a><br>> <a href="http://fi.linkedin.com/in/remidenis" target="_blank">http://fi.linkedin.com/in/remidenis</a><br>><br>><br>> ------------------------------<br>><br>> _______________________________________________<br>> vlc-devel mailing list<br>> <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>> <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>><br>><br>> End of vlc-devel Digest, Vol 56, Issue 35<br>> *****************************************<br>><br>><br>><br>> _______________________________________________<br>> vlc-devel mailing list<br>> To unsubscribe or

modify your subscription options: > <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <<a href="http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/52ff0cf7/attachment.html" target="_blank">http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120108/52ff0cf7/attachment.html</a>> ------------------------------ _______________________________________________ vlc-devel mailing list <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a> <a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a> End of vlc-devel Digest, Vol 56, Issue 37 *****************************************???

 <br><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 8 Jan 2012 15:47:02 +0100<br>From: Pierre Ynard <<a ymailto="mailto:linkfanel@yahoo.fr" href="mailto:linkfanel@yahoo.fr">linkfanel@yahoo.fr</a>><br>To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>Subject: Re: [vlc-devel] The case for 2.0<br>Message-ID: <<a ymailto="mailto:20120108144702.GA8552@via.ecp.fr" href="mailto:20120108144702.GA8552@via.ecp.fr">20120108144702.GA8552@via.ecp.fr</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>> The current development process has three levels of release (major<br>> releases, bugfix releases and repackaging), yet the versioning scheme<br>> has four (major number, minor number, revision number and optional<br>> packaging letter). This is inconsistent, and that is why this is not<br>> the first time we debate whether to increment the major

 version or the<br>> minor one.<br>> <br>> Unless someone has a better idea on how to use the major version<br>> number, I think it would make sense to use it for stable branches /<br>> major release / whatever-you-want-to-call-them.<br><br>We could use the major versions for important amounts of changes like in<br>Twoflower. And not use them for releases that are just yet another bunch<br>of small improvements and additions to the codec list.<br><br>> Feature-based versus time-based. The project history suggests that<br>> feature-based releases simply don't work because there is not enough<br>> commitment to finishing features, and time-based releases don't work<br>> because there is not enough commitment to stabilizing branches.<br>> <br>> So unless one of you turns into a VLCtropic billionaire, this is<br>> screwed either way.<br><br>Alright, you convinced me, this is doomed so I give up on the project,<br>it's only

 logical.<br><br>-- <br>Pierre Ynard<br>"Une ?me dans un corps, c'est comme un dessin sur une feuille de papier."<br><br><br>------------------------------<br><br>Message: 3<br>Date: Sun, 8 Jan 2012 15:48:29 +0100<br>From: Jean-Baptiste Kempf <<a ymailto="mailto:jb@videolan.org" href="mailto:jb@videolan.org">jb@videolan.org</a>><br>To: Mailing list for VLC media player developers<br>    <<a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a>><br>Subject: Re: [vlc-devel] [PATCH] Avcodec: limit the number of threads<br>    automatically selected to 12<br>Message-ID: <<a ymailto="mailto:20120108144829.GA25989@videolan.org" href="mailto:20120108144829.GA25989@videolan.org">20120108144829.GA25989@videolan.org</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>On Thu, Jan 05, 2012 at 10:12:24AM +0100, Denis Charmet wrote :<br>> Le mardi 03 janvier

 2012 ? 11:41:09, Laurent Aimar a ?crit :<br>> >  The value should be the dpb_size of the H264 streams (1-16, it depends<br>> > on the way the stream was created) + number of threads + a small value<br>> > (it depends on the way ffmpeg works and/or the way we use it, in my last<br>> > test it seems that 2 was good enough).<br>> > <br>> <br>> Wouldn't it be cleaner instead of freeing the oldest image in the pool<br>> to dynamically increase the pool if needed by vlc_get_cpu_count(),<br>> at least a limited number of times and then start the vout_FixLeak<br>> function?<br><br>What is the status of this?<br><br>Best,<br><br>-- <br>Jean-Baptiste Kempf<br><a href="http://www.jbkempf.com/" target="_blank">http://www.jbkempf.com/</a> - +33 672 704 734<br>Sent from my Electronic Device<br><br><br>------------------------------<br><br>Message: 4<br>Date: Sun, 8 Jan 2012 16:05:07 +0100<br>From: Pierre Ynard <<a

 ymailto="mailto:linkfanel@yahoo.fr" href="mailto:linkfanel@yahoo.fr">linkfanel@yahoo.fr</a>><br>To: <a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br>Subject: Re: [vlc-devel] The case for 2.0<br>Message-ID: <<a ymailto="mailto:20120108150507.GA8765@via.ecp.fr" href="mailto:20120108150507.GA8765@via.ecp.fr">20120108150507.GA8765@via.ecp.fr</a>><br>Content-Type: text/plain; charset=iso-8859-1<br><br>> Having such a schedule shows that you have a roadmap for developing<br>> your software; it gives your users confidence that this product has a<br>> future they can depend on. Continuous release of subversions only to<br>> fix problems does exactly the reverse. It indicates that the program<br>> is going nowhere and even after a long life, still has problems.<br>> <br>> This issue is about your customers PERCEPTION of the quality and<br>> longevity of VLC; it is not

 about how much or how little changes.<br>> It is what your users see about the future of VLC. It is what they<br>> believe, not about what you change.<br><br><sarcasm>But the project actually doesn't have a dependable<br>future.</sarcasm> And it's in our open-source culture not to deceive our<br>users, so you understand that we can't just lie to them and make them<br>believe all the good things you're talking about.<br><br>> It is time for VLC 2.0. It is time to start planning for all future<br>> releases and updates for VLC. It is time to set goals and targets. It is<br>> time to develop a ROADMAP!!! It is time to show both your users and your<br>> developers that VLC has a future.<br><br>Already two key developers don't intend on doing that unless we<br>magically get big funding. So what do you say now?<br><br>-- <br>Pierre Ynard<br>"Une ?me dans un corps, c'est comme un dessin sur une feuille de

 papier."<br><br><br>------------------------------<br><br>_______________________________________________<br>vlc-devel mailing list<br><a ymailto="mailto:vlc-devel@videolan.org" href="mailto:vlc-devel@videolan.org">vlc-devel@videolan.org</a><br><a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br><br><br>End of vlc-devel Digest, Vol 56, Issue 38<br>*****************************************<br><br><br> </div> </div>  </div></body></html>