Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(36) |
Feb
(6) |
Mar
(1) |
Apr
(6) |
May
(19) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(6) |
Dec
(5) |
| 2007 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
|
Nov
(5) |
Dec
(32) |
| 2008 |
Jan
|
Feb
(14) |
Mar
(15) |
Apr
(18) |
May
(3) |
Jun
(12) |
Jul
(22) |
Aug
(7) |
Sep
(11) |
Oct
(55) |
Nov
(38) |
Dec
(11) |
| 2009 |
Jan
(68) |
Feb
(2) |
Mar
(7) |
Apr
(8) |
May
(13) |
Jun
(5) |
Jul
(3) |
Aug
(7) |
Sep
(2) |
Oct
(12) |
Nov
|
Dec
(6) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
(50) |
Apr
(5) |
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
|
Oct
(7) |
Nov
(7) |
Dec
(3) |
| 2011 |
Jan
(4) |
Feb
(9) |
Mar
(10) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(3) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
|
2
|
3
(2) |
4
(7) |
5
(3) |
6
(2) |
|
7
(3) |
8
(3) |
9
|
10
(6) |
11
(2) |
12
|
13
|
|
14
|
15
(1) |
16
(2) |
17
(2) |
18
(2) |
19
(9) |
20
(2) |
|
21
(1) |
22
|
23
|
24
|
25
|
26
(1) |
27
|
|
28
|
29
|
30
(2) |
31
|
|
|
|
|
From: Fabian Deutsch <fabian.deutsch@gm...> - 2010-03-30 08:58:28
|
Am Dienstag, den 30.03.2010, 02:36 -0400 schrieb David Schleef: > On Fri, Mar 26, 2010 at 09:27:00AM +0100, Fabian Deutsch wrote: > > Hello, > > > > when building orc for Fedora, we recognized that the size of liborc > > exceeds the size give in the README [1]. Is this normal and just a > > not-so-up-to-date README, or an abnormal growth? > > The 100 kB size is only meant for embedded development, which only > includes one backend. Right now, you can only get that by patching > the source. A more realistic size for all backends plus the parser > is about 300 kB. Okay. > > Another note was, that one test is failing on an AMD64 arch (but running > > fine on x86_64). Are there known issues with AMD64 or is there something > > wrong on our side? > > This is fixed in today's release. > http://code.entropywave.com/2010/03/orc-0-4-4-released/ Thanks, for fixing this :) - fabian |
|
From: David Schleef <ds@en...> - 2010-03-30 06:37:33
|
On Fri, Mar 26, 2010 at 09:27:00AM +0100, Fabian Deutsch wrote: > Hello, > > when building orc for Fedora, we recognized that the size of liborc > exceeds the size give in the README [1]. Is this normal and just a > not-so-up-to-date README, or an abnormal growth? The 100 kB size is only meant for embedded development, which only includes one backend. Right now, you can only get that by patching the source. A more realistic size for all backends plus the parser is about 300 kB. > Another note was, that one test is failing on an AMD64 arch (but running > fine on x86_64). Are there known issues with AMD64 or is there something > wrong on our side? This is fixed in today's release. http://code.entropywave.com/2010/03/orc-0-4-4-released/ dave... |
|
From: Fabian Deutsch <fabian.deutsch@gm...> - 2010-03-26 08:27:12
|
Hello, when building orc for Fedora, we recognized that the size of liborc exceeds the size give in the README [1]. Is this normal and just a not-so-up-to-date README, or an abnormal growth? Another note was, that one test is failing on an AMD64 arch (but running fine on x86_64). Are there known issues with AMD64 or is there something wrong on our side? Greetings - fabian -- [1] https://bugzilla.redhat.com/show_bug.cgi?id=526916#c13 [2] https://bugzilla.redhat.com/show_bug.cgi?id=526916#c18 [3] http://koji.fedoraproject.org/koji/taskinfo?taskID=2076254 |
|
From: Mark Himsley <mark@md...> - 2010-03-21 08:11:02
|
On 20/03/2010 18:34, David Schleef wrote: > On Sat, Mar 20, 2010 at 03:19:39PM +0000, Mark Himsley wrote: > >> When compiling ffmpeg from svn with on Ubuntu Karmic (gcc (Ubuntu >> 4.4.1-4ubuntu9) 4.4.1) building a static monolithic executable with this >> configure line the detection of libschroedinger fails. > >> The root cause is that `pkg-config --libs schroedinger-1.0` does not >> include -lm *after* -lorc-0.4. > > For static builds, you should be using pkg-config --static --libs ...'. > This changed in git just recently. Thanks. That makes all the difference in ffmpeg's configure. I'll try to get that into ffmpeg's svn (not that they fully support a static executable). > Also, you should be using Schroedinger and Orc releases, unless you > have a specific need for building from git I wanted the bug fixes to ORC, especially your "less hacky" fix of orc_once_mutex_lock(). > dave... -- Mark |
|
From: David Schleef <ds@en...> - 2010-03-20 18:36:08
|
On Sat, Mar 20, 2010 at 03:19:39PM +0000, Mark Himsley wrote: > Hi List. I hope this observation is ok for this list. > > When compiling ffmpeg from svn with on Ubuntu Karmic (gcc (Ubuntu > 4.4.1-4ubuntu9) 4.4.1) building a static monolithic executable with this > configure line the detection of libschroedinger fails. > The root cause is that `pkg-config --libs schroedinger-1.0` does not > include -lm *after* -lorc-0.4. For static builds, you should be using pkg-config --static --libs ...'. This changed in git just recently. Also, you should be using Schroedinger and Orc releases, unless you have a specific need for building from git, for example, you're checking to see if a bug in the release is fixed in git before reporting it. dave... |
|
From: Mark Himsley <mark@md...> - 2010-03-20 15:41:13
|
Hi List. I hope this observation is ok for this list.
When compiling ffmpeg from svn with on Ubuntu Karmic (gcc (Ubuntu
4.4.1-4ubuntu9) 4.4.1) building a static monolithic executable with this
configure line the detection of libschroedinger fails.
./configure \
--prefix=/usr/local \
--enable-gpl \
--enable-nonfree \
--enable-runtime-cpudetect \
--enable-static \
--disable-shared \
--enable-pthreads \
--enable-runtime-cpudetect \
--extra-cflags='--static -L/usr/local/include' \
--extra-libs='-static -L/usr/local/lib' \
--enable-ffmpeg \
--enable-ffplay \
--enable-ffprobe \
--enable-ffserver \
--enable-libschroedinger
The root cause is that `pkg-config --libs schroedinger-1.0` does not
include -lm *after* -lorc-0.4.
Editing /usr/local/lib/pkgconfig/orc-0.4.pc and adding -lm to the end of
the Libs: line fixes that problem and ffmpeg can be configured and compiled.
My ORC is from git today.
Thanks.
--
Mark
|
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-19 20:52:49
|
On Fri, Mar 19, 2010 at 5:30 PM, David Schleef <ds@...> wrote: > On Thu, Mar 18, 2010 at 09:57:33PM -0300, Ramiro Polla wrote: >> $subj > > This patch breaks compiling with MSVC. In general, I approve > of C99 features, but MSVC still doesn't have inttypes.h. It's http://code.google.com/p/msinttypes/ |
|
From: David Schleef <ds@en...> - 2010-03-19 20:31:29
|
On Thu, Mar 18, 2010 at 09:57:33PM -0300, Ramiro Polla wrote: > $subj This patch breaks compiling with MSVC. In general, I approve of C99 features, but MSVC still doesn't have inttypes.h. It's probably about time to add a better solution than the autogenerated orc-stdint.h. dave... |
|
From: David Schleef <ds@en...> - 2010-03-19 19:14:06
|
On Fri, Mar 19, 2010 at 09:44:40AM -0300, Ramiro Polla wrote: > This patch makes the malloc() case unused. It's still left there if > you want to reuse it later. From what I understood, only the win32 > targets were using malloc(), right? There's at least one embedded user with a custom OS that uses the malloc code allocator. He apparently has to patch configure.ac. Anyway, I'll fix up that bit. dave... |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-19 12:48:03
|
On Thu, Mar 18, 2010 at 10:02 PM, Tommy Thorn <tommy.thorn@...> wrote: > +#define ALIGN(ptr,n) ((void *)((intptr_t)(ptr) & (~(unsigned long)(n-1)))) > > This should be > > +#define ALIGN(ptr,n) ((void *)((uintptr_t)(ptr) & (~(uintptr_t)(n-1)))) Right... I'm not sending another patch with only this change though... |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-19 12:44:49
|
On Fri, Mar 19, 2010 at 3:06 AM, David Schleef <ds@...> wrote: > On Thu, Mar 18, 2010 at 10:00:04PM -0300, Ramiro Polla wrote: >> $subj, not tested on pw32. >> >> This should make the allocated code executable so it may run from >> Win64. But I assume there is no Win64 calling convention implemented >> yet, so it still crashes all the time. > > Is memory allocated by malloc() not executable on Win64? That's right, it's not executable. > This patch is not acceptable as-is, since it removes the malloc() This patch makes the malloc() case unused. It's still left there if you want to reuse it later. From what I understood, only the win32 targets were using malloc(), right? > case. Would you like to fix it up, or would you like me to hack > up an untested patch? (By the way, the VirtualAlloc() does work > on Win32, and I'm indifferent as to which method it uses.) I'm too lazy to fix it up, I'd rather test the hacked up patch =). But if it works on Win32 then it should work on Win64 as well (except for the calling convention). |
|
From: David Schleef <ds@en...> - 2010-03-19 06:07:38
|
On Thu, Mar 18, 2010 at 10:00:04PM -0300, Ramiro Polla wrote: > $subj, not tested on pw32. > > This should make the allocated code executable so it may run from > Win64. But I assume there is no Win64 calling convention implemented > yet, so it still crashes all the time. Is memory allocated by malloc() not executable on Win64? This patch is not acceptable as-is, since it removes the malloc() case. Would you like to fix it up, or would you like me to hack up an untested patch? (By the way, the VirtualAlloc() does work on Win32, and I'm indifferent as to which method it uses.) dave... |
|
From: Tommy Thorn <tommy.thorn@gm...> - 2010-03-19 01:02:28
|
+#define ALIGN(ptr,n) ((void *)((intptr_t)(ptr) & (~(unsigned long)(n-1)))) This should be +#define ALIGN(ptr,n) ((void *)((uintptr_t)(ptr) & (~(uintptr_t)(n-1)))) Tommy On Mar 18, 2010, at 17:57 , Ramiro Polla wrote: > $subj > <0002-Do-not-misuse-long-and-long-long-for-64-bit-ints.patch>------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Schrodinger-devel mailing list > Schrodinger-devel@... > https://lists.sourceforge.net/lists/listinfo/schrodinger-devel |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-19 01:00:10
|
$subj, not tested on pw32. This should make the allocated code executable so it may run from Win64. But I assume there is no Win64 calling convention implemented yet, so it still crashes all the time. |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-19 00:57:40
|
$subj |
|
From: David Schleef <ds@en...> - 2010-03-18 22:30:28
|
On Thu, Mar 18, 2010 at 06:16:00PM -0300, Ramiro Polla wrote: > Sorry, I had replied to dave only. I thought the list would Reply-To > itself by default but that doesn't seem to be the case. > > On Thu, Mar 18, 2010 at 5:09 PM, David Schleef <ds@...> wrote: > > On Thu, Mar 18, 2010 at 04:10:11PM -0300, Ramiro Polla wrote: > >> Do you expect all users to find this out and set ORCC directly? Is > >> this even documented anywhere? > > > > Almost all users get schroedinger from a distribution. The small > > fraction of users that compile themselves are mostly compiling for > > local use. For the small fraction of those people that are cross > > compiling or building packages for a distribution, I expect that > > they can figure these things out. > > >> Could you please give more examples on what other tools follow this? > > > > In a few minutes of searching, I found: > > Qt > > glib > > ORBit > > Does each distributor also have to waste time finding out if there is > an ORCC-like variable hidden somewhere that must be set to something > specific for each of these tools? If you're cross compiling, yes. It's not like this takes a huge amount of time to figure out: You cross-compile schroedinger, it fails, you realize that it attempts to use /some/prefix/orcc.exe, realize that you need to a) get an orcc tool that runs locally, and b) tell schroedinger to run that tool. 30 seconds looking in the Makefile tells you that it's using the ORCC variable, which leads you directly to the solution of using 'make ORCC=/usr/bin/orcc'. If you overthink it, you might wonder if orcc has some platform dependency, but either examining or executing the generated code would lead you to think "probably not". And indeed, the answer is no. dave... |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-18 21:16:11
|
Sorry, I had replied to dave only. I thought the list would Reply-To itself by default but that doesn't seem to be the case. On Thu, Mar 18, 2010 at 5:09 PM, David Schleef <ds@...> wrote: > On Thu, Mar 18, 2010 at 04:10:11PM -0300, Ramiro Polla wrote: >> Do you expect all users to find this out and set ORCC directly? Is >> this even documented anywhere? > > Almost all users get schroedinger from a distribution. The small > fraction of users that compile themselves are mostly compiling for > local use. For the small fraction of those people that are cross > compiling or building packages for a distribution, I expect that > they can figure these things out. >> Could you please give more examples on what other tools follow this? > > In a few minutes of searching, I found: > Qt > glib > ORBit Does each distributor also have to waste time finding out if there is an ORCC-like variable hidden somewhere that must be set to something specific for each of these tools? |
|
From: David Schleef <ds@en...> - 2010-03-17 21:59:46
|
On Tue, Mar 16, 2010 at 01:36:36AM -0300, Ramiro Polla wrote: > This means schroedinger uses both liborc and orcc. If liborc was built > for cross-compilation, either orcc won't run or liborc won't link. > David Schleef claims it's not a bug in liborc: > http://bugs.freedesktop.org/show_bug.cgi?id=27103 > > Either libschroedinger, liborc, or pkg-config (most likely all 3) are wrong. None of them are wrong. You'll need to have both a native Orc and cross-Orc on your system to build Schroedinger, and also specify ORCC directly. This is pretty normal practice for packages that create build tools. dave... |
|
From: Bojan <havaji@ya...> - 2010-03-17 06:40:24
|
Hi. I tried arrozcru build, but there seems to be some issues with the new version: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=1&t=1323 So what about http://diracvideo.org/wiki/index.php/Ffmpeg2dirac ? Last build was from 11-Feb-2009. I know devs are busy, but it could be quite useful to have win builds of encoder and decoder. I tried vlc 1.05 on win, but it does not have dirac dll included, so no go. Thanks for the work on coding, and hope to be able to run win version soon. |
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-16 04:36:46
|
>From configure.ac:
----------------------------------------
dnl Orc is required
ORC_VER="0.4.3"
PKG_CHECK_MODULES(ORC, orc-0.4 >= $ORC_VER, HAVE_ORC=yes, HAVE_ORC=no)
if test "x${HAVE_ORC}" != xyes ; then
AC_ERROR([orc-0.4 >= $ORC_VER is required])
fi
SCHRO_PKG_DEPS="$SCHRO_PKG_DEPS orc-0.4 >= $ORC_VER"
ORCC=`$PKG_CONFIG --variable=orcc orc-0.4`
AC_SUBST(ORCC)
----------------------------------------
This means schroedinger uses both liborc and orcc. If liborc was built
for cross-compilation, either orcc won't run or liborc won't link.
David Schleef claims it's not a bug in liborc:
http://bugs.freedesktop.org/show_bug.cgi?id=27103
Either libschroedinger, liborc, or pkg-config (most likely all 3) are wrong.
|
|
From: Ramiro Polla <ramiro.polla@gm...> - 2010-03-16 04:28:52
|
On http://diracvideo.org/developers/ : "Bugs should be reported on the Bugzilla system." The link points to http://bugzilla.schleef.org/cgi-bin/bugzilla/index.cgi , which gives: Not Found The requested URL /cgi-bin/bugzilla/index.cgi was not found on this server. Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch mod_ssl/2.2.11 OpenSSL/0.9.8g Server at bugzilla.schleef.org Port 80 |
|
From: Tim Borer <tim.borer@bb...> - 2010-03-15 16:33:08
|
I appreciate the need to keep the spec free as in speech. Balanced against this is the need to avoid divergence from the SMPTE spec. Maybe the thing to do is to split the Dirac spec into two parts, one corresponding to the SMPTE spec, but not owned by the SMPTE and freely available, the other corresponding to the interframe parts of Dirac (and also freely available). Then users can still get access to the whole spec even if we say that, in case of difference, the SMPTE spec takes preference. Whatever is done it will be a while and we'll try to keep everyone informed. Please rest assured that we still want Dirac to remain a royalty free open technology. We're not going back on that. Tim At 14:13 15/03/2010, James Cloos wrote: > >>>>> "TB" == Tim Borer <tim.borer@...> writes: > >TB> I had in mind trimming the current Dirac spec of everything covered >TB> in SMPTE 2042. > >That would severely reduce the use and usefulness of dirac. > >Please don't. > >The spec needs to remain free, and TeX source in git is as close to an >optimal choice as is available. > >And, yes, I do mean free as GNU uses it. > >-JimC >-- >James Cloos <cloos@...> OpenPGP: 1024D/ED7DAEA6 > >No virus found in this incoming message. >Checked by AVG - http://www.avg.com >Version: 8.5.436 / Virus Database: 271.1.1/2747 - Release Date: >03/14/10 19:33:00 Tim Borer BBC Research & Development BBC Centre House 56 Wood Lane London W12 7SB Office: 03030 409611 Mobile: 07745 108652 |
|
From: Tim Borer <tim.borer@bb...> - 2010-03-11 14:01:33
|
The Open Cores "implementation" of "Dirac", is out of date, broken and only even implemented a tiny piece of Dirac. DO NOT EVEN TRY TO USE IT. There is, as yet, no hardware implementation of long GOP Dirac. However some companies (Numedia Technology and soon others have commercial hardware implementations of Dirac Pro (SMPTE 2042/VC-2). Westwood Rock are developing commercial (but probably not very expensive) Dirac Pro cores for anyone to use. I am told they should be making an announcements within the next few months. Tim At 18:17 10/03/2010, Stefan de Konink wrote: >Hi, > > >Yesterday I was looking at the OpenCores implementation of Dirac. I >wonder, what hardware was used to test this? > > >Stefan > >------------------------------------------------------------------------------ >Download Intel® Parallel Studio Eval >Try the new software tools for yourself. Speed compiling, find bugs >proactively, and fine-tune applications for parallel performance. >See why Intel Parallel Studio got high marks during beta. >http://p.sf.net/sfu/intel-sw-dev >_______________________________________________ >Schrodinger-devel mailing list >Schrodinger-devel@... >https://lists.sourceforge.net/lists/listinfo/schrodinger-devel > >No virus found in this incoming message. >Checked by AVG - http://www.avg.com >Version: 8.5.436 / Virus Database: 271.1.1/2736 - Release Date: >03/11/10 07:33:00 Tim Borer BBC Research & Development BBC Centre House 56 Wood Lane London W12 7SB Office: 03030 409611 Mobile: 07745 108652 |
|
From: Tommy Thorn <tommy.thorn@gm...> - 2010-03-11 09:05:39
|
On Wed, Mar 10, 2010 at 11:48 AM, David Schleef <ds@...> wrote: > > http://diracvideo.org/download/test-streams/raw/vts/ > > This set of streams is meant to test the various features of the > encoder, but happens to hit most of the code paths in the decoder. > Thanks, this is really helpful. It exposed one bug in my parser already, unfortunately I'm still hunting bugs in the decoder. Tommy > Also, each frame has an MD5 sum embedded in the bit stream, which is > described here: > > http://diracvideo.org/wiki/index.php/DiracAuxiliaryData > > > > dave... > > |
|
From: David Schleef <ds@en...> - 2010-03-10 19:49:36
|
On Wed, Mar 10, 2010 at 01:51:16PM -0500, David Schleef wrote: > On Wed, Mar 10, 2010 at 10:39:35AM -0800, Tommy Thorn wrote: > > Thanks David, > > > > It would be very useful to have a diverse set of reference clips in *plain* drc format, exercising > > as much as possible of the spec along with golden outputs and perhaps a few examples of > > expected internal state. > > testsuite/streams/make_vts_streams. It requires GStreamer, though. > I can put the streams (that are currently being generated) on the > web site. http://diracvideo.org/download/test-streams/raw/vts/ This set of streams is meant to test the various features of the encoder, but happens to hit most of the code paths in the decoder. Also, each frame has an MD5 sum embedded in the bit stream, which is described here: http://diracvideo.org/wiki/index.php/DiracAuxiliaryData dave... |