ccextractor-users — General ccextractor list.

[ccextractor-users] [GSoC] Test suite - latest test round - Including Ruslan's patch

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

Hello all,

I've ran the latest version of CCExtractor from Github, and then the latest
with Ruslan's patch.

I'll give an overview of the broken files:

Current github repo (compared to 0.69, and verified to be worse than 0.69):

Regression/Correct/No XDS/CBLT.mpg
Regression/Correct/No XDS/glenn_beck_20110425_1657.ts
Regression/Correct/With XDS/CCSample1.mpg
Regression/Correct/With XDS/images.mpg
Regression/Correct/With
XDS/The.Colbert.Report.2011-09-12.1080i.HDTV.MPEG-2-CtrlHD.ts
Regression/Correct/With
XDS/The.Daily.Show.with.Jon.Stewart.2011-09-08.1080i.HDTV.MPEG-2-CtrlHD-xds-solo-content-advisory.ts
Regression/Correct/With XDS/WLS.mpg
Regression/Minor issues/163ce77200976977847a5d66a537871b.20110901205100.mpg

Ruslan's victoria_justice branch (compared to 0.69, verified to be worse
than 0.69):

Regression/Correct/No XDS/CBLT.mpg
Regression/Correct/With XDS/images.mpg
Regression/Minor issues/163ce77200976977847a5d66a537871b.20110901205100.mpg

To be 100% sure, I cloned the latest github to my own repository, applied
Ruslan's patch, built it and ran the tests again. The results were the
same, so I think Ruslan did a very good job on the patch :)

I'm still working on threading the test suite, it seems to be faster than
no threading, but I'm not sure if it's (long term) good for your HDD though
:p

Once I finished it I'll leave the user the choice between threading and
non-threading.

Sincerely,
Willem

[ccextractor-users] Leaving

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

Guys,

I'm leaving for the US in a few hours. From June 1 until June 29 I
will be in the PST timezone (probably working on CET time until the
body adapts though).

So thoughts:

0.70 wasn't ready on time. I don't care much, there's lots of good
work done and there's no point in rushing things. I really want 0.70
to be a very good release, meaning it deals with all files we have in
the repository (except the broken ones which might be there).

The mid-term evaluation is in 3 weeks. I will be still in the US but
of course I'll do my job :-) This is the first time I have to do it so
I don't have any experience but apparently it's just Fail or Pass.
Everyone if working great so this is a non-issue. But if they ask
anything else I'll let you know.

I will have a phone in the US, with whatsapp, the number is in the
resource document.

The CHANGES.TXT document needs to be updated with the stuff you guys
have been doing.

Willem's test stuff, when everyone's happy about it, should be
packaged so we can release it.

There's a number of issues in github's issue tracker. I've assigned
some of them, and the rest are there for whoever wants them. If
there's something you feel like doing by all means go for it.

Pull requests: I've applied/pushed Anshul's today's one. There's one
pending from Ruslan, which looks good, but often following the
standards means breaking support for non-compliant streams, which
suck. So I'm waiting for Willem's report on that patch before
including it.

The GSOC summit lottery: Did you guys apply?

The mailing list: Unsure if everyone's on it which is why I'm emailing
everyone directly on top of sending it to the list.

I think this is all :-)

Carlos

Re: [ccextractor-users] quantization of colors and improvement in timing

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

Pull request? :-)

On Sat, May 31, 2014 at 5:49 PM, Anshul Maheshwari
<ans...@gm...> wrote:
> Hi
> I have done quantization of colors so that spumux which supports not more
> then 3 color can use output to mux output in dvd.
>
> I have also done some twiking  of timing for dvb subtitles.
>
> two patch are attached
> Thanks
> Anshul
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

[ccextractor-users] quantization of colors and improvement in timing

[Anshul M. <ans...@gm...>]

Hi
I have done quantization of colors so that spumux which supports not more
then 3 color can use output to mux output in dvd.

I have also done some twiking  of timing for dvb subtitles.

two patch are attached
Thanks
Anshul

Re: [ccextractor-users] [GSoC] Tests on latest github

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

On Fri, May 30, 2014 at 9:50 AM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> Why do we ignore parity bits? Data may be corrupted so we should skip it.

Because experience showed that it worked better with the existing samples :-)

Re: [ccextractor-users] [GSoC] Tests on latest github

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

Hello!

>From CEA-608-E:

This doesn't really tell whether we should reset column or not.
ZVBI doesn't reset.

It will come to you :-)

Why do we ignore parity bits? Data may be corrupted so we should skip it.

Respectfully,
Ruslan Kuchumov.


On Thu, May 29, 2014 at 3:03 PM, Carlos Fernandez <cf...@gm...> wrote:

> On Thu, May 29, 2014 at 4:53 PM, Ruslan Kuchumov <kuc...@gm...>
> wrote:
> >
> > remove column=0 when receive roll-up again, then everything is OK. I
> have no
> > idea what's wrong. In debug mode it shows this sequence: RU, CR, PAC,
> text1,
> > RU, text2. So text2 overlaps text1. I even checked parity bits. Maybe
> it's
>
> From CEA-608-E:
> Proper order of data
> B.8.1 Roll-Up Style
> Precede each new row of text with these three codes:
> RU2 or RU3 or RU4 (to set roll-up style and depth)
> CR (to roll the display up one row)
> PAC (to set the indent and base row)
> To relocate the roll-up display immediately, send a PAC which implies
> the new base row. To continue painting the current row, assuming the
> relocation occurred in the middle of a row, the PAC used should indent
> to the same column number where the cursor resided prior to the move
> or to the nearest indent to the left of that column. The service
> provider should then either re-send enough characters to return the
> cursor to its original column, or use the appropriate Tab Offset
> command to move the cursor there.
>
> > In VLC it doesn't work either, VLC's 608 is based on CCExtractor.
>
> Damn. That's a problem of being the reference implementation I guess.
> There's also another place to look -
> http://zapping.sourceforge.net/ZVBI/ . There's also a 608 decoder
> there. It's simpler (because it's intended for real time processing
> only) but it's clean and it seems to work well.
>
> > Just a request: don't use spaces in directories names.
>
> Totally agreed.
> >
> > I feel like I forgot to say something else, but I can't remember :)
> >
> It will come to you :-)
>

Re: [ccextractor-users] [GSoC] Tests on latest github

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

On Thu, May 29, 2014 at 4:53 PM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> remove column=0 when receive roll-up again, then everything is OK. I have no
> idea what's wrong. In debug mode it shows this sequence: RU, CR, PAC, text1,
> RU, text2. So text2 overlaps text1. I even checked parity bits. Maybe it's

>From CEA-608-E:
Proper order of data
B.8.1 Roll-Up Style
Precede each new row of text with these three codes:
RU2 or RU3 or RU4 (to set roll-up style and depth)
CR (to roll the display up one row)
PAC (to set the indent and base row)
To relocate the roll-up display immediately, send a PAC which implies
the new base row. To continue painting the current row, assuming the
relocation occurred in the middle of a row, the PAC used should indent
to the same column number where the cursor resided prior to the move
or to the nearest indent to the left of that column. The service
provider should then either re-send enough characters to return the
cursor to its original column, or use the appropriate Tab Offset
command to move the cursor there.

> In VLC it doesn't work either, VLC's 608 is based on CCExtractor.

Damn. That's a problem of being the reference implementation I guess.
There's also another place to look -
http://zapping.sourceforge.net/ZVBI/ . There's also a 608 decoder
there. It's simpler (because it's intended for real time processing
only) but it's clean and it seems to work well.

> Just a request: don't use spaces in directories names.

Totally agreed.
>
> I feel like I forgot to say something else, but I can't remember :)
>
It will come to you :-)

[ccextractor-users] CHANGES.TXT

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

Guys, don't forget to update CHANGES.TXT with the relevant stuff
added. Right now it should nothing for 0.70 and lots of things have
been done already :-)

On a different note it seems like some students find it useful
personally to have their proposals, profiles, or whatever in the
official project pages. If anyone wants to have a page on
ccextractor.org for their CV or something else it's no problem at all.
We can have a "meet our GSOC students" or something like that.
Obviously it's up to each of you.

Finally - anyone plans to attend the GSOC summit in October? It's
expensive (since you have to pay for it yourself) but a once in a
lifetime opportunity to visit Google. And if you need a visa to enter
the US, Google will give you a nice invitation letter that makes it
really easy to get.

If it makes a difference, I plan to go.

Re: [ccextractor-users] [GSoC] Tests on latest github

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

On Wed, May 28, 2014 at 9:49 PM, Willem Van Iseghem
<wil...@gm...> wrote:
>
> Once 0.70 is officially out I think it might be a good idea to reorder
> the repository and create a new structure that is a little more
> logical (so a folder with all broken samples, one with working
> samples, subdivided by type or sample characteristics).

By all means do that already if you have a good structure you'd like
to use :-) I know it's a mess.

[ccextractor-users] [GSoC] Tests on latest github

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

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

Hello all,

I've been running all the tests again on the latest github (up to
commit 184eabb2e6d957e440c47643c41062be1098ae3f), and this is what I
found (today's run reports start with CCExtractor0.70a):

- - Most broken files from yesterday are fine again!
- - Regression/Correct/No XDS/CBLT.mpg has some mangling.
- - Regression/Correct/No XDS/glenn_beck_20110425_1657.ts shows
differences compared to 0.69. It seems some of the extracted captions
are gone with the github built, only at the beginning though (first 6
seconds). Less worse than yesterday though.
- - Regression/Correct/With XDS/CCSample1.mpg has one line missing.
- - Regression/Correct/With XDS/images.mpg still messed up worse than 0.69
- - Regression/Correct/With
XDS/The.Colbert.Report.2011-09-12.1080i.HDTV.MPEG-2-CtrlHD.ts has a
single line messed up
- - The.Daily.Show.with.Jon.Stewart.2011-09-08.1080 (same folder as
above), similar symptoms, one line messed up.
- - WLS.mpg is, as indicated by Ruslan earlier today, broken.
- - Regression/Minor
issues/163ce77200976977847a5d66a537871b.20110901205100.mpg lost the
one line it had. Probably similar to CCSample1.mpg

Once 0.70 is officially out I think it might be a good idea to reorder
the repository and create a new structure that is a little more
logical (so a folder with all broken samples, one with working
samples, subdivided by type or sample characteristics).

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

iQEcBAEBAgAGBQJThj3aAAoJEER4GtAYK/sNoCsH/1OEnJt7W4OBP/MbwWym49F8
rL7Efk58Trc0dzZsjVukj5WfwabzEWPdNPnBKJIffEy+k9Y1E9WcojzhR2gpLUUL
vtO3YVWdQLuGqAo0/NzMkXtUiRdV6Q4Wf6zAMs6eviCT6D9Y48JcMKFK62THxdfh
ToYcDs6j2wAcXKUsJ6nn8Zpcs03bN+ne1A4GF67XtPvPm412ZAPiQ4JJtnxkEUel
rR0FdAz1hm0EwDRZPfShOxn2laXRhzXXx74/YAcXtZX8z0LplDfHoS/o8O9loPhj
8gH2cQrfsYUwRZ5wbqUPQTOv8R8qtbyENRsm9fmpEZWV3KhM/ZcZURrM6iLvgNw=
=m8K0
-----END PGP SIGNATURE-----

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

On Wed, May 28, 2014 at 4:37 PM, Ruslan Kuchumov <kuc...@gm...> wrote:

> everything is OK. But we need to reset. I don't know where else to check
> this file.

What happens in VLC?

Only semi relevant part in CEA-608-E I could find:

C.10 Style Switching (Regulatory)
The FCC caption decoder rules are quite clear on how decoders should
respond to commands which
change the style from that which is currently displayed or most
recently received. The purpose of this
section is to summarize certain important aspects of the rules
relative to style switching.
The RCL command should have no effect except to select pop-on style.
If roll-up or paint-on style is in
effect, any displayed captioning shall be unaffected. The next data
shall be loaded into the non-displayed
memory.
Similarly, the RDC command has no effect except to select paint-on
style. Next data are written directly to
the display upon receipt. If other captioning is already on the
screen, the four-row limit is still in effect.
(See Section C.6 for processing a fifth row.)
The three roll-up commands -- RU2, RU3, and RU4 -- select roll-up
style and move the cursor to column
1. The FCC requires further that, if pop-on or paint-on captioning is
already present in either memory, it
shall be erased. This required erasure seems reasonable, since display
memory may have to be
reorganized in order to prepare for roll-up style.
The EOC command should have no effect except to (1) exchange displayed
and non-displayed memories
and (2) force the decoder into pop-on style (since EOC would make no
sense otherwise).

> There were already the condition for that (at line #535 ts_tables.c in
> master)

Not really. Consider this scenario: We first receive a PAT that
contains programs 2, 3, 4 and we are in autoprogram mode. We process
part of the stream, life is good, but at some point later we get a PAT
with programs 1 and 2. The current code could switch to program 1
(even if program 2 was selected before and it's still the PAT)
discarding whatever we have in the buffers and mixing output. Now if
that's not the definition of a shitty implimentation :-)

> Function parse_PMT() overwrites caption buffer variables.
> So, to fix this bug we should remove clearing of this vars when new pat is
> received.

Nope...ONLY if a new PAT is received and the new PAT data invalidates
the previous data (which I think only happens if our selected program
is gone).

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

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

Hello,

I'll make a branch of the tester and I'll see if I can make it run in
parallel. But indeed, if it's disk activity that is the bottleneck it
won't help a lot ^^

Willem


On 28/05/2014 12:17, Carlos Fernandez wrote:
> On Wed, May 28, 2014 at 12:04 PM, Ruslan Kuchumov
> <kuc...@gm...> wrote:
>> 
>> Yes. It was that wired conditions I didn't pay attention to. I
>> mean, if context->mode was already in roll-up and we received
>> roll-up again, then we should reset the cursor. These conditions
>> were messed up. I did't find anything about resetting column in
>> Robson's book.
> 
> I believe this document: 
> http://edocket.access.gpo.gov/cfr_2007/octqtr/pdf/47cfr15.119.pdf
> 
> Explains it. If not, of course EIA-608 should.
> 
>> By the way, I fetched repository and I didn't find the changes
>> about clearing after new PAT, but I pushed them. So images.mpg
>> still doesn't work.
> 
> Ah! Yes. Now I remember. If we're going to alter the PAT/PMT rules
> for clearing/not clearing let's do it correctly. If not, it will
> work for some files and fail for others and we're just going to
> change which files are in the correct/fail sets depending on the
> strategy.
> 
> Let's settle with clear when our PMT disappears from PAT (even if
> the PAT changes for different reasons, such as a new channel that
> we don't care about is added or removed), and (in the PMT code) if
> our elementary stream disappears, even if there's changing
> affecting other streams.
> 
>> Willem, your test suite is quite useful :) I have an idea. Since
>> each test execution doesn't depend on the others, it's possible
>> to do them in parallel to improve time.
> 
> It's worth checking out but my prediction is that parallel
> processing will make things worse, because the bottleneck is the
> disk, not the CPU - so processing several files at the same time
> will just make the HD heads move more :-)
> 
> Anyway let's see, this is one of the times I'd rather be wrong.
> 
> ------------------------------------------------------------------------------
>
> 
Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download http://p.sf.net/sfu/restlet 
> _______________________________________________ ccextractor-users
> mailing list cce...@li... 
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThfWpAAoJEER4GtAYK/sNtcMIAKycnDiwgY+d2sYcIOgtBUjI
Y7QwO266I7exS0P53xMH26Db+8wbLHX//6cn+D65BChaCC5LDSwseMCV8oYpafCE
qvrFUbNS0dGDf4gpjehlPrAz+Z8CZHQZU6IBZq3O6SoYl491XbAjbJbUQf/gZ7Ym
geyYQk5Il0UrIb+SW/sxlkapp2kSN6vtVbU0yXfFOua9sQwBnMnnYVzvpz+t5OmC
4ZgkBhTLOO2AvUoV3fmh35dkKl7xVDkZ7SHnTRZJdsPyHI+QegG2h/lCP+zwJ9XS
nTjlIYoPfx1TlSJFVs0RmxyYM1TtpwgqX2iEhiymfCqmUV+Dp74cZEvGpqN111I=
=p+dU
-----END PGP SIGNATURE-----

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

>
> Explains it. If not, of course EIA-608 should.

It seems that something wrong with WLS.mpg. If we reset cursor position
when we receive roll-up again then the output is wrong. If we don't reset,
everything is OK. But we need to reset. I don't know where else to check
this file.

Let's settle with clear when our PMT disappears from PAT

There were already the condition for that (at line #535 ts_tables.c in
master)

>   and (in the PMT code) if our
> elementary stream disappears, even if there's changing affecting other
> streams.

Function parse_PMT() overwrites caption buffer variables.
So, to fix this bug we should remove clearing of this vars when new pat is
received.

It's worth checking out but my prediction is that parallel processing
> will make things worse, because the bottleneck is the disk

Oh, indeed, that would not make it faster for sure.



On Wed, May 28, 2014 at 10:17 AM, Carlos Fernandez <cf...@gm...> wrote:

> On Wed, May 28, 2014 at 12:04 PM, Ruslan Kuchumov <kuc...@gm...>
> wrote:
> >
> > Yes. It was that wired conditions I didn't pay attention to. I mean, if
> > context->mode was already in roll-up and we received roll-up again, then
> we
> > should reset the cursor. These conditions were messed up. I did't find
> > anything about resetting column in Robson's book.
>
> I believe this document:
> http://edocket.access.gpo.gov/cfr_2007/octqtr/pdf/47cfr15.119.pdf
>
> Explains it. If not, of course EIA-608 should.
>
> > By the way, I fetched repository and I didn't find the changes about
> > clearing after new PAT, but I pushed them. So images.mpg still doesn't
> work.
>
> Ah! Yes. Now I remember. If we're going to alter the PAT/PMT rules for
> clearing/not clearing let's do it correctly. If not, it will work for
> some files and fail for others and we're just going to change which
> files are in the correct/fail sets depending on the strategy.
>
> Let's settle with clear when our PMT disappears from PAT (even if the
> PAT changes for different reasons, such as a new channel that we don't
> care about is added or removed), and (in the PMT code) if our
> elementary stream disappears, even if there's changing affecting other
> streams.
>
> > Willem, your test suite is quite useful :) I have an idea. Since each
> test
> > execution doesn't depend on the others, it's possible to do them in
> parallel
> > to improve time.
>
> It's worth checking out but my prediction is that parallel processing
> will make things worse, because the bottleneck is the disk, not the
> CPU - so processing several files at the same time will just make the
> HD heads move more :-)
>
> Anyway let's see, this is one of the times I'd rather be wrong.
>

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

On Wed, May 28, 2014 at 12:04 PM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> Yes. It was that wired conditions I didn't pay attention to. I mean, if
> context->mode was already in roll-up and we received roll-up again, then we
> should reset the cursor. These conditions were messed up. I did't find
> anything about resetting column in Robson's book.

I believe this document:
http://edocket.access.gpo.gov/cfr_2007/octqtr/pdf/47cfr15.119.pdf

Explains it. If not, of course EIA-608 should.

> By the way, I fetched repository and I didn't find the changes about
> clearing after new PAT, but I pushed them. So images.mpg still doesn't work.

Ah! Yes. Now I remember. If we're going to alter the PAT/PMT rules for
clearing/not clearing let's do it correctly. If not, it will work for
some files and fail for others and we're just going to change which
files are in the correct/fail sets depending on the strategy.

Let's settle with clear when our PMT disappears from PAT (even if the
PAT changes for different reasons, such as a new channel that we don't
care about is added or removed), and (in the PMT code) if our
elementary stream disappears, even if there's changing affecting other
streams.

> Willem, your test suite is quite useful :) I have an idea. Since each test
> execution doesn't depend on the others, it's possible to do them in parallel
> to improve time.

It's worth checking out but my prediction is that parallel processing
will make things worse, because the bottleneck is the disk, not the
CPU - so processing several files at the same time will just make the
HD heads move more :-)

Anyway let's see, this is one of the times I'd rather be wrong.

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

Hello!


>  It seems that the victoria_justice
> fix broke it in such a way that all detection of captions is gone.

Yes. It was that wired conditions I didn't pay attention to. I mean, if
context->mode was already in roll-up and we received roll-up again, then we
should reset the cursor. These conditions were messed up. I did't find
anything about resetting column in Robson's book. If we do reset
column, WLS.mpg fail. I'll create pull request in an hour, I tested it, and
it worked with correct files.

 I suspect this will explain why I was so
> aggressive cleaning after a changed PAT :-)

By the way, I fetched repository and I didn't find the changes about
clearing after new PAT, but I pushed them. So images.mpg still doesn't work.

Willem, your test suite is quite useful :) I have an idea. Since each test
execution doesn't depend on the others, it's possible to do them in
parallel to improve time. Maybe it'll better to fork a process for each
test and let OS to distribute CPU time between them. So, there is a chance
for tests to work simultaneously.

Respectfully,
Ruslan Kuchumov.




On Tue, May 27, 2014 at 7:41 PM, Carlos Fernandez <cf...@gm...> wrote:

> Ruslan, can you take a look? I suspect this will explain why I was so
> aggressive cleaning after a changed PAT :-)
>
> On Tue, May 27, 2014 at 9:07 PM, Willem Van Iseghem
> <wil...@gm...> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hello all,
> >
> > I just finished testing the latest github version with the testing
> > tool, and comparing them to the 0.69 output files.
> >
> > This is what I found (all reports can be checked here -
> > http://gsocdev.ccextractor.org/~willem/, they are named
> > CCExtractor0.70-*):
> >
> > Improved:
> > - - No XDS/CCSample2.mpg, it shows more details than before.
> > - - With XDS/Victoria justice.ts improved (seems to be of the same type
> > as the CCSample2), which was the intended result of the fix by Ruslan.
> >
> >
> > Broken or detoriated:
> > - - Quite a lot of files are broken. It seems that the victoria_justice
> > fix broke it in such a way that all detection of captions is gone.
> > Some files are now empty except for XDS information.
> >
> > I hope this will help to fix the things, and then, after checking
> > again, releasing a nice stable 0.70 version.
> >
> > Willem
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (MingW32)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> > iQEcBAEBAgAGBQJThOKGAAoJEER4GtAYK/sNs4UH/2BpGD5y7C5ykyJ3SzxF3spA
> > KVv1src/Frhz2tqTr4P/z5dFM6FBj/OXO4WuTY3nFZ1fmGsLkhLSjiAM7IS86aab
> > VOzLapVU/4zGP5veNwvcX1/f36/Jox3N1wE770BkRywlrtmmB/5t57JgCspPTkNR
> > GgMilquSw7ysC4EHzdNlToc957b2tWpwsOIdZ8lOvdl+uxzBzBl7uoH3Z3KhuqCS
> > 24NFdX1OkpRFKJsbr6++PdHE3waLnl8D+YhwJtyyseR5Oj/dhRmxZO0PZqg/Hzr9
> > Jtp5ZyBJ9Y8R1iepGtwqV2qYG669aOqK9gN4qpF5i6u+q0+3BcIcgL9DSQTAj28=
> > =hkBM
> > -----END PGP SIGNATURE-----
> >
> >
> ------------------------------------------------------------------------------
> > The best possible search technologies are now affordable for all
> companies.
> > Download your FREE open source Enterprise Search Engine today!
> > Our experts will assist you in its installation for $59/mo, no
> commitment.
> > Test it for FREE on our Cloud platform anytime!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> > _______________________________________________
> > ccextractor-users mailing list
> > cce...@li...
> > https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>
>
> ------------------------------------------------------------------------------
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users
>

Re: [ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

Ruslan, can you take a look? I suspect this will explain why I was so
aggressive cleaning after a changed PAT :-)

On Tue, May 27, 2014 at 9:07 PM, Willem Van Iseghem
<wil...@gm...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello all,
>
> I just finished testing the latest github version with the testing
> tool, and comparing them to the 0.69 output files.
>
> This is what I found (all reports can be checked here -
> http://gsocdev.ccextractor.org/~willem/, they are named
> CCExtractor0.70-*):
>
> Improved:
> - - No XDS/CCSample2.mpg, it shows more details than before.
> - - With XDS/Victoria justice.ts improved (seems to be of the same type
> as the CCSample2), which was the intended result of the fix by Ruslan.
>
>
> Broken or detoriated:
> - - Quite a lot of files are broken. It seems that the victoria_justice
> fix broke it in such a way that all detection of captions is gone.
> Some files are now empty except for XDS information.
>
> I hope this will help to fix the things, and then, after checking
> again, releasing a nice stable 0.70 version.
>
> Willem
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJThOKGAAoJEER4GtAYK/sNs4UH/2BpGD5y7C5ykyJ3SzxF3spA
> KVv1src/Frhz2tqTr4P/z5dFM6FBj/OXO4WuTY3nFZ1fmGsLkhLSjiAM7IS86aab
> VOzLapVU/4zGP5veNwvcX1/f36/Jox3N1wE770BkRywlrtmmB/5t57JgCspPTkNR
> GgMilquSw7ysC4EHzdNlToc957b2tWpwsOIdZ8lOvdl+uxzBzBl7uoH3Z3KhuqCS
> 24NFdX1OkpRFKJsbr6++PdHE3waLnl8D+YhwJtyyseR5Oj/dhRmxZO0PZqg/Hzr9
> Jtp5ZyBJ9Y8R1iepGtwqV2qYG669aOqK9gN4qpF5i6u+q0+3BcIcgL9DSQTAj28=
> =hkBM
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users

[ccextractor-users] [GSoC] Tests on current 0.70a build - conclusions

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

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

Hello all,

I just finished testing the latest github version with the testing
tool, and comparing them to the 0.69 output files.

This is what I found (all reports can be checked here -
http://gsocdev.ccextractor.org/~willem/, they are named
CCExtractor0.70-*):

Improved:
- - No XDS/CCSample2.mpg, it shows more details than before.
- - With XDS/Victoria justice.ts improved (seems to be of the same type
as the CCSample2), which was the intended result of the fix by Ruslan.


Broken or detoriated:
- - Quite a lot of files are broken. It seems that the victoria_justice
fix broke it in such a way that all detection of captions is gone.
Some files are now empty except for XDS information.

I hope this will help to fix the things, and then, after checking
again, releasing a nice stable 0.70 version.

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

iQEcBAEBAgAGBQJThOKGAAoJEER4GtAYK/sNs4UH/2BpGD5y7C5ykyJ3SzxF3spA
KVv1src/Frhz2tqTr4P/z5dFM6FBj/OXO4WuTY3nFZ1fmGsLkhLSjiAM7IS86aab
VOzLapVU/4zGP5veNwvcX1/f36/Jox3N1wE770BkRywlrtmmB/5t57JgCspPTkNR
GgMilquSw7ysC4EHzdNlToc957b2tWpwsOIdZ8lOvdl+uxzBzBl7uoH3Z3KhuqCS
24NFdX1OkpRFKJsbr6++PdHE3waLnl8D+YhwJtyyseR5Oj/dhRmxZO0PZqg/Hzr9
Jtp5ZyBJ9Y8R1iepGtwqV2qYG669aOqK9gN4qpF5i6u+q0+3BcIcgL9DSQTAj28=
=hkBM
-----END PGP SIGNATURE-----

Re: [ccextractor-users] [GSoC] Repository files vol. 2

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

Fingers crossed :-)

On Tue, May 27, 2014 at 12:11 AM, Willem Van Iseghem
<wil...@gm...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> I just finished up creating and testing all the samples in the
> repository, and I have the next additional findings:
>
> Others
>
> - - cal.mp4 does not produce anything, VLC doesn't show anything either.
> When processing with CCExtractor a lot of "Notice: NAL of type 1 had
> to be skipped because remove_03emu failed."
> - - cc2.mov & cc3.mov only produces output when using default (CC1). Not
> sure if this needs to produce output on CC2, VLC doesn't show any
> captions. cc3.mov shows loads of warnings about unsupported XDS packets.
> - - spanish.mpg seems to be not working. Only result is
> "Not a recognized header. Searching for next header.
> 00000000 | 01 E0 07 EE FF FF                                |  à îÿÿG
>
> Warning: Defective Pack header"
>
> norman_dahl
>
> Only 576-2316-24-ABC_News_24.mpg is generating no output, no matter
> what commands are used. VLC produces teletext subtitles
>
> Max Wrenn
>
> Both files produce no output. Storyville.ts contains DVB subtitles
> which VLC can play.
>
> Lakey-White
>
> File seems to produced incorrect timed SMI files indeed. VLC shows no
> subs.
>
> elderman
>
> Quite a lot of the samples (all samples) in this folder have incorrect
> timings (or timings are broken)
>
> danBhentschel
>
> Example is omitting lines. VLC is too. Is present since (at least)
> 0.63, but possibly not fixable.
>
> - -----------------------------------------------------------------------
>
> I'll be testing all files from the repository tomorrow morning against
> the current 0.70 branch, and I'll let everyone know which files
> changed compared to the ones that are broken now. I assume most DVB &
> TT issues will be solved, just like the images & victoria sample
> files. If all goes well, 0.70 will be able to released wednessday I
> guess :)
>
> Willem
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTg7wsAAoJEER4GtAYK/sNNfoH/0WGHF0aRT7/W9v0aQ+D0qnf
> ePAbaB5eZXAlBCnjSKIh9u8Vr4xfl4y0u26vdqvI5MZ1xTTL/WYl00AEe971RLDP
> DRyyIJA6+Lxg2iYSE+0Mh7l8VONXA0Yoymqdl2OS6H4WUl3tVmUskU2HvmW1AJQ5
> dCOegxsNvPc1uYNpgb3g+eu2Euz9mZR/xfqWy289TqN7MuhydhovBeceFc6gsX+x
> /c2NSEatde+dpdnu9nHPLsZb+uOJ9IBD1l3qanbTNokpg7zLUkFrUOFnYef3f2pV
> uzusBEW6a4yaxbXWi7/zQC2PJBMdyR9gYT09i9d3/cWsO3p1M8TL9Bujoi3MjVc=
> =LZzR
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> _______________________________________________
> ccextractor-users mailing list
> cce...@li...
> https://lists.sourceforge.net/lists/listinfo/ccextractor-users

[ccextractor-users] [GSoC] Repository files vol. 2

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

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

Hello,

I just finished up creating and testing all the samples in the
repository, and I have the next additional findings:

Others

- - cal.mp4 does not produce anything, VLC doesn't show anything either.
When processing with CCExtractor a lot of "Notice: NAL of type 1 had
to be skipped because remove_03emu failed."
- - cc2.mov & cc3.mov only produces output when using default (CC1). Not
sure if this needs to produce output on CC2, VLC doesn't show any
captions. cc3.mov shows loads of warnings about unsupported XDS packets.
- - spanish.mpg seems to be not working. Only result is
"Not a recognized header. Searching for next header.
00000000 | 01 E0 07 EE FF FF                                |  à îÿÿG

Warning: Defective Pack header"

norman_dahl

Only 576-2316-24-ABC_News_24.mpg is generating no output, no matter
what commands are used. VLC produces teletext subtitles

Max Wrenn

Both files produce no output. Storyville.ts contains DVB subtitles
which VLC can play.

Lakey-White

File seems to produced incorrect timed SMI files indeed. VLC shows no
subs.

elderman

Quite a lot of the samples (all samples) in this folder have incorrect
timings (or timings are broken)

danBhentschel

Example is omitting lines. VLC is too. Is present since (at least)
0.63, but possibly not fixable.

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

I'll be testing all files from the repository tomorrow morning against
the current 0.70 branch, and I'll let everyone know which files
changed compared to the ones that are broken now. I assume most DVB &
TT issues will be solved, just like the images & victoria sample
files. If all goes well, 0.70 will be able to released wednessday I
guess :)

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

iQEcBAEBAgAGBQJTg7wsAAoJEER4GtAYK/sNNfoH/0WGHF0aRT7/W9v0aQ+D0qnf
ePAbaB5eZXAlBCnjSKIh9u8Vr4xfl4y0u26vdqvI5MZ1xTTL/WYl00AEe971RLDP
DRyyIJA6+Lxg2iYSE+0Mh7l8VONXA0Yoymqdl2OS6H4WUl3tVmUskU2HvmW1AJQ5
dCOegxsNvPc1uYNpgb3g+eu2Euz9mZR/xfqWy289TqN7MuhydhovBeceFc6gsX+x
/c2NSEatde+dpdnu9nHPLsZb+uOJ9IBD1l3qanbTNokpg7zLUkFrUOFnYef3f2pV
uzusBEW6a4yaxbXWi7/zQC2PJBMdyR9gYT09i9d3/cWsO3p1M8TL9Bujoi3MjVc=
=LZzR
-----END PGP SIGNATURE-----

Re: [ccextractor-users] Dvb subtitle output spupng

[Anshul M. <ans...@gm...>]

Hi
i have attached 4 patch to give spupng output from dvb.
will send the pull request if every thing is ok here.
tested on linux.
tested with tudor video to see i have not broken any thing there.
tested with one dvb video too
not tested on windows.

there are some problem for dvb output if i give output directly to spumux.
but if i use mogrify -colors 3 sub00* in output directory, then output is
working with spumux.
I will remove mogrify dependency soon. :)

Thanks
Anshul

[ccextractor-users] [GSoC] Repository files

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

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

Hello,

I've been checking the folders (still downloading a part of the files
to my local pc), and so far I have the next constatations (for 0.69,
will be testing the current 0.70 build in the upcoming days):

- -------------------------------------------------------------
TGBrowning / Samples

I don't know what to make of the mp4 files... VLC says no subs,
CCExtractor can't find them either. No note describing issues?
The VIDEO_TS files generate ttxt's though. Maybe he wants to know why
it works with VIDEO_TS but not with the mp4's? My guess is something
went wrong while converting.

RonBass

Problem is no longer valid, though both samples are having one messed
line up. The mpg is a little better on that line.

RDVaughan

All files are failing in CCExtractor 0.69 (prematurely), just as in
v0.64 apparently.
VLC can read out DVB and or TT on the uk_dvb_example and
9015_20121015201700_LOSSLESS_BUG samples.
VLC can read out CC1 on 1031_20121009013000_LOSSLESS_BUG
VLC can read out nothing on the two other samples.

Rajiv

cc.mpg2 doesn't generate anything, but VLC doesn't show anything either.

ProtectedWTV

Can't play the file (copy restrictions -_-), but CCExtractor seems to
generate an transcript. Can't verify the correctness though.

pross

Both files generate captions, looking fine.

P2PFiend

Files generate captions.
- -----------------------------------------------------------------

I assume that with 0.70 and the implementation of DVB subs & fixes in
TT some of the issues will be solved... I'll keep you guys updated.

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

iQEcBAEBAgAGBQJTf7X9AAoJEER4GtAYK/sNetEIALUj3g7QQ/is8OTBgDHgoZbH
URxPYgFiykSurUzmkw98C3J5QK9sDeXsxhtStrEsDnJFerIAtEXqkIGiDOcANy+Q
QoymxWYpd6pMAvKC/wWmCB0U9HArupt3uXaZwH2A24Y/n/uVlf9ui5YRh7sphRJV
ZqgYnNbDbYBUY0OyEYjqHOBkXEnmlXVWZLE/ACUIi9RmpRKnJMtJqeMuUGUN8bPS
ke9KcQKoAxaFURdHcaZqZYe0B5brptl+b/+/z0/VqGpH2UvxPMeexbmxS9nbi38n
vsntltpXI8QsIBaD0oMMIrf8z0yyK5LK/qmiJJz0ac46byRHfhXnz+a89IcxawA=
=nEvV
-----END PGP SIGNATURE-----

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

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

On Thu, May 22, 2014 at 4:34 PM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> So the fix is to remove reset of ts_cappid and other variables after
> receiving new PAT, but reset pmt_array, pids_seen.

Keep in mind that PAT and PMT are transmitted every second or so
(otherwise you wouldn't be able to turn the TV on and start watching
any channel at any time). So clearing variables needs to be
implemented in a clever way, i.e. only when needed.

Has the PAT changed?
No => Don't reset
Yes => Has the PMT for the program you were watching disappeared?
No => Don't reset
Yes => Reset

Has the PMT changed?
No => Don't reset
Yes => Has the stream you were following for captions disappeared?
No => Don't reset
Yes => Reset

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

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

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

Hello Ruslan,

Thanks for trying to use the test suite.

The current setup has indeed an xml file with the files that need to
be tested. There is no option to test an entire directory without
specifying all files because of the various amount of parameters,
input and output possibilities CCExtractor has. The files in the
regression folder usually have a certain number of (unique) commands,
hence I chose to make the user have them entered one-by-one. If you
use Windows or Linux with a graphic shell you can use the GUI, which
will allow you to easily modify or add entries.

However, since I'm in progress of testing all the files in the
repository, I have (at this moment) all the files in the Regression
folder mapped in XML's. Below are the dropbox links to them:


https://www.dropbox.com/s/mhybx4hoimkokkb/Regression_Correct_No_XDS.xml
https://www.dropbox.com/s/9x1g9t6yfo74q2t/Regression_Correct_With_XDS.xml
https://www.dropbox.com/s/83uknxlfk6qiz2f/Regression_Correct_With_XDS_Canada.xml
https://www.dropbox.com/s/hvks1daphornzrv/Regression_Minor_Issues.xml
https://www.dropbox.com/s/zrziao7kjrmc8qf/Regression_Need_Fixing.xml
https://www.dropbox.com/s/w5sglobsmvnk0bo/Regression_No_CC_stream_found.xml
https://www.dropbox.com/s/e43jaodenufc66s/Regression_Teletext_-Scandinavia.xml

As far as the suggestion goes for the variable name, I'll update that
in the coming versions.

Sincerely,
Willem

On 22/05/2014 13:40, Ruslan Kuchumov wrote:
> 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... <mailto:cf...@gm...>> wrote:
> 
> On Thu, May 22, 2014 at 10:11 AM, Ruslan Kuchumov 
> <kuc...@gm... <mailto: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.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
"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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTfl/qAAoJEER4GtAYK/sNH34H/jvp5/5cR3G945CMyhlxeWWW
vDuIYv5vLSs3UfB6cJLqtzuYUGLk/okO0zIfYae2ImWhS9PRTfpiStLvDHukBfX+
mEwUXgTwtyB8hTzCU2UbPpPYlAduGal2HfgazOMwOmdNFyKTcDJnk/S9JWkdgSub
3+S0qi8ZDAz9NS63Saz5d4XyVcRfLDqcfVcn9AY2sn4n1S+u2ZEGtc9pGmUkBTII
8l48SDqLzSjk/JyrOS7rSSzcAX9NET1XGhkQGr8wnmCA/PZERpE8DMwZ9fCDiFlX
BP3k8qd0dDKdb2mVguUL9LDv8j292TWCF/w6Gf7vb4IxnhIjXEa3HohjFL8GCLU=
=K07D
-----END PGP SIGNATURE-----

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

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

>
> If our selected PMT disappears then we need
> to reset everything - the program we were "watching" is gone.

There are already a code to detect if program number changed and to reset
that variables. I'm not sure if we should clear buffer when program ends -
it may have last characters of that program.

Also, when the PMT changes if our selected stream disappears then we
> also have to reset everything.

In this case function parse_PMT() will overwrite current .ts_cappid and
caption types to the new values.

So the fix is to remove reset of ts_cappid and other variables after
receiving new PAT, but reset pmt_array, pids_seen.


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

> On Thu, May 22, 2014 at 1:40 PM, Ruslan Kuchumov <kuc...@gm...>
> wrote:
> >
> > What is the purpose of clearing the caption buffer after new PAT in the
>
> If PAT has changed then the stream you are reading now has different
> stuff (programs were added or removed). Probably I was too aggressive.
>
> > first place?  I think we should clear it only when caption type changes
> > (from 608 to 708 or something).
>
> No, that's legal, and in fact it's normal to have both 608 and 708
> captions in the same program.
>
> 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.
>
> We'd need to do something more clever here. If the PAT changes but the
> PMT we were using is still present then don't clear the buffer or
> reset the PID variables. If our selected PMT disappears then we need
> to reset everything - the program we were "watching" is gone.
>
> Also, when the PMT changes if our selected stream disappears then we
> also have to reset everything. I guess it's possible that a PMT
> changes, for example because a new program starts and it has an extra
> audio track or something like that.
>

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

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

On Thu, May 22, 2014 at 1:40 PM, Ruslan Kuchumov <kuc...@gm...> wrote:
>
> What is the purpose of clearing the caption buffer after new PAT in the

If PAT has changed then the stream you are reading now has different
stuff (programs were added or removed). Probably I was too aggressive.

> first place?  I think we should clear it only when caption type changes
> (from 608 to 708 or something).

No, that's legal, and in fact it's normal to have both 608 and 708
captions in the same program.

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.

We'd need to do something more clever here. If the PAT changes but the
PMT we were using is still present then don't clear the buffer or
reset the PID variables. If our selected PMT disappears then we need
to reset everything - the program we were "watching" is gone.

Also, when the PMT changes if our selected stream disappears then we
also have to reset everything. I guess it's possible that a PMT
changes, for example because a new program starts and it has an extra
audio track or something like that.