ccextractor-users — General ccextractor list.

Re: [ccextractor-users] [GSoC] Regression error list

[Ruslan K. <kuc...@gm...>]

>
> We should probably just do that if the PAT has changed (I believe I
> did that check, but I could be mistaken).

What is the purpose of clearing the caption buffer after new PAT in the
first place?  I think we should clear it only when caption type changes
(from 608 to 708 or something). As for ccx_options.ts_cappid and cap types,
I think they are valid until new PMT arrives. I tried and it worked. I'll
create pull request after testing.

Willem, I tried to use your test suite. It seems that I need to write all
files I want to test in tests.xml, right? Is there a way to test a whole
dir without specifying each file? Also, there are the filed in config
file CCExtractorLocation, maybe it's better to call it CCExtractorPath,
"location" is more like a directory (for me).

Respectfully,
Ruslan Kuchumov.


On Thu, May 22, 2014 at 8:18 AM, Carlos Fernandez <cf...@gm...> wrote:

> On Thu, May 22, 2014 at 10:11 AM, Ruslan Kuchumov <kuc...@gm...>
> wrote:
> >
> > The first one (images.mpg) is quite tricky. I think the problem is that
> we
> > clear caption buffer every time we receive new PAT. But the buffer may
> hold
>
> We should probably just do that if the PAT has changed (I believe I
> did that check, but I could be mistaken).
>
> > I didn't found any info  in specs saying that PMT should arrive after
> PAT.
>
> It doesn't. Keep in mind that in a broadcast you can start reading the
> stream at any point (when you turn on the TV). You just start getting
> packets and the first one can be anything. It can be a video stream
> (which you can't do nothing with yet), audio, a PMT for the program
> you want to watch or a different program, etc. Basically - you have to
> wait for a PAT (which is the only table for which you have a
> guaranteed PID) before you can do anything.
>
> Once you have a PAT you can wait for PMTs, and when you have the PMT
> you want then you start reading the actual elementary streams.
>
> The PAT shouldn't change often, but it can... same with PMTs.
>
> > Also I found in specs that PAT may be partitioned into up to 255 sections
>
> Yes. I don't have however any sample stream that contains a "long PAT" I
> think.
>
> > carrying parts of the overall PAT. But we treat new sections as a new
> PAT,
> > right?
>
> Hopefully not :-) I think IF a section arrives that isn't the first
> one there's an error similar to "Long PAT not supported" or something
> like that.
>

Re: [ccextractor-users] [GSoC] Regression error list

[Carlos F. <cf...@gm...>]

On Thu, May 22, 2014 at 10:11 AM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> The first one (images.mpg) is quite tricky. I think the problem is that we
> clear caption buffer every time we receive new PAT. But the buffer may hold

We should probably just do that if the PAT has changed (I believe I
did that check, but I could be mistaken).

> I didn't found any info  in specs saying that PMT should arrive after PAT.

It doesn't. Keep in mind that in a broadcast you can start reading the
stream at any point (when you turn on the TV). You just start getting
packets and the first one can be anything. It can be a video stream
(which you can't do nothing with yet), audio, a PMT for the program
you want to watch or a different program, etc. Basically - you have to
wait for a PAT (which is the only table for which you have a
guaranteed PID) before you can do anything.

Once you have a PAT you can wait for PMTs, and when you have the PMT
you want then you start reading the actual elementary streams.

The PAT shouldn't change often, but it can... same with PMTs.

> Also I found in specs that PAT may be partitioned into up to 255 sections

Yes. I don't have however any sample stream that contains a "long PAT" I think.

> carrying parts of the overall PAT. But we treat new sections as a new PAT,
> right?

Hopefully not :-) I think IF a section arrives that isn't the first
one there's an error similar to "Long PAT not supported" or something
like that.

Re: [ccextractor-users] [GSoC] Regression error list

[Ruslan K. <kuc...@gm...>]

 Hello!

  (when there's a previous CCExtractor version that
> worked OK it's of course a matter of comparing source code and patient
> analysis).

The first one (images.mpg) is quite tricky. I think the problem is that we
clear caption buffer every time we receive new PAT. But the buffer may hold
some data. Also we set ccx_options.ts_cappid to 0. It seems that after PAT
packet we receive packet with captions, but we don't know about it
because ts_cappid is set to 0. Maybe we should keep it until next PMT and
don't clear the buffer.
I didn't found any info  in specs saying that PMT should arrive after PAT.
I commented the code which clears caption buffer, and it works fine (maybe
only with this file).

Also I found in specs that PAT may be partitioned into up to 255 sections
carrying parts of the overall PAT. But we treat new sections as a new PAT,
right? Specs says that new PAT is valid when its version_number is 1. I
doubt it because version_number is 5 bits long.
So, I need some advice.

Respectfully,
Ruslan Kuchumov.


On Wed, May 21, 2014 at 6:40 AM, Carlos Fernandez <cf...@gm...> wrote:

> OK, so here's what I think should be the immediate course of action:
>
> - Willem, complete the tests as you say so we now exactly which tests
> files are broken and when was the last time (if ever) they worked. If
> you don't find any CCExtractor version that worked, you can give VLC a
> try - sometimes CCExtractor has been proven incorrect by VLC doing a
> correct playback.
> - Anshul, complete the DVB part (in spupng), when ready we'll ask
> Helen Huus to validate.
> - Ruslan, for errors reported by Willem see if you are able to find
> out how to fix them (when there's a previous CCExtractor version that
> worked OK it's of course a matter of comparing source code and patient
> analysis).
>
> When this is done we're releasing 0.70 - I'm quite excited about this
> since it will be our first GSOC release and GSOC is just getting
> started.
>
> I'd like this version to be released in a week or so (maybe next
> Wednesday) IF we are sure it's a good one.
>
> My own status - I will be away from Thursday to Sunday. As always,
> email and whatsapp will work but I won't be able to actually test
> stuff. I'll catch up on Monday.
>
> Finally, all of you have received the book already - hope you enjoy
> it. As I said before it's not too technical (yet the 608 pages were
> quite useful to me) but it gives you a global view of closed
> captioning which I think is interesting to have.
>
>
>
> On Wed, May 21, 2014 at 12:01 AM, Willem Van Iseghem
> <wil...@gm...> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hello all,
> >
> > I just combed through all the files that were in the Regression folder
> > (I'll generate samples for the other folders in the repository in the
> > coming days), and I found out that there are a couple files broken:
> >
> > - - Regression / Correct / With XDS / images.mpg
> >         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
> >         -> broken since: 0.67 (0.66 is fine)
> > - - Regression / Correct / With XDS / victoria.justice.ts
> >         -> commandline: -autoprogram -out=srt -latin1 -ucla
> >         -> broken since: 0.66 (0.65 is fine)
> > - - Regression / Need fixing /
> > b1f48f41ed9dfdfc55078395abaef533.20110812151000.ts
> >         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
> >         -> broken since: < 0.61 (can't compile 0.60 on server)
> >
> > This one is a little questionable, but the contents of the srt seem to
> > match what actually is being said.
> >
> > - - Regression / No CC stream found /
> > SplurgeandSave-S01E10-TimelessTraditionalFamilyRoom-5052453-0.mpg
> >         -> commandline: -autoprogram -out=srt -latin1
> >         -> broken since: < 0.61 (must have worked at some point, or with
> a
> > special option? Regression folder contains srt with captions)
> > - - Regression / No CC stream found / other files
> >         -> broken since: < 0.61 (never seem to have worked, txt's are
> empty)
> >
> > I've also run the current git built against the 0.69 files, and it has
> > no changes except for:
> > - - Regression / Minor issues /
> > 163ce77200976977847a5d66a537871b.20110901205100.mpg
> >         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
> >         -> broken since: 0.70 (0.69 is fine)
> >         -> what is broken?
> "19700101000000.100|19700101000003.236|CC1|POP|? "
> > disappeared.
> > - - Regression / Correct / With XDS / images.mpg
> >         -> what? Just more mangled than 0.69, but 0.69 (as described
> above)
> > is already broken.
> >
> >
> > I'll be updating this list with the other files as soon as I've
> > processed them :)
> >
> > Sincerely,
> > Willem
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJTe9CmAAoJEER4GtAYK/sNMcQH/0gIToOh4f4QSxmyiTK/L5Oe
> > 00ipwhsym8BzzU8abqYXmae46gKLcKLCx0nladwvgfUJE3Wzo+qOwOUJQFnrBBip
> > Yx66CETDVx9PXXiyz1HZySsgCYNhA99bp13R0fxnTv8X41c78hUFYMkVqRybWe+P
> > VrgPxYranOSgH3j9yz84R1WxUCsSB6U8K7aR3bxmKU+QjuBo3wZ6+WW2YX2y9QeL
> > 9HkW+KpCGrUPO4Q4m5btsKbxfIbSnwDnF2PTKX6tcNLoAFlj0VtlXQ4HlWXHMVGQ
> > 9GPdvdkIEZ0AtKoLs5bt0TKiMfqoLVdRDXV9woeAi2K4hLzj7R/QQtWyZYtUljc=
> > =YFsI
> > -----END PGP SIGNATURE-----
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > ccextractor-users mailing list
> > cce...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

Re: [ccextractor-users] [GSoC] Regression error list

[Carlos F. <cf...@gm...>]

OK, so here's what I think should be the immediate course of action:

- Willem, complete the tests as you say so we now exactly which tests
files are broken and when was the last time (if ever) they worked. If
you don't find any CCExtractor version that worked, you can give VLC a
try - sometimes CCExtractor has been proven incorrect by VLC doing a
correct playback.
- Anshul, complete the DVB part (in spupng), when ready we'll ask
Helen Huus to validate.
- Ruslan, for errors reported by Willem see if you are able to find
out how to fix them (when there's a previous CCExtractor version that
worked OK it's of course a matter of comparing source code and patient
analysis).

When this is done we're releasing 0.70 - I'm quite excited about this
since it will be our first GSOC release and GSOC is just getting
started.

I'd like this version to be released in a week or so (maybe next
Wednesday) IF we are sure it's a good one.

My own status - I will be away from Thursday to Sunday. As always,
email and whatsapp will work but I won't be able to actually test
stuff. I'll catch up on Monday.

Finally, all of you have received the book already - hope you enjoy
it. As I said before it's not too technical (yet the 608 pages were
quite useful to me) but it gives you a global view of closed
captioning which I think is interesting to have.



On Wed, May 21, 2014 at 12:01 AM, Willem Van Iseghem
<wil...@gm...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
>
> I just combed through all the files that were in the Regression folder
> (I'll generate samples for the other folders in the repository in the
> coming days), and I found out that there are a couple files broken:
>
> - - Regression / Correct / With XDS / images.mpg
>         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
>         -> broken since: 0.67 (0.66 is fine)
> - - Regression / Correct / With XDS / victoria.justice.ts
>         -> commandline: -autoprogram -out=srt -latin1 -ucla
>         -> broken since: 0.66 (0.65 is fine)
> - - Regression / Need fixing /
> b1f48f41ed9dfdfc55078395abaef533.20110812151000.ts
>         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
>         -> broken since: < 0.61 (can't compile 0.60 on server)
>
> This one is a little questionable, but the contents of the srt seem to
> match what actually is being said.
>
> - - Regression / No CC stream found /
> SplurgeandSave-S01E10-TimelessTraditionalFamilyRoom-5052453-0.mpg
>         -> commandline: -autoprogram -out=srt -latin1
>         -> broken since: < 0.61 (must have worked at some point, or with a
> special option? Regression folder contains srt with captions)
> - - Regression / No CC stream found / other files
>         -> broken since: < 0.61 (never seem to have worked, txt's are empty)
>
> I've also run the current git built against the 0.69 files, and it has
> no changes except for:
> - - Regression / Minor issues /
> 163ce77200976977847a5d66a537871b.20110901205100.mpg
>         -> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
>         -> broken since: 0.70 (0.69 is fine)
>         -> what is broken? "19700101000000.100|19700101000003.236|CC1|POP|? "
> disappeared.
> - - Regression / Correct / With XDS / images.mpg
>         -> what? Just more mangled than 0.69, but 0.69 (as described above)
> is already broken.
>
>
> I'll be updating this list with the other files as soon as I've
> processed them :)
>
> Sincerely,
> Willem
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTe9CmAAoJEER4GtAYK/sNMcQH/0gIToOh4f4QSxmyiTK/L5Oe
> 00ipwhsym8BzzU8abqYXmae46gKLcKLCx0nladwvgfUJE3Wzo+qOwOUJQFnrBBip
> Yx66CETDVx9PXXiyz1HZySsgCYNhA99bp13R0fxnTv8X41c78hUFYMkVqRybWe+P
> VrgPxYranOSgH3j9yz84R1WxUCsSB6U8K7aR3bxmKU+QjuBo3wZ6+WW2YX2y9QeL
> 9HkW+KpCGrUPO4Q4m5btsKbxfIbSnwDnF2PTKX6tcNLoAFlj0VtlXQ4HlWXHMVGQ
> 9GPdvdkIEZ0AtKoLs5bt0TKiMfqoLVdRDXV9woeAi2K4hLzj7R/QQtWyZYtUljc=
> =YFsI
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users

Re: [ccextractor-users] [ISSUE] lseek64 does not work on my 32-bit system

[Carlos F. <cf...@gm...>]

OK... let's take care of this. Please send me a patch that doesn't
break CCExtractor for Windows or 64 bits linux :-)

On Wed, May 21, 2014 at 8:15 AM, anshul <ans...@gm...> wrote:
> HI
>
> I wrote small program to test lseek64 on my system,
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <fcntl.h>
> #include <stdio.h>
> int main(int argc, char*argv[])
> {
>
>     off_t var;
>     int fd = open(argv[1],O_RDONLY);
>     if (fd < 0)
>     {
>         perror("open");
>         return -1;
>     }
>
>     var = LSEEK(fd,0,SEEK_END);
>     perror("lseek");
>
>     printf("%jd \n",var);
>     return 0;
>
> }
>
>
> previously our system was running, since it was getting compiled using cpp
> and file size was valid
> [anshul@daku_daddy C]$ g++ -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek64
> lseek.c
> [anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
> lseek: Success
> 5054653440
>
> after changing to c, compiler doe not get correct declaration of lseek64 and
> middle argument
> is not typecasted before passing,and at compile time it give warning and run
> time error.
> [anshul@daku_daddy C]$ gcc -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek64
> lseek.c
> lseek.c: In function ‘main’:
> lseek.c:17:2: warning: implicit declaration of function ‘lseek64’
> [-Wimplicit-function-declaration]
> [anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
> lseek: Invalid argument
> -1
>
> over here if you look lseek(not lseek64) with FILE_OFFSET_BITS macro works
> on my system.
> [anshul@daku_daddy C]$ gcc -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek
> lseek.c
> [anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
> lseek: Success
> 5054653440
>
>
> There was another thing that i noticed, if i typecast "0" offset to long
> long, i don't get
>  invalid argument error.
>
>
> On 05/21/2014 10:13 AM, anshul wrote:
>
> Hi
>
> lseek64 return -1 at run time and while compiling compiler gives following
> warning.
> gcc -c -Wno-write-strings -DGPAC_CONFIG_LINUX -D_FILE_OFFSET_BITS=64
> -I../src/gpacmp4/ -I../src/libpng -I../src/zlib -O3 -std=gnu99
> ../src/file_functions.c -o objs/file_functions.o
> ../src/file_functions.c: In function ‘getfilesize’:
> ../src/file_functions.c:14:5: warning: implicit declaration of function
> ‘lseek64’ [-Wimplicit-function-declaration]
> ../src/file_functions.c: In function ‘gettotalfilessize’:
> ../src/file_functions.c:31:9: warning: implicit declaration of function
> ‘open64’ [-Wimplicit-function-declaration]
>
>
> I have gone through man 7 feature_test_macro on linux , in which i
> interpreted that no need to use xxxx64,
> linux will do those things automatically if _FILE_OFFSET_BITS=64 is defined.
>
>
> following is variables from linux manuals:
>
> _LARGEFILE64_SOURCE:
>
> Expose definitions for the alternative API specified by the LFS (Large File
> Summit) as a "transitional extension" to the Single UNIX Specification.
> (See ⟨http://opengroup.org/platform/lfs.html⟩) The alternative API consists
> of a set of new objects (i.e., functions and  types) whose  names  are
> suffixed  with  "64"  (e.g., off64_t versus off_t, lseek64() versus lseek(),
> etc.).  New programs should not employ this interface; instead
> _FILE_OFFSET_BITS=64 should be employed.
>
>
>
> _FILE_OFFSET_BITS:
>
> Defining this macro with the value 64 automatically converts references to
> 32-bit functions and data types related to  file  I/O  and  file system
> operations into references to their 64-bit counterparts.  This is useful for
> performing I/O on large files (> 2 Gigabytes) on 32-bit systems.  (Defining
> this macro permits correctly written programs to use large files with only a
> recompilation  being  required.)   64-bit systems naturally permit file
> sizes greater than 2 Gigabytes, and on those systems this macro has no
> effect.
>
>
> As our test server is 64bit the same issue is not reproduced there.
>
> Thanks
> Anshul
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

Re: [ccextractor-users] [ISSUE] lseek64 does not work on my 32-bit system

[anshul <ans...@gm...>]

HI

I wrote small program to test lseek64 on my system,
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
int main(int argc, char*argv[])
{

     off_t var;
     int fd = open(argv[1],O_RDONLY);
     if (fd < 0)
     {
         perror("open");
         return -1;
     }

     var = LSEEK(fd,0,SEEK_END);
     perror("lseek");

     printf("%jd \n",var);
     return 0;

}


previously our system was running, since it was getting compiled using 
cpp and file size was valid
[anshul@daku_daddy C]$ g++ -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek64 
lseek.c
[anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
lseek: Success
5054653440

after changing to c, compiler doe not get correct declaration of lseek64 
and middle argument
is not typecasted before passing,and at compile time it give warning and 
run time error.
[anshul@daku_daddy C]$ gcc -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek64 
lseek.c
lseek.c: In function 'main':
lseek.c:17:2: warning: implicit declaration of function 'lseek64' 
[-Wimplicit-function-declaration]
[anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
lseek: Invalid argument
-1

over here if you look lseek(not lseek64) with FILE_OFFSET_BITS macro 
works on my system.
[anshul@daku_daddy C]$ gcc -Wall -D_FILE_OFFSET_BITS=64 -DLSEEK=lseek 
lseek.c
[anshul@daku_daddy C]$ ./a.out ~/Videos/testfile_5GB
lseek: Success
5054653440


There was another thing that i noticed, if i typecast "0" offset to long 
long, i don't get
  invalid argument error.

On 05/21/2014 10:13 AM, anshul wrote:
> Hi
>
> lseek64 return -1 at run time and while compiling compiler gives 
> following warning.
> gcc -c -Wno-write-strings -DGPAC_CONFIG_LINUX -D_FILE_OFFSET_BITS=64  
> -I../src/gpacmp4/ -I../src/libpng -I../src/zlib -O3 -std=gnu99 
> ../src/file_functions.c -o objs/file_functions.o
> ../src/file_functions.c: In function 'getfilesize':
> ../src/file_functions.c:14:5: warning: implicit declaration of 
> function 'lseek64' [-Wimplicit-function-declaration]
> ../src/file_functions.c: In function 'gettotalfilessize':
> ../src/file_functions.c:31:9: warning: implicit declaration of 
> function 'open64' [-Wimplicit-function-declaration]
>
>
> I have gone through man 7 feature_test_macro on linux , in which i 
> interpreted that no need to use xxxx64,
> linux will do those things automatically if _FILE_OFFSET_BITS=64 is 
> defined.
>
>
> following is variables from linux manuals:
>
> _LARGEFILE64_SOURCE:
>
>     Expose definitions for the alternative API specified by the LFS
>     (Large File Summit) as a "transitional extension" to the Single
>     UNIX Specification.  (See
>     ?http://opengroup.org/platform/lfs.html?) The alternative API
>     consists of a set of new objects (i.e., functions and  types)
>     whose  names  are  suffixed  with  "64" (e.g., off64_t versus
>     off_t, lseek64() versus lseek(), etc.). New programs should not
>     employ this interface; instead _FILE_OFFSET_BITS=64 should be
>     employed.
>
>
>
> _FILE_OFFSET_BITS:
>
>     Defining this macro with the value 64 automatically converts
>     references to 32-bit functions and data types related to  file 
>     I/O  and  file system operations into references to their 64-bit
>     counterparts.  This is useful for performing I/O on large files (>
>     2 Gigabytes) on 32-bit systems.  (Defining this macro permits
>     correctly written programs to use large files with only a 
>     recompilation  being  required.)   64-bit systems naturally permit
>     file sizes greater than 2 Gigabytes, and on those systems this
>     macro has no effect.
>
>
> As our test server is 64bit the same issue is not reproduced there.
>
> Thanks
> Anshul
>

[ccextractor-users] [ISSUE] lseek64 does not work on my 32-bit system

[anshul <ans...@gm...>]

Hi

lseek64 return -1 at run time and while compiling compiler gives 
following warning.
gcc -c -Wno-write-strings -DGPAC_CONFIG_LINUX -D_FILE_OFFSET_BITS=64  
-I../src/gpacmp4/ -I../src/libpng -I../src/zlib -O3 -std=gnu99 
../src/file_functions.c -o objs/file_functions.o
../src/file_functions.c: In function 'getfilesize':
../src/file_functions.c:14:5: warning: implicit declaration of function 
'lseek64' [-Wimplicit-function-declaration]
../src/file_functions.c: In function 'gettotalfilessize':
../src/file_functions.c:31:9: warning: implicit declaration of function 
'open64' [-Wimplicit-function-declaration]


I have gone through man 7 feature_test_macro on linux , in which i 
interpreted that no need to use xxxx64,
linux will do those things automatically if _FILE_OFFSET_BITS=64 is defined.


following is variables from linux manuals:

_LARGEFILE64_SOURCE:

    Expose definitions for the alternative API specified by the LFS
    (Large File Summit) as a "transitional extension" to the Single UNIX
    Specification.  (See ?http://opengroup.org/platform/lfs.html?) The
    alternative API consists of a set of new objects (i.e., functions
    and  types) whose  names  are  suffixed  with  "64"  (e.g., off64_t
    versus off_t, lseek64() versus lseek(), etc.).  New programs should
    not employ this interface; instead _FILE_OFFSET_BITS=64 should be
    employed.



_FILE_OFFSET_BITS:

    Defining this macro with the value 64 automatically converts
    references to 32-bit functions and data types related to file  I/O 
    and  file system operations into references to their 64-bit
    counterparts.  This is useful for performing I/O on large files (> 2
    Gigabytes) on 32-bit systems.  (Defining this macro permits
    correctly written programs to use large files with only a
    recompilation  being  required.)   64-bit systems naturally permit
    file sizes greater than 2 Gigabytes, and on those systems this macro
    has no effect.


As our test server is 64bit the same issue is not reproduced there.

Thanks
Anshul

[ccextractor-users] [GSoC] Regression error list

[Willem V. I. <wil...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,

I just combed through all the files that were in the Regression folder
(I'll generate samples for the other folders in the repository in the
coming days), and I found out that there are a couple files broken:

- - Regression / Correct / With XDS / images.mpg
	-> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
	-> broken since: 0.67 (0.66 is fine)
- - Regression / Correct / With XDS / victoria.justice.ts
	-> commandline: -autoprogram -out=srt -latin1 -ucla
	-> broken since: 0.66 (0.65 is fine)
- - Regression / Need fixing /
b1f48f41ed9dfdfc55078395abaef533.20110812151000.ts
	-> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
	-> broken since: < 0.61 (can't compile 0.60 on server)

This one is a little questionable, but the contents of the srt seem to
match what actually is being said.

- - Regression / No CC stream found /
SplurgeandSave-S01E10-TimelessTraditionalFamilyRoom-5052453-0.mpg
	-> commandline: -autoprogram -out=srt -latin1
	-> broken since: < 0.61 (must have worked at some point, or with a
special option? Regression folder contains srt with captions)
- - Regression / No CC stream found / other files
	-> broken since: < 0.61 (never seem to have worked, txt's are empty)

I've also run the current git built against the 0.69 files, and it has
no changes except for:
- - Regression / Minor issues /
163ce77200976977847a5d66a537871b.20110901205100.mpg
	-> commandline: -autoprogram -out=ttxt -latin1 -ucla -xds
	-> broken since: 0.70 (0.69 is fine)
	-> what is broken? "19700101000000.100|19700101000003.236|CC1|POP|? "
disappeared.
- - Regression / Correct / With XDS / images.mpg
	-> what? Just more mangled than 0.69, but 0.69 (as described above)
is already broken.


I'll be updating this list with the other files as soon as I've
processed them :)

Sincerely,
Willem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTe9CmAAoJEER4GtAYK/sNMcQH/0gIToOh4f4QSxmyiTK/L5Oe
00ipwhsym8BzzU8abqYXmae46gKLcKLCx0nladwvgfUJE3Wzo+qOwOUJQFnrBBip
Yx66CETDVx9PXXiyz1HZySsgCYNhA99bp13R0fxnTv8X41c78hUFYMkVqRybWe+P
VrgPxYranOSgH3j9yz84R1WxUCsSB6U8K7aR3bxmKU+QjuBo3wZ6+WW2YX2y9QeL
9HkW+KpCGrUPO4Q4m5btsKbxfIbSnwDnF2PTKX6tcNLoAFlj0VtlXQ4HlWXHMVGQ
9GPdvdkIEZ0AtKoLs5bt0TKiMfqoLVdRDXV9woeAi2K4hLzj7R/QQtWyZYtUljc=
=YFsI
-----END PGP SIGNATURE-----

Re: [ccextractor-users] Real-time uploading

[Carlos F. <cf...@gm...>]

On Sun, May 18, 2014 at 6:38 PM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> subtitles. But I'm not sure how website would get real-time updates, I'll
> deal with it later.

This is tricky :-) Whatever you do, consider these requirements.

- Real time means real time, not every 5 minutes, or in bursts. It's
as-it-happens.
- Data needs to be received in order.
- The website needs real-time updates because we want to have
real-time data on the website. If I connect my CCExtractor in Spain to
the system you should be able to read transcripts from Russia as fast
as the network allows.
- Ideally the system should be fail resilent, i.e. if CCExtractor
can't connect to the website server to upload it should be able to
buffer the data to send when it's possible. This part might add lots
of complexity though. Unsure, so give it a thought.

About the website, it should be organized by some criteria that needs
discussion. For example it could be by country then by station name,
but I don't know if that's enough. Also some stations are available in
more than one country (for example via satellite).

Re: [ccextractor-users] Real-time uploading

[Ruslan K. <kuc...@gm...>]

Hello!


> To be honest I think using a plain transcript format (start and end
> time for each line and the line itself) would be enough :-) C

I agree. It's not difficult to switch to another format.

 The first case is the global repository. Here, CCExtractors around
> the world would sent the transcripts of stations as they are received.

 Ok, I will work on it. Fortunately, it is not too much to change. Just to
reverse server and client apps and to provide some files to store received
subtitles. But I'm not sure how website would get real-time updates, I'll
deal with it later.

Respectfully,
Ruslan Kuchumov.


On Sun, May 18, 2014 at 11:36 AM, Carlos Fernandez <cf...@gm...> wrote:

> To be honest I think using a plain transcript format (start and end
> time for each line and the line itself) would be enough :-) Check
> -ttxt as an example.
>
> If you prefer any other format you can, but I think it's best to keep
> it simple. We don't need more than the transcript (not colors,
> positions, etc). ttml is not that simple, and most importantly - to
> make a good use of it we'd need to convert the original data to ttml,
> which is a lot of work.
>
> About the architecture, in general. First let's discuss the real use
> case there's going to be do there's not a lot of work done for someone
> people won't use.
>
> a) The first case is the global repository. Here, CCExtractors around
> the world would sent the transcripts of stations as they are received.
> For this we are going to be need the ability of CCExtractor to send
> the data somewhere, and then a receiver that takes the data and
> archives it. We will also need a simple website where the data can be
> seen in real time.
> b) When I say "global" I don't mean unique. For example, universities
> may want to install their own system which they control completely,
> while corporations may want to have their own, and we may want to run
> one in ccextractor.org
> c) Another possibly cool use would be CCExtractor to CCExtractor
> direct. Here, there would be a CCExtractor instance connected directly
> to a tuner to get the raw data, send it via network to another
> CCExtractor, and that one would be generating the final file. This
> implementation has some advantages - for example, the receiver could
> decide how to store the data (maybe .srt, or maybe .raw, etc) so we
> wouldn't have to settle for ttml or transcript, etc. It has the
> disadvantage that we'd need to hookup the network code in a number of
> places, so it's a bit more complex.
>
> The case that Ruslan suggests which is a rebroadcast, I don't know if
> we care much about for now. It's cool, but would it be used?
>
>
>
>
>
>
>
>
>
>
>
> On Sun, May 18, 2014 at 11:24 AM, Ruslan Kuchumov <kuc...@gm...>
> wrote:
> > Hello everyone!
> >
> > I just have written some code on real-time uploading.
> > https://github.com/rkuchumov/ccextractor/tree/networking/src/networking
> >
> > I haven't integrated it to CCExtractor yet. Instead server application
> reads
> > caption data in ttml format from specified file with some delays and
> sends
> > it to clients.
> >
> > Is it OK to send data in ttml? Now clients receive only the content of
> <p>
> > tag, later I'll add header stuff as the first packet to be send to
> clients.
> >
> > Below is the main ideas:
> > Server is a forked process that would bind to the port and accept
> > connections. CCExtractror would send a signal to it when new data is
> written
> > to tmp file. Server sends this data to connected clients.
> >
> > When client app receives data, it may write it to specified file and
> send a
> > signal.
> >
> > Authentication: Server generates the password, clients must send this
> > password. If they don't match, server fall asleep for 1 sec. Pretty
> simple.
> >
> > What do you think?
> >
> > Respectfully,
> > Ruslan Kuchumov.
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> > available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > ccextractor-users mailing list
> > cce...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccextractor-users
> >
>

Re: [ccextractor-users] Real-time uploading

[Carlos F. <cf...@gm...>]

To be honest I think using a plain transcript format (start and end
time for each line and the line itself) would be enough :-) Check
-ttxt as an example.

If you prefer any other format you can, but I think it's best to keep
it simple. We don't need more than the transcript (not colors,
positions, etc). ttml is not that simple, and most importantly - to
make a good use of it we'd need to convert the original data to ttml,
which is a lot of work.

About the architecture, in general. First let's discuss the real use
case there's going to be do there's not a lot of work done for someone
people won't use.

a) The first case is the global repository. Here, CCExtractors around
the world would sent the transcripts of stations as they are received.
For this we are going to be need the ability of CCExtractor to send
the data somewhere, and then a receiver that takes the data and
archives it. We will also need a simple website where the data can be
seen in real time.
b) When I say "global" I don't mean unique. For example, universities
may want to install their own system which they control completely,
while corporations may want to have their own, and we may want to run
one in ccextractor.org
c) Another possibly cool use would be CCExtractor to CCExtractor
direct. Here, there would be a CCExtractor instance connected directly
to a tuner to get the raw data, send it via network to another
CCExtractor, and that one would be generating the final file. This
implementation has some advantages - for example, the receiver could
decide how to store the data (maybe .srt, or maybe .raw, etc) so we
wouldn't have to settle for ttml or transcript, etc. It has the
disadvantage that we'd need to hookup the network code in a number of
places, so it's a bit more complex.

The case that Ruslan suggests which is a rebroadcast, I don't know if
we care much about for now. It's cool, but would it be used?











On Sun, May 18, 2014 at 11:24 AM, Ruslan Kuchumov <kuc...@gm...> wrote:
> Hello everyone!
>
> I just have written some code on real-time uploading.
> https://github.com/rkuchumov/ccextractor/tree/networking/src/networking
>
> I haven't integrated it to CCExtractor yet. Instead server application reads
> caption data in ttml format from specified file with some delays and sends
> it to clients.
>
> Is it OK to send data in ttml? Now clients receive only the content of <p>
> tag, later I'll add header stuff as the first packet to be send to clients.
>
> Below is the main ideas:
> Server is a forked process that would bind to the port and accept
> connections. CCExtractror would send a signal to it when new data is written
> to tmp file. Server sends this data to connected clients.
>
> When client app receives data, it may write it to specified file and send a
> signal.
>
> Authentication: Server generates the password, clients must send this
> password. If they don't match, server fall asleep for 1 sec. Pretty simple.
>
> What do you think?
>
> Respectfully,
> Ruslan Kuchumov.
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

Re: [ccextractor-users] Real-time uploading

[Ruslan K. <kuc...@gm...>]

Hello Willem!

Thanks.

No, it is not possible. Now server and client apps are not really
customizable.
I think you are thinking of server as a program which receives subtitles
and probably stores them. But in my case, server process and broadcasts
subtitles. Clients receive them and do whatever they want.

You just reminded me about that worldwide repository idea. I think that
would require creating another completely different server-client
applications.

Respectfully,
Ruslan Kuchumov.



On Sun, May 18, 2014 at 9:44 AM, Willem van iseghem <
wil...@gm...> wrote:

> Hello,
>
> my personal opinion on your proposal is that it looks quite good.
>
> I have 1 questions though:
>
> Your current setup with ttml is fine, as long as the user only wishes to
> send the data to the server alone. Is it with your setup possible to
> simultaneously send to the server and save an ttxt (or srt, or ...) on the
> processing computer? Of course I don't know if that would be ever the case,
> but I was wondering.
>
> Sincerely,
> Willem
>
>
>
>
> 2014-05-18 11:24 GMT+02:00 Ruslan Kuchumov <kuc...@gm...>:
>
>> Hello everyone!
>>
>> I just have written some code on real-time uploading.
>> https://github.com/rkuchumov/ccextractor/tree/networking/src/networking
>>
>> I haven't integrated it to CCExtractor yet. Instead server application
>> reads caption data in ttml format from specified file with some delays and
>> sends it to clients.
>>
>> Is it OK to send data in ttml? Now clients receive only the content of
>> <p> tag, later I'll add header stuff as the first packet to be send to
>> clients.
>>
>> Below is the main ideas:
>> Server is a forked process that would bind to the port and accept
>> connections. CCExtractror would send a signal to it when new data is
>> written to tmp file. Server sends this data to connected clients.
>>
>> When client app receives data, it may write it to specified file and send
>> a signal.
>>
>> Authentication: Server generates the password, clients must send this
>> password. If they don't match, server fall asleep for 1 sec. Pretty simple.
>>
>> What do you think?
>>
>> Respectfully,
>> Ruslan Kuchumov.
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> ccextractor-users mailing list
>> cce...@li...
>> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>>
>>
>

Re: [ccextractor-users] Real-time uploading

[Willem v. i. <wil...@gm...>]

Hello,

my personal opinion on your proposal is that it looks quite good.

I have 1 questions though:

Your current setup with ttml is fine, as long as the user only wishes to
send the data to the server alone. Is it with your setup possible to
simultaneously send to the server and save an ttxt (or srt, or ...) on the
processing computer? Of course I don't know if that would be ever the case,
but I was wondering.

Sincerely,
Willem




2014-05-18 11:24 GMT+02:00 Ruslan Kuchumov <kuc...@gm...>:

> Hello everyone!
>
> I just have written some code on real-time uploading.
> https://github.com/rkuchumov/ccextractor/tree/networking/src/networking
>
> I haven't integrated it to CCExtractor yet. Instead server application
> reads caption data in ttml format from specified file with some delays and
> sends it to clients.
>
> Is it OK to send data in ttml? Now clients receive only the content of <p>
> tag, later I'll add header stuff as the first packet to be send to clients.
>
> Below is the main ideas:
> Server is a forked process that would bind to the port and accept
> connections. CCExtractror would send a signal to it when new data is
> written to tmp file. Server sends this data to connected clients.
>
> When client app receives data, it may write it to specified file and send
> a signal.
>
> Authentication: Server generates the password, clients must send this
> password. If they don't match, server fall asleep for 1 sec. Pretty simple.
>
> What do you think?
>
> Respectfully,
> Ruslan Kuchumov.
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>
>

[ccextractor-users] Real-time uploading

[Ruslan K. <kuc...@gm...>]

Hello everyone!

I just have written some code on real-time uploading.
https://github.com/rkuchumov/ccextractor/tree/networking/src/networking

I haven't integrated it to CCExtractor yet. Instead server application
reads caption data in ttml format from specified file with some delays and
sends it to clients.

Is it OK to send data in ttml? Now clients receive only the content of <p>
tag, later I'll add header stuff as the first packet to be send to clients.

Below is the main ideas:
Server is a forked process that would bind to the port and accept
connections. CCExtractror would send a signal to it when new data is
written to tmp file. Server sends this data to connected clients.

When client app receives data, it may write it to specified file and send a
signal.

Authentication: Server generates the password, clients must send this
password. If they don't match, server fall asleep for 1 sec. Pretty simple.

What do you think?

Respectfully,
Ruslan Kuchumov.

[ccextractor-users] Reminder

[Carlos F. S. <ca...@cc...>]

Reminder: GSOC starts officially on Monday!

The timeline says that Google will start issuing payments then.
Hopefully all 3 of you have already submitted whatever you needed to
submit.

If not, please do :-)

In case you are wondering, Google hasn't contacted me about anything.
I don't know if they do before actually doing the payments. If they do
I'll let you know.

19 May:
Students begin coding for their Google Summer of Code projects;

Google begins issuing initial student payments provided tax forms are
on file and students are in good standing with their communities.

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Carlos F. <cf...@gm...>]

Probably a good idea would be to have different check lists (each list
being a test files with file or directory names, allowing wildcards).
Sometimes we'll want to test everything, sometimes just specific files
we know that could be affected (for example if we changed the wtv
parser then we'll just want to test *.wtv).

These days we need to test everything because we're talking about
releasing a new version.



On Sat, May 17, 2014 at 1:58 PM, Willem van iseghem
<wil...@gm...> wrote:
> Hello,
>
> The last time I checked the Regression folder contained a lot of files and
> samples (/repository/Regression contains subfolders with Correct, Minor
> Issues, Needs fixing, No CC steam found, ...). But if you want to get all
> samples in the /repository checked, no problem either though :)
>
> As for the "naming" issue, Gmail automatically did that... I corrected it
> now ^^
>
> Willem
>
>
> 2014-05-17 13:20 GMT+02:00 Carlos Fernandez <cf...@gm...>:
>
>> No, everything should be tested :-) Regression contains just one file
>> that is known to work (the one I normally use when working with .ts)
>> but we really need to verify everything: Teletext, wtv, mpeg PS...
>> everything. Even those files that don't work are interesting because
>> somehow they could start to work if we fix things.
>>
>> By the way it seems like you have cce...@li...
>> as
>> "Carlos Fernandez Gsoc" rather than CCExtractor development list or
>> something like that :-)
>>
>>
>> On Sat, May 17, 2014 at 11:46 AM, Willem van iseghem
>> <wil...@gm...> wrote:
>> > Hello all,
>> >
>> > Thanks for the feedback.
>> >
>> > I think the option carlos suggested (path + timestamp) might be indeed
>> > the
>> > most interesting one, so I'll go with that one. I'll put it on top of
>> > each
>> > report, whether it be html or txt
>> >
>> > I'll be pulling the entire GIT to my computer (or the server, but then
>> > in
>> > local copy), and I'll build a test file for all the files... I assume
>> > that
>> > only the files in the Regression folder should be tested?
>> >
>> > Sincerely,
>> > Willem
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> > Instantly run your Selenium tests across 300+ browser/OS combos.
>> > Get unparalleled scalability from the best Selenium testing platform
>> > available
>> > Simple to use. Nothing to install. Get started now for free."
>> > http://p.sf.net/sfu/SauceLabs
>> > _______________________________________________
>> > ccextractor-users mailing list
>> > cce...@li...
>> > https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>> >
>
>

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Willem v. i. <wil...@gm...>]

Hello,

The last time I checked the Regression folder contained a lot of files and
samples (/repository/Regression contains subfolders with Correct, Minor
Issues, Needs fixing, No CC steam found, ...). But if you want to get all
samples in the /repository checked, no problem either though :)

As for the "naming" issue, Gmail automatically did that... I corrected it
now ^^

Willem


2014-05-17 13:20 GMT+02:00 Carlos Fernandez <cf...@gm...>:

> No, everything should be tested :-) Regression contains just one file
> that is known to work (the one I normally use when working with .ts)
> but we really need to verify everything: Teletext, wtv, mpeg PS...
> everything. Even those files that don't work are interesting because
> somehow they could start to work if we fix things.
>
> By the way it seems like you have cce...@li...
> "Carlos Fernandez Gsoc" rather than CCExtractor development list or
> something like that :-)
>
>
> On Sat, May 17, 2014 at 11:46 AM, Willem van iseghem
> <wil...@gm...> wrote:
> > Hello all,
> >
> > Thanks for the feedback.
> >
> > I think the option carlos suggested (path + timestamp) might be indeed
> the
> > most interesting one, so I'll go with that one. I'll put it on top of
> each
> > report, whether it be html or txt
> >
> > I'll be pulling the entire GIT to my computer (or the server, but then in
> > local copy), and I'll build a test file for all the files... I assume
> that
> > only the files in the Regression folder should be tested?
> >
> > Sincerely,
> > Willem
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> > available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > ccextractor-users mailing list
> > cce...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccextractor-users
> >
>

[ccextractor-users] Telxcc

[Carlos F. S. <ca...@cc...>]

Following the work in telxcc to make it compile as C, I sent an email
to Petr Kutalec which is the coder that wrote telxcc, in case he
wanted to get our patches.

He told me that telxcc has been discontinued and in fact the
repository have been deleted from github. So well, telxcc doesn't
exist anymore.

Of course we can continue to use what we have, but we are on our own
for teletext support.

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Carlos F. <cf...@gm...>]

No, everything should be tested :-) Regression contains just one file
that is known to work (the one I normally use when working with .ts)
but we really need to verify everything: Teletext, wtv, mpeg PS...
everything. Even those files that don't work are interesting because
somehow they could start to work if we fix things.

By the way it seems like you have cce...@li... as
"Carlos Fernandez Gsoc" rather than CCExtractor development list or
something like that :-)


On Sat, May 17, 2014 at 11:46 AM, Willem van iseghem
<wil...@gm...> wrote:
> Hello all,
>
> Thanks for the feedback.
>
> I think the option carlos suggested (path + timestamp) might be indeed the
> most interesting one, so I'll go with that one. I'll put it on top of each
> report, whether it be html or txt
>
> I'll be pulling the entire GIT to my computer (or the server, but then in
> local copy), and I'll build a test file for all the files... I assume that
> only the files in the Regression folder should be tested?
>
> Sincerely,
> Willem
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Willem v. i. <wil...@gm...>]

Hello all,

Thanks for the feedback.

I think the option carlos suggested (path + timestamp) might be indeed the
most interesting one, so I'll go with that one. I'll put it on top of each
report, whether it be html or txt

I'll be pulling the entire GIT to my computer (or the server, but then in
local copy), and I'll build a test file for all the files... I assume that
only the files in the Regression folder should be tested?

Sincerely,
Willem

[ccextractor-users] Migration to pure C

[Carlos F. S. <ca...@cc...>]

After some pain all files are now .c and they seem to build in both
GNU and Visual Studio.

Lots of files needed to be changed because of Visual Studio using C89
for .c files (so variables needs to be declared on top and things like
that).

Hopefully we (mostly Anshul and myself) didn't break anything in the
process, but please test.

Willem, if you could do a complete test run to compare 0.69 with my
current git it would help a lot to confirm we are still OK. No need
for a fancy report, just a simple "all identical" or "this is fucked"
will do (note: the test should compare several file formats, not just
srt).

If nothing is broken I'll ask Helen Huus (who did the spupng
implementation) to check it out (since libpng was updated, the C++
part of the code were changed and so on) and if she says everything is
OK I'll release this as 0.70 so we have again a stable code base to
continue working on.

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Carlos F. <cf...@gm...>]

On Fri, May 16, 2014 at 1:15 PM, anshul <ans...@gm...> wrote:
>
> if some user want to use our test suite, then he will having only binary
> in unix at /usr/bin and windows at system32, so path will not always
> suggest the version used to generate that output.

Nah, forget about some user :-) It's just us, developers. Users don't
bother with this stuff, they just email to complain. If we're lucky
they say something like "this file worked in 0.43 but I just upgraded
to 0.69 after 4 years and now it doesn't work".

Probably we'll have our own builds in our home directories and we want
to check that we didn't break something.

> - - Let the tester define the version he's running (either in a config
> file, or a command that needs to be passed)

Expect version not to be 0.69, or 0.70, but "Willem's build from git
at 2014-05-16".

> I don't know which one you'd prefer, and which one would be the best
> to distinguish several versions from each other.

I think path and timestamp.

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[anshul <ans...@gm...>]

On 05/16/2014 03:40 AM, Willem Van Iseghem wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 15/05/2014 7:49, Carlos Fernandez wrote:
>> On Thu, May 15, 2014 at 12:52 AM, Willem Van Iseghem
>> <wil...@gm...> wrote:
>>> 1) (default) is the HTML report generator. It generates reports
>>> based
>> I think this one should include information such as how the
>> correct file was generated (i.e. which CCExtractor version did it)
>> so if we generate a wrong file we can compare the code to find out
>> what we broke.
> I think this could be achieved in multiple ways:
> - - Show the location of the CCExtractor executable, providing each
> version is in it's own folder (eg CCExtractor-0.70, CCExtractor-0.75b,
> CCExtractor-0.70-anshul, ...)
if some user want to use our test suite, then he will having only binary
in unix at /usr/bin and windows at system32, so path will not always
suggest the version used to generate that output.
> - - Use the first line of the output of an CCExtractor file run to show
> the version... The first line currently outputs "CCExtractor 0.69,
> Carlos Fernandez Sanz, Volker Quetschke.", so if this is maintained
> through the next versions, this could be used
This would be possible for keeping track of version being tested
but we will not have all ccextractor binary used to generate the
reference output.
> - - Let the tester define the version he's running (either in a config
> file, or a command that needs to be passed)
he will not always know or remember which version was used
for generating reference output.
> I don't know which one you'd prefer, and which one would be the best
> to distinguish several versions from each other.
we can keep a file as a record which reference output was generated by 
which version.

we can start adding some comment in all output subtitle files, using 
which we can track
which version was used to generate this. and can also be the publicity 
stunt , so that all
user using subtitle generated by ccextractor know that this file was 
generated by
ccextractor.
>>> A disadvantage of the html is that it grows large pretty fast
>>> when you
>> Do you have everything preloaded in the html or load on demand?
> Right now everything is preloaded, because my idea is that the html
> file should contain, just like a txt report, everything... What I
> probably will do to cut down on size, is ignoring files with 0
> changes. If a file is an exact match to another, there's no need to
> include the "differ", which is what's taking up all the space, inside
> the report. Still, if you'd manage to break every single file during a
> test-run, the file would be quite big.
>
>>> process a lot of files or some really large output files. the TXT
>>> is smaller, but (imho) visually less interesting.
>> The txt might be convenient to cut and paste in email, for
>> example. Anyway it's a "professional" tool :-) It needs to assist
>> in verifying that we didn't break things with changes, that's all.
>> If it does the job well then that's all that's needed.
>>
> Both options are available, and adding a html file to an email is not
> that hard I think. But indeed, the goal is to be easily identify
> issues, no matter the report.
>
> There are log-files provided as well, that in debug mode capture all
> the output from the CCExtractor process as well...
>
>
If you are looking to upload the status of whether changes
break anything or not then please have a look at this link 
<http://fate.ffmpeg.org/>
but if only developer of ccextractor are going to use, then
just a pass report or output in any format is acceptable.

I have question:
if only developer are going to use this testing tool, then do we really
need to upload the result, we can test our code and if we find any error
we can correct them.

Above are just my opinion. :)

Thanks
Anshul

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Willem V. I. <wil...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/05/2014 7:49, Carlos Fernandez wrote:
> On Thu, May 15, 2014 at 12:52 AM, Willem Van Iseghem 
> <wil...@gm...> wrote:
>> 
>> 1) (default) is the HTML report generator. It generates reports
>> based
> 
> I think this one should include information such as how the
> correct file was generated (i.e. which CCExtractor version did it)
> so if we generate a wrong file we can compare the code to find out
> what we broke.

I think this could be achieved in multiple ways:
- - Show the location of the CCExtractor executable, providing each
version is in it's own folder (eg CCExtractor-0.70, CCExtractor-0.75b,
CCExtractor-0.70-anshul, ...)
- - Use the first line of the output of an CCExtractor file run to show
the version... The first line currently outputs "CCExtractor 0.69,
Carlos Fernandez Sanz, Volker Quetschke.", so if this is maintained
through the next versions, this could be used
- - Let the tester define the version he's running (either in a config
file, or a command that needs to be passed)

I don't know which one you'd prefer, and which one would be the best
to distinguish several versions from each other.


> 
>> A disadvantage of the html is that it grows large pretty fast
>> when you
> 
> Do you have everything preloaded in the html or load on demand?

Right now everything is preloaded, because my idea is that the html
file should contain, just like a txt report, everything... What I
probably will do to cut down on size, is ignoring files with 0
changes. If a file is an exact match to another, there's no need to
include the "differ", which is what's taking up all the space, inside
the report. Still, if you'd manage to break every single file during a
test-run, the file would be quite big.

> 
>> process a lot of files or some really large output files. the TXT
>> is smaller, but (imho) visually less interesting.
> 
> The txt might be convenient to cut and paste in email, for
> example. Anyway it's a "professional" tool :-) It needs to assist
> in verifying that we didn't break things with changes, that's all.
> If it does the job well then that's all that's needed.
> 

Both options are available, and adding a html file to an email is not
that hard I think. But indeed, the goal is to be easily identify
issues, no matter the report.

There are log-files provided as well, that in debug mode capture all
the output from the CCExtractor process as well...

Sincerely,
Willem
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTdTtqAAoJEER4GtAYK/sNxGAIALWc7xoGJ7KtOt1O9z89D/v7
1bIHLsHkslgmFiUlGYSOFItl/m9+RT4rnsM7Y07ql6HwuaJ/C94XR6D8bD/lkHd5
wlvoNnunTKDIEt/qBKsWObNkxg7k/B1DjI7SGoL4GDGj9ctJsa0F1f/LHBtam/Ri
GVnjnKZu4Mdhafm9op+p55Q+4DAE/fMLrZiDwzlotJEcGx/rAKtvt5nVUhrDNe7N
3COObktdHLZyuCiZtz8/XcMsPJFYcu9I3i9edGqg7yxBULFrZgQYcE/09OVEuZfc
42v08q8x1hQB4g11+RChByeXeU3Sm3TcFcPpVdxM5jkP61RLi99ibHo9rZs7E+U=
=x3Xn
-----END PGP SIGNATURE-----

Re: [ccextractor-users] [Test program] Feedback wanted on reports

[Carlos F. <cf...@gm...>]

On Thu, May 15, 2014 at 12:52 AM, Willem Van Iseghem
<wil...@gm...> wrote:
>
> 1) (default) is the HTML report generator. It generates reports based

I think this one should include information such as how the correct
file was generated (i.e. which CCExtractor version did it) so if we
generate a wrong file we can compare the code to find out what we
broke.

> A disadvantage of the html is that it grows large pretty fast when you

Do you have everything preloaded in the html or load on demand?

> process a lot of files or some really large output files. the TXT is
> smaller, but (imho) visually less interesting.

The txt might be convenient to cut and paste in email, for example.
Anyway it's a "professional" tool :-) It needs to assist in verifying
that we didn't break things with changes, that's all. If it does the
job well then that's all that's needed.