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
>