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
> >
>