pfspd-users — For pfspd users: support, suggestions, announcments, etc.

Re: [Pfspd-users@sf.net] File fragmentation

[Harold S. <har...@ph...>]

Hello,

Thanks to Bram's rigorous testing, we uncovered a problem with the win32 
file I/O.

In overlapped (asynchronous) mode, reserving the file space does not 
complete immediately,
but it appears that some data (zeros ?) is written to disk. On a local 
file system, this takes some time, but works ok.
However,on a network share (e.g. writing remotely to a streamer pc), there 
is a timeout after 2-3 GB, and the application crashes.

Workaround is to create a file using regular I/O, reserve disk space, 
close it, then open again in overlapped mode.
The disk space allocation is moved to p_fio_allocate( ).

Please note that this only affects you if you are using the development 
version of cpfspd (sf.net), so update your cvs sandbox.

Regards,
Harold
___________________________________
Ing. H.A.W. Schmeitz
Video Processing Systems, Philips Research Laboratories

High Tech Campus 36, 5656 AE Eindhoven, The Netherlands
Tel. +31 (0)40 27 46489
har...@ph...

[Pfspd-users@sf.net] File fragmentation

[Harold S. <har...@ph...>]

Hello All,

Today, I made a patch to cpfspd which helps to reduce file fragmentation 
on NTFS.
As a side benefit, file creation is much faster than before.

To benefit from this change, make sure that the number of images in the 
pT_header structure is set correctly.
(Currently, many tools set this to zero or 1 to speed up file creation, 
which is not needed anymore).

Please update your cvs sandboxes.

Regards,
Harold
___________________________________
Ing. H.A.W. Schmeitz
Video Processing Systems, Philips Research Laboratories

High Tech Campus 36, 5656 AE Eindhoven, The Netherlands
Tel. +31 (0)40 27 46489
har...@ph...

[Pfspd-users@sf.net] WxWidgets 2.6.2 install for PV developers

[Bram R. <bra...@ph...>]

Hi all,

For PV developers at Research Eindhoven/High Tech Campus, a new release of 
wxWidgets is installed at
/home/softtv/appls/utils/wxwin/wx-2.6.2

The PV Make.env files have been adapted; just run
setup.sh -f
at the PV directory (.../pfspd/pv)

As discussed before, support for SunOS and SGI has been discontinued.
The following platforms are supported: win32, cygwin, Linux, hp

Regards, Bram.
--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] MTK update: LINK_CPP feature

[Bram R. <bra...@ph...>]

Hi all,

Today, I added a new feature in the MTK development tree.

From the Readme file:
- Added LINK_CPP setting. Use LINK_CPP=1 in the Makefile
  to allow applications only using C sources with libraries
  that contains C++ sources. This flag forces the choice
  of the link command.

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] Platform support for PV

[Bram R. <bra...@ph...>]

Dear PV users,

We are currently in the process to migrate PV from wxWindows 2.4.0 to 
wxWidgets 2.6.2.
(wxWidgets is the new name for wxWindows). This transistion is essential 
for some
bug fixes; in a couple of cases, PV suffers from low level bugs in 
wxWidgets/GTK.

We find ourselves in the situation that compiling wxWidgets is 
increasingly difficult
on some older platforms. Since wxWidgets is built on top of GTK, we also 
need a
GTK 2.x version on all platforms. Our computer support department (COS) 
did an
attempt to get this available, but they are about to give up...
This is partly motivated by the required effort, and partly by their 
platform support policies.

Up till now, we were used to provide pre-compiled executables on the 
following platforms:
sgi/irix, sun/solaris, hp/hp-ux, linux, windows, and cygwin.

We now propose to cease support of the "older" *nixes (sgi, sun, hp) and 
keep only:
linux, windows, and cygwin.

For the high tech campus and research environments, the PV command will 
remain
available via the queing system (in other words, entering "pv" on a sgi 
system will
start the pv tool in a linux queue). This will provide a solution for 
shared/networked
file systems; not for sgi-local file systems.

If you feel to encouter serious limitations by this move, please let me 
know.

Kind regards, Bram.

PS. This only holds for PV viewer. The cpfspd library remains available.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] PV update: menus and accelarators

[Bram R. <bra...@ph...>]

Hi all,

Changes in the PV code repository:
- The view menu is enhanced with submenu's for the "deinterlace method",
  the "color display method" and the "signal/vector range".
  Other menu entries have become a checkbox ("single field display"
  and "full color range").
  This aims at improving the user feedback of the current settings.
- Key handling in canvas is cleaned up. Where possible, menu accelators
  are used. This functionality was duplicated in the OnChar method.

Novice users can now see the display modes in the menu.

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] File size platform dependency resolved

[Bram R. <bra...@ph...>]

Hi all,

With help from Erwin de Kock, we resolved the file size issue in the 
cpfspd
development repository.

From the readme file:
- Files written on the windows (win32 or cygwin) platforms
  contained unused space at the end due to the unbuffered
  file I/O. As a consequence, the file length depended on
  the platform. This is no longer the case. On win32/cygwin,
  the file is truncated to the proper length.

For a clean impelementation , I had to dig quite deep into cpfspd_low
to keep track of actual data written to the file and use this information
when the file is actually closed.

A new test on file size is added.

Developers, please update your sandboxes.

Regards, Bram.
--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

Re: [Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Erwin de K. <erw...@ph...>]

Hi Bram and others,

The files are know modified only if the pfiles[idx].mode equals 
p_write_mode when entering the p_close_idx() function. I hope this does 
the job.

Thanks for the offer to become a developer but I prefer to remain a happy 
user for a while. This does not mean that this was my last patch but I 
want to limit the number of patches :-)

I will send the patch directly.

Best regards,
Erwin

[Pfspd-users@sf.net] Parse_options under LGPL

[Bram R. <bra...@ph...>]

Hi all,

On request of Erwin de Kock I have changed the licence terms of the 
parse_options module
from GPL to LGPL. This is in line with the permission to bring cpfspd 
under LGPL.
Erwin needs this in view of his effort to release YAPI under LGPL.

Developers, please update your sandbox.

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

Re: [Pfspd-users@sf.net] Cpfspd speed optimization on cygwin

[Bram R. <bra...@ph...>]

Hi all,

Immediately after the previous email, the -mmmx and -msse compiler options 
got my attention.
Then Patrick called and suggested the same.
I verified the gcc doc, and it seems that they indeed serve our purpose.
Hence, I have enabled the speed optimization on cygwin.
There is no cpu load difference anymore between the win32 and the cygwin 
platforms.

Patrick, thanks for your input!

Developers, some tests on old hardware would be appreciated... :-)

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...








Bram Riemens 
Sent by:
pfs...@li...
03-02-2006 17:24

To
pfs...@li...
cc
Patrick Meuwissen/EHV/RESEARCH/PHILIPS@PHILIPS
O P Gangwal/EHV/RESEARCH/PHILIPS@PHILIPS
Subject
[Pfs...@sf...] Cpfspd speed optimization on cygwin
Classification








Hi all, 

Today, I updated the cpfspd_fio.c module in the code repository. 
This code contains a speed optimized memcpy function, that uses 
assembly and intrinsics for cpu identification, data prefetching and 
fast copy using the SSE instruction set. 
Uptil now, this is available on the win32 platform only; not on cygwin. 
This assembly code has been streamlined for a few % more 
performance (hence lower cpu load for file access functions). 

Furthermore, I prepared gcc compilation for this code. 
Unfortunately it requires the -mpentium4 compiler flag. 
So, even though the cpu is checked at runtime whether the optimized 
code can be executed, I cannot compile it unless the processor is 
specified to the compiler. 
I am reluctant to specify the  -mpentium4 flag because I don't know 
what the compiler will do with all other code... 
I do not want to distribute a cpfspd library that fails on older 
(pre-pentium4) 
systems. And I do not have such systems to test... 
Therefore, the optimized memcpy code is still not activated on cygwin. 

Any suggestions? Opinions? Hints to compile without the processor flag? 

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] Cpfspd speed optimization on cygwin

[Bram R. <bra...@ph...>]

Hi all,

Today, I updated the cpfspd_fio.c module in the code repository.
This code contains a speed optimized memcpy function, that uses
assembly and intrinsics for cpu identification, data prefetching and
fast copy using the SSE instruction set.
Uptil now, this is available on the win32 platform only; not on cygwin.
This assembly code has been streamlined for a few % more
performance (hence lower cpu load for file access functions).

Furthermore, I prepared gcc compilation for this code.
Unfortunately it requires the -mpentium4 compiler flag.
So, even though the cpu is checked at runtime whether the optimized
code can be executed, I cannot compile it unless the processor is
specified to the compiler.
I am reluctant to specify the  -mpentium4 flag because I don't know
what the compiler will do with all other code...
I do not want to distribute a cpfspd library that fails on older 
(pre-pentium4)
systems. And I do not have such systems to test...
Therefore, the optimized memcpy code is still not activated on cygwin.

Any suggestions? Opinions? Hints to compile without the processor flag?

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

Re: [Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Bram R. <bra...@ph...>]

Hi Erwin,

Indeed, file length shall only be adapted if file is modified (i.e. 
written).
This is not only important to ratain the original file attributes, but 
even more to allow reading files when the user has no write access.

Are you interested in becoming a developer?
Then you can perform the update yourself. I will have a look at it anyhow.
Otherwise, it is probably simplest to hand-over the patch to me directly.

Regards, Bram.
--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...








Erwin de Kock 
Sent by:
pfs...@li...
02-02-2006 18:43

To
pfs...@li...
cc

Subject
Re: [Pfs...@sf...] Linux, cygwin, and different yuv file sizes
Classification








Hi Bram and others 

I have implemented the file truncation using the extended approach: 

1- perform regular close of the file 
2- reopen the file in read mode to avoid calling of p_close_idx() in 
p_read_hdr() 
3- read the header using p_read_hdr() 
4- calculate file length 
5- close file 
6- set file length by 
   a) reopening the file in update mode, 
   b) advancing the file pointer to file length using 
fio_fp_set_filepointer(), 
   c) calling SetEndOfFile(), 
   d) and closing the file

To this end, I have added code to p_close_idx() and I have added a 
function p_fio_set_end_of_file(const char* filename, fio_offset_t offset) 
to cpfspd_fio to implement step 6. 

Currently this is done for all files, so also for files that were opened 
for reading only. This is not ok, since the date and time attributes of 
read-only files will be updated. I do not know if it is save to assume in 
p_close_idx() that if p_files[idx].mode equals p_mode_read, then the file 
should not be truncated. Any comments on this? 

How do you want me to send the changes? Shall I submit a patch file 
through the sourceforge site? 

Best regards, 
--Erwin

Re: [Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Erwin de K. <erw...@ph...>]

Hi Bram and others

I have implemented the file truncation using the extended approach:

1- perform regular close of the file 
2- reopen the file in read mode to avoid calling of p_close_idx() in 
p_read_hdr()
3- read the header using p_read_hdr()
4- calculate file length 
5- close file 
6- set file length by
   a) reopening the file in update mode, 
   b) advancing the file pointer to file length using 
fio_fp_set_filepointer(), 
   c) calling SetEndOfFile(),
   d) and closing the file

To this end, I have added code to p_close_idx() and I have added a 
function p_fio_set_end_of_file(const char* filename, fio_offset_t offset) 
to cpfspd_fio to implement step 6.

Currently this is done for all files, so also for files that were opened 
for reading only. This is not ok, since the date and time attributes of 
read-only files will be updated. I do not know if it is save to assume in 
p_close_idx() that if p_files[idx].mode equals p_mode_read, then the file 
should not be truncated. Any comments on this?

How do you want me to send the changes? Shall I submit a patch file 
through the sourceforge site?

Best regards,
--Erwin

Re: [Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Bram R. <bra...@ph...>]

Hi Erwin, others,

Here my thoughts on the implementation of file size truncation on windows.

Currently, files are closed by function p_close_idx() in module 
cpfspd_low.
Possible reasons to close a file are:
- application request
- application opens new file while many files already open (least recently 
used file is closed)
- atexit function when application terminates

Main issue: the file header info is required in order to calculate the 
file size.
This info is not available in p_close_idx(). In many cases,
this info is not even in the application anymore.

Note that p_close_idx() already writes the number of images at the
beginning of the file (hence, it adapts the file header) in case
the actual file contains more images than the data in the file header.

Simple approach

The win32 api has calls to set file size. Maybe this works for files
opened unbuffered and asynchronously. If this is true, then this
simple approach will work.

Therefore, the approach must be:
- move to beginning of the file
- read the header
- calculate file length
- set file length
- close file

Extended approach

It may be required to close the file first, then reopen it in normal mode.
This results in a slightly more extended approach:
- perform regular close of the file
- reopen the file (normal mode)
- read the header
- calculate file length
- set file length
- close file

Other notes

Module cpfspd_low.
- Add required functionality in p_close_idx().
- File size calculation is analogous to file positioning when accessing an 
image,
  see e.g. cpfspd_low.c function p_read_image() lines 1593-1610.

Some win API background info for use in cpfspd_fio:
- OpenFile() 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/openfile.asp
- ReOpenFile() 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/reopenfile.asp
- SetFilePointer() 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/setfilepointer.asp
- SetEndOfFile() 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/setendoffile.asp
- CloseHandle() 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/closehandle.asp
Examples of most of these calls are already in cpfspd_fio.c
I expect, when reopening the file in the new mode, all regular file access 
works as expected.
Hence, first reopen the file in normal buffered mode; then perform the 
regular p_read_header()
(which uses fio_read functions) will work as usual.
I expect, only new code is to be added. No existing code needs 
modification.

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...








Erwin de Kock
30-01-2006 21:15

To
Bram Riemens/EHV/RESEARCH/PHILIPS@PHILIPS
cc

Subject
Re: [Pfs...@sf...] Linux, cygwin, and different yuv file  sizes
Classification
Unclassified





Hi Bram,

Thanks for the response. I am using your software in our open source 
project at http://sourceforge.net/projects/y-api. The internal tool pts is 
not available for the general public so I prefer your suggestion to adapt 
the file size when closing the file. Then I can check against expected 
output using "diff -q". I am willing to help with this change, but I have 
to familiarize myself with your code. I will contact you if I have 
questions :)

Best regards,
--Erwin

Re: [Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Bram R. <bra...@ph...>]

Hi Erwin, others,

On windows platforms (cygwin, win32) we use high performance platform 
specific file I/O.
When the OS version (windows NT, 2000, XP) and the file system (ntfs) 
supports it,
unbuffered and asynchronous I/O is used (this is detected at runtime).
As an example, the underlaying I/O system performs the read DMA of a next 
block
while the application is processing the current block.
This I/O is optimized for sequential image access and allows us to process 
video
data with only a single memcpy operation between an cpfspd internal buffer 
and
the application. On win32, this memcpy is optimized using MMX operations.
The result is a data throughput close to the theoretical limits of the 
harddisk
with a very low CPU load overhead.

This is only possible with I/O blocks that are a multiple of the disk 
block size.
We found that a block size of 256 kbyte provides optimal performance in 
most cases.

As a side effect of this approach, the file size is always a multiple of 
256 kbyte
on cygwin/win32. So you are doing nothing wrong.

When we want to perform checks against expected output, we typically use
an internal tool "pts checksum". This provides a checksum of the file 
contents,
thus ignores the unused file space.

Regards, Bram.

PS. The buffer size can be changed with p_set_file_buf_size().

PPS. As a solution, we could adapt the file size when closing the file.
Erwin, are you able to help with this change?

PPPS. I'll make a FAQ page at our website. This question is not new.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...








Erwin de Kock 
Sent by:
pfs...@li...
26-01-2006 19:09

To
pfs...@li...
cc

Subject
[Pfs...@sf...] Linux, cygwin, and different yuv file sizes
Classification








Hi all, 

I noticed that the cpfsp p_write_header function generates files that have 
different sizes under Linux and Cygwin. I use the following code: 

#include <stdlib.h> 
#include "cpfspd.h" 

int main() 
{ 
    pT_header seqInfo; 
    pT_status status; 

    if ((p_create_ext_header(&seqInfo, P_COLOR_420_PL, P_50HZ, P_SD, 720, 
1, P_16_9) != P_OK) 
         || (p_mod_image_size(&seqInfo, 704, 576) != P_OK) 
         || (p_mod_num_frames(&seqInfo, 7) != P_OK) 
       ) 
    { 
      printf("Error, cannot create pfspd header\n"); 
      exit(1); 
    } 
 
    status=p_write_header("./out.yuv", &seqInfo); 
} 

Under Linux this results in a file out.yuv of size 4280320. 
Under Cygwin this results in a file out.yuv of size 4456448. 

If I write yuv data in the specified format to these files, then the first 
4280320 bytes of the files are identical. So it seems that the last bytes 
of the cygwin out.yuv file are not used (or maybe even more if the linux 
file size is too large as well). 

I also tried supported combinations of color format, image frequency, and 
image size such as p_create_ext_header(&seqInfo, P_COLOR_420_PL, P_50HZ, 
P_SD, 720, 1, P_4_3) without changing the image size later on, but this 
also gives different file sizes. 

The different files are a problem because I want to check the output of my 
program against expected output. I prefer that the expected output does 
not depend on the platform. 

What am I doing wrong? 

Thanks for any help, 
Erwin de Kock 

[Pfspd-users@sf.net] Linux, cygwin, and different yuv file sizes

[Erwin de K. <erw...@ph...>]

Hi all,

I noticed that the cpfsp p_write_header function generates files that have 
different sizes under Linux and Cygwin. I use the following code:

#include <stdlib.h>
#include "cpfspd.h"

int main()
{
    pT_header seqInfo;
    pT_status status;

    if ((p_create_ext_header(&seqInfo, P_COLOR_420_PL, P_50HZ, P_SD, 720, 
1, P_16_9) != P_OK)
         || (p_mod_image_size(&seqInfo, 704, 576) != P_OK)
         || (p_mod_num_frames(&seqInfo, 7) != P_OK)
       )
    {
      printf("Error, cannot create pfspd header\n");
      exit(1);
    }
 
    status=p_write_header("./out.yuv", &seqInfo);
}

Under Linux this results in a file out.yuv of size 4280320.
Under Cygwin this results in a file out.yuv of size 4456448.

If I write yuv data in the specified format to these files, then the first 
4280320 bytes of the files are identical. So it seems that the last bytes 
of the cygwin out.yuv file are not used (or maybe even more if the linux 
file size is too large as well).

I also tried supported combinations of color format, image frequency, and 
image size such as p_create_ext_header(&seqInfo, P_COLOR_420_PL, P_50HZ, 
P_SD, 720, 1, P_4_3) without changing the image size later on, but this 
also gives different file sizes.

The different files are a problem because I want to check the output of my 
program against expected output. I prefer that the expected output does 
not depend on the platform.

What am I doing wrong?

Thanks for any help,
Erwin de Kock

[Pfspd-users@sf.net] [Fwd: [ alexandria-Support Requests-1408891 ] CVS stale lock removal: pfspd]

[Hendrik te W. <he...@4d...>]

The CVS commands for the PV tool work again as expected.

Hendrik

-------- Original Message --------
Subject: [ alexandria-Support Requests-1408891 ] CVS stale lock removal: pfspd
Date: Wed, 18 Jan 2006 07:23:25 -0800
From: SourceForge.net <no...@so...>
To: no...@so...

Support Requests item #1408891, was opened at 2006-01-18 04:04
Message generated for change (Comment added) made by zigler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1408891&group_id=1

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Project CVS Services
Group: First Level Support
>Status: Closed
>Priority: 7
Submitted By: Hendrik te Winkel (htewinkel)
>Assigned to: Erich Zigler (zigler)
>Summary: CVS stale lock removal: pfspd

Initial Comment:
Hi,

Since about 14 hours we get this message on all our
actions in one of our pfspd project areas:

cvs status: [09:59:44] waiting for riemen's lock in
/cvsroot/pfspd/pv

I know what it is, but I don't think I can remove the
lock myself. Could you fix this for us, please?
The person (riemens) who 'caused' the lock is away for
a couple of days.

Thanks,
Hendrik te Winkel - pfspd developer

----------------------------------------------------------------------

Comment By: Erich Zigler (zigler)
Date: 2006-01-18 09:23

Message:
Logged In: YES 
user_id=1243797

Greetings, 

Per your request, the stale lock(s) have been removed from your
project CVS repository.  Should you require further  assistance
from the SourceForge.net team, please submit a new support request. 

Thank you, 

SourceForge.net support

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1408891&group_id=1

-- 
Hendrik te Winkel                he...@4d...
4DNet Graphics and Networks

[Pfspd-users@sf.net] PV activities

[Bram R. <bra...@ph...>]

Hi all,

Currently, I am doing some code cleanup on PV.
One issue is consistently using wxT("") for literal strings.
Further, I am moving some menu entries:

- The menu items have been reordered.
    - Next file in Directory (Space)
    - Previous file in Directory (Backspace)
    - Next file (Lock view) (Tab)
    - Previous file (Lock view) (Shift-Tab)(`)
  are moved from the view menu to the file menu as these operation
  relate to choosing the current opened file.
  The "Full screen" menu entry is moved from the file menu to the view 
menu. 

In order to reduce code complexity, I want to use menu accelarators for 
most of the menu items.
This cannot be done for the "Previous file (Lock view) " operation, since
that uses two accelerators (Shift-Tab and ` (backquote)).
I do not understand why the Shift-Tab is there. Its use is cumbersome and
the Tab and backquote keys are positioned conveniently.

Is there any objection agains removing theShift-Tab key shortcut?

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] new cpfspd version

[Hendrik te W. <he...@4d...>]

All,

A new version of cpfspd has been released. This is version 1.10.1
Some bugs were fixed that were not properly addressed when releasing
version 1.10.0

The version can be downloaded from the sourceforge.net location:
http://sourceforge.net/projects/pfspd/

Done in release 1.10.1 (dd. Jan. 10, 2006)
---------------------------------------

Highlights
       New release to recover from bugs in 1.10.0
       Bug fixes
- Function p_write_header(), takes care that a newly written header
 has room available for auxiliary headers (even when the header
 supplied by the application does not request this). The calculation
 of the amount of records was incorrect in cases where the record
 length is not a power of 2. This is corrected. This bug was created
 with the introduction of auxiliary data.
 This bug caused the following error without appearent reason:
 Error no: 228, description: Auxiliary header exceeds maximum size
- When reading from stdin using a pipe, all unused data is flushed
 from the pipe before the program terminates to avoid a "broken pipe"
 error. Previously, such error occured when an application wrote
 more data into the pipe then it read from the pipe. This could easily
 happen when writing extra components and reading only the standard
 components.

Bye,
Hendrik

[Pfspd-users@sf.net] new cpfspd version

[Hendrik te W. <hen...@ph...>]

All,

A new version of cpfspd has been released. This is version 1.10.1
Some bugs were fixed that were not properly addressed when releasing
version 1.10.0

The version can be downloaded from the sourceforge.net location:
http://sourceforge.net/projects/pfspd/

Done in release 1.10.1 (dd. Jan. 10, 2006)
---------------------------------------

Highlights
        New release to recover from bugs in 1.10.0
        
Bug fixes
- Function p_write_header(), takes care that a newly written header
  has room available for auxiliary headers (even when the header
  supplied by the application does not request this). The calculation
  of the amount of records was incorrect in cases where the record
  length is not a power of 2. This is corrected. This bug was created
  with the introduction of auxiliary data.
  This bug caused the following error without appearent reason:
  Error no: 228, description: Auxiliary header exceeds maximum size
- When reading from stdin using a pipe, all unused data is flushed
  from the pipe before the program terminates to avoid a "broken pipe"
  error. Previously, such error occured when an application wrote
  more data into the pipe then it read from the pipe. This could easily
  happen when writing extra components and reading only the standard
  components.

Bye,
Hendrik
-- 
Hendrik te Winkel              hen...@ph...
SAVG-COS                       p: +31 40 27 46170
Philips Research               f: +31 40 27 44675
High Tech Campus 36 room P044, 5656 AE Eindhoven, The Netherlands

[Pfspd-users@sf.net] Broken pipe issue resolved

[Bram R. <bra...@ph...>]

Hi all,

Today, I fixed a bug in the development tree of cpfspd.

From the readme file:
- When reading from stdin using a pipe, all unused data is flushed
  from the pipe before the program terminates to avoid a "broken pipe"
  error. Previously, such error occured when an application wrote
  more data into the pipe then it read from the pipe. This could easily
  happen when writing extra components and reading only the standard
  components.

This resolves an issue raised by Rene van de Vleuten today.
Although the "broken pipe" message sounds pretty alarming, all data was 
processed correctly.
We have seen obscure "broken pipe" messages before that we did not really 
understand.
I believe this is now resolved.

Further, I changed the copyright year to 2006.

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] PV updates: prepare wxWidgets 2.6.2

[Bram R. <bra...@ph...>]

Hi all,

Currently, I am in the process of migration to wxWidgets release 2.6.2, 
since
the current wxWindows release that we use for PV is rather old.
I hope this will also resolve the PV crash on small images that Rene 
reported recently.

In order to prepare this, PV sources frame.cc and canvas.cc were slightly 
modified.

Compilation of wxWidgets on cygwin and win32 run fine now.
On Linux, I have some pending issues.

Once this new wxWidgets release runs, I will add a wxwidgets directory 
that contains
some shell scripts and readme files how to compile (at least in our 
environment).

Regards, Bram.

--
A.K. (Bram) Riemens
Principal Scientist, DSP group, Philips Research
Office: WO-p-94, Postbox WO02
High Tech Campus 36 (WO), 5656 AE Eindhoven, The Netherlands
Tel: +31 40 27 43833, Fax: +31 40 27 44675
E-mail: bra...@ph...

[Pfspd-users@sf.net] pv trouble

[Rene v. d. V. <ren...@ph...>]

<br><font size=3D2 face=3D"sans-serif">Hi!</font>
<br>
<br><font size=3D2 face=3D"sans-serif">There seems to be a problem with the
Linux version of pv on small files. When I press PageDown or go to a frame
using &quot;g&quot;, pv crashes. Here is a file that makes it crash (availa=
ble
this week):</font>
<br><font size=3D2 face=3D"sans-serif">ftp://ftp.ehv.campus.philips.com/pri=
vate/3c3dc1152cf3b9cc55a8c5a31931dfc0/</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Regards, Ren=E9.</font>
<br><font size=3D2 face=3D"sans-serif"><br>
--------------------------------------------------------------------------<=
br>
Dr. Rene J. van der Vleuten<br>
Philips Research Laboratories<br>
Prof. Holstlaan 4 (WO-01)<br>
5656 AA &nbsp;Eindhoven<br>
The Netherlands<br>
<br>
Phone: +31 40 2742941<br>
Fax: &nbsp; +31 40 2742630<br>
mailto:Ren...@ph...</font>

Re: [Pfspd-users@sf.net] Re: [Pfspd-devel] Trouble with latest pts/cpfspd release

[Robert J. S. <rob...@ph...>]

Ignore my answer...

It seems that Bram already fixed this ;-)

I do think that we need a new release, since this is a very inconvenient=20
bug...

--
Robert Jan Schutten, mailto:Rob...@ph...
Philips Consumer Electronics Innovation Lab, Eindhoven NL
office: +31 (0) 40 2738951, mobile: +31 (0) 6 5126 3168
- "Imagination is more important than knowledge" - Einstein -








Bram Riemens <bra...@ph...>=20
Sent by:
pfs...@li...
2005-12-05 10:11
Please respond to
Bram Riemens/EHV/RESEARCH/PHILIPS@PHILIPS


To
pfs...@li...
cc
Rene van der Vleuten/EHV/RESEARCH/PHILIPS@PHILIPS
Subject
[Pfs...@sf...] Re: [Pfspd-devel] Trouble with latest      pts/cpfspd =

release
Classification








Hi Rene, others,=20

In the latest cpfspd releaes we introduced auxiliary data.=20
In some (unusual) cases, an existing application fails to run.=20
This is fixed in the code repository.=20

Here is the excerpt of the Readme file:=20
- Function p=5Fwrite=5Fheader(), takes care that a newly written header=20
  has room available for auxiliary headers (even when the header=20
  supplied by the application does not request this). The calculation=20
  of the amount of records was incorrect in cases where the record=20
  length is not a power of 2. This is corrected. This bug was created=20
  with the introduction of auxiliary data.=20

Regards, Bram.

--
A.K. (Bram) Riemens, Principal Scientist
Philips Research Laboratories; Office: WDC 1.51
Prof. Holstlaan 4 (WDC-01), 5656 AA Eindhoven, The Netherlands
Tel: +31 40 27 43833; Fax: +31 40 27 44004
mailto:bra...@ph...=20







Rene van der Vleuten=20
Sent by:=20
pfs...@gf...=20
02-12-2005 17:23=20


To
pfs...@gf...=20
cc

Subject
[Pfspd-devel] Trouble with latest pts/cpfspd release=20
Classification










Hi!=20

there seems to be some serious trouble with the latest release:=20
/home/softtv/appls/utils/pts/release/latest/exe/Linux/pts convert -yuv422=20
/home/sdata/visa/videodata/seq=5Fsd/film22/teeny.yuv tst.yuv=20
Error no: 228, description: Auxiliary header exceeds maximum size, on=20
file: tst.yuv=20

I know this file is already yuv422, but this worked fine in previous=20
versions of pts. The fact that is does not work anymore causes visa to not =

accept this file!=20

Regards,=20

Ren=E9.=20

--------------------------------------------------------------------------
Dr. Rene J. van der Vleuten
Philips Research Laboratories
Prof. Holstlaan 4 (WO-01)
5656 AA  Eindhoven
The Netherlands

Phone: +31 40 2742941
Fax:   +31 40 2742630
mailto:Ren...@ph...=20
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Pfspd-devel mailing list
Pfs...@gf...
http://gforge.natlab.research.philips.com/mailman/listinfo/pfspd-devel

[Pfspd-users@sf.net] Re: [Pfspd-devel] Trouble with latest pts/cpfspd release

[Bram R. <bra...@ph...>]

Hi Rene, others,

In the latest cpfspd releaes we introduced auxiliary data.
In some (unusual) cases, an existing application fails to run.
This is fixed in the code repository.

Here is the excerpt of the Readme file:
- Function p=5Fwrite=5Fheader(), takes care that a newly written header
  has room available for auxiliary headers (even when the header
  supplied by the application does not request this). The calculation
  of the amount of records was incorrect in cases where the record
  length is not a power of 2. This is corrected. This bug was created
  with the introduction of auxiliary data.

Regards, Bram.

--
A.K. (Bram) Riemens, Principal Scientist
Philips Research Laboratories; Office: WDC 1.51
Prof. Holstlaan 4 (WDC-01), 5656 AA Eindhoven, The Netherlands
Tel: +31 40 27 43833; Fax: +31 40 27 44004
mailto:bra...@ph...








Rene van der Vleuten=20
Sent by:
pfs...@gf...
02-12-2005 17:23

To
pfs...@gf...
cc

Subject
[Pfspd-devel] Trouble with latest pts/cpfspd release
Classification








Hi!=20

there seems to be some serious trouble with the latest release:=20
/home/softtv/appls/utils/pts/release/latest/exe/Linux/pts convert -yuv422=20
/home/sdata/visa/videodata/seq=5Fsd/film22/teeny.yuv tst.yuv=20
Error no: 228, description: Auxiliary header exceeds maximum size, on=20
file: tst.yuv=20

I know this file is already yuv422, but this worked fine in previous=20
versions of pts. The fact that is does not work anymore causes visa to not =

accept this file!=20

Regards,=20

Ren=E9.=20

--------------------------------------------------------------------------
Dr. Rene J. van der Vleuten
Philips Research Laboratories
Prof. Holstlaan 4 (WO-01)
5656 AA  Eindhoven
The Netherlands

Phone: +31 40 2742941
Fax:   +31 40 2742630
mailto:Ren...@ph...=20
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Pfspd-devel mailing list
Pfs...@gf...
http://gforge.natlab.research.philips.com/mailman/listinfo/pfspd-devel