|
Home > Archive > Macromedia Flash Server > June 2005 > controlling amount of time user can record
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
controlling amount of time user can record
|
|
| adam@jewdoo 2005-06-13, 7:45 am |
| hi,
i was wondering if anyone knows of a solid solution regarding =
controlling the amount of time a user can record netstreams if client =
records from client side. ive tested various methods and ive only come =
up with one method that seems to work, and that is to publish a live =
stream from the client to server and on server side do a ns.record and =
ns.play(name, -1, totTime). to that effect if totTime is reached an =
event is triggered and i close the stream and set writeAccess to "". =
however, i have found recording from server isnt as good as recording =
from client. my problem with recording from cleint is i havent found a =
way to securely end recording ability. if code is hacked and user =
decides to record indefinately, it would fill up disk space rather =
quickly. that idea just isnt sitting right with me.=20
when recording from client, i have tried setting writeAccess on server =
to "" in the middle of the recording but it doesnt seem to take effect =
till after the recording stops, so in that scenario, setting writeAccess =
does me no good. i would like to record from client securely if at all =
possible. any comments or suggestions are greatly appreciated.
thanks in advance,
adam
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bill Sanders 2005-06-13, 7:45 am |
| Adam,
Why not have a start and stop function for ns.record using the Date()
object for a timer?
HTH,
Bill
On Jun 13, 2005, at 7:31 AM, adam@jewdoo wrote:
> hi,
>
> i was wondering if anyone knows of a solid solution regarding
> controlling the amount of time a user can record netstreams if
> client records from client side. ive tested various methods and ive
> only come up with one method that seems to work, and that is to
> publish a live stream from the client to server and on server side
> do a ns.record and ns.play(name, -1, totTime). to that effect if
> totTime is reached an event is triggered and i close the stream and
> set writeAccess to "". however, i have found recording from server
> isnt as good as recording from client. my problem with recording
> from cleint is i havent found a way to securely end recording
> ability. if code is hacked and user decides to record indefinately,
> it would fill up disk space rather quickly. that idea just isnt
> sitting right with me.
>
> when recording from client, i have tried setting writeAccess on
> server to "" in the middle of the recording but it doesnt seem to
> take effect till after the recording stops, so in that scenario,
> setting writeAccess does me no good. i would like to record from
> client securely if at all possible. any comments or suggestions are
> greatly appreciated.
>
> thanks in advance,
>
> adam
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-06-13, 7:45 am |
| I simply start an interval when rec is pressed, counting down by 1 every
second and when recordingtime >= allowedtime I stop the recording
programmatically
Stefan
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Bill Sanders
Sent: Monday, June 13, 2005 12:39 PM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Adam,
Why not have a start and stop function for ns.record using the Date() object
for a timer?
HTH,
Bill
On Jun 13, 2005, at 7:31 AM, adam@jewdoo wrote:
> hi,
>
> i was wondering if anyone knows of a solid solution regarding
> controlling the amount of time a user can record netstreams if client
> records from client side. ive tested various methods and ive only come
> up with one method that seems to work, and that is to publish a live
> stream from the client to server and on server side do a ns.record and
> ns.play(name, -1, totTime). to that effect if totTime is reached an
> event is triggered and i close the stream and set writeAccess to "".
> however, i have found recording from server isnt as good as recording
> from client. my problem with recording from cleint is i havent found a
> way to securely end recording ability. if code is hacked and user
> decides to record indefinately, it would fill up disk space rather
> quickly. that idea just isnt sitting right with me.
>
> when recording from client, i have tried setting writeAccess on server
> to "" in the middle of the recording but it doesnt seem to take effect
> till after the recording stops, so in that scenario, setting
> writeAccess does me no good. i would like to record from client
> securely if at all possible. any comments or suggestions are greatly
> appreciated.
>
> thanks in advance,
>
> adam
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 7:45 am |
| Hi Bill, thanks for your reply.
im not altogther sure if you mean on the client side or server side but
being that there is no .record on client its my guess you mean on server.
the thing is, on the server, i have no problem ending a recording stream at
a given time. if im doing ns.play(name, -1, totTime), the play ends at
totTime, the event is triggered and then i call a function to close out the
stream and disable writeAccess to said client. i would rather not record
from the server. its so much cleaner to record from the client and it seems
the quality and playback are better if recording straight from client. when
i record from the cleint though, i am unable to securely regulate
writeAccess. in order to disable writeAccess to the client, the client has
to have ended the ns.publish(name, "record") before it will take effect.
know what i mean? 
thanks in advance,
adam
----- Original Message -----
From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 1:39 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> Adam,
>
> Why not have a start and stop function for ns.record using the Date()
> object for a timer?
>
> HTH,
> Bill
> On Jun 13, 2005, at 7:31 AM, adam@jewdoo wrote:
>
>
>
>
> bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bill Sanders 2005-06-13, 7:45 am |
| Adam,
I was talking about the CS. As soon as you invoke ns.publish
("fileName", record), start the timer. and then fire ns.close() when
the time's up. Stefan's method is equally effective and simple. I
agree that recording on the CS is a lot cleaner.
HTH,
Bill
On Jun 13, 2005, at 7:52 AM, adam@jewdoo wrote:
> Hi Bill, thanks for your reply.
>
> im not altogther sure if you mean on the client side or server side
> but being that there is no .record on client its my guess you mean
> on server.
>
> the thing is, on the server, i have no problem ending a recording
> stream at a given time. if im doing ns.play(name, -1, totTime), the
> play ends at totTime, the event is triggered and then i call a
> function to close out the stream and disable writeAccess to said
> client. i would rather not record from the server. its so much
> cleaner to record from the client and it seems the quality and
> playback are better if recording straight from client. when i
> record from the cleint though, i am unable to securely regulate
> writeAccess. in order to disable writeAccess to the client, the
> client has to have ended the ns.publish(name, "record") before it
> will take effect. know what i mean?
>
> thanks in advance,
>
> adam
>
> ----- Original Message ----- From: "Bill Sanders"
> <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 1:39 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 7:45 am |
| Hi Stefan, than you for your reply.
i do the same thing on the client as a matter of fact. on the client, when
myTimer >= maxTime, i close out the ns.publish(name, "live") and then make a
call to server to close out its ns.play and ns.record and set the client
writeAccess to "".
on the server, ns.play(name, -1, totTime) is my failsafe. i set totTime to 5
seconds longer then what i set my timer to on the client, this way if some
unforseen something happens like code being tampered with, the ns on the
server ends and writeAcess is set to "".
its a bit tricky as there are multiple calls from server to client, and
client to server to prep, init, end and validate etc, but it works and
disables the ability to write to server from client when i want it to. but,
it a lot of steps that i would love to circumnavigate if i can. but i dont
see a certain way of disabling the ability to publish a "record" stream from
client that wont be effected by an annoymous who changes cleint side code.
not to mention recording from client seems to have better quality and
playback quality then publishing a live stream to server and recording it
from server.
maybe im being overly cautious, but i feel its better to be safe the have a
lot of potential downtime once i finally get my site online.
thanks in advance,
adam.
----- Original Message -----
From: "Stefan Richter" <stefan-fMeCE+ULXElEfu+5ix1nRw@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 1:46 PM
Subject: RE: [FlashComm] controlling amount of time user can record
>I simply start an interval when rec is pressed, counting down by 1 every
> second and when recordingtime >= allowedtime I stop the recording
> programmatically
>
> Stefan
>
>
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Bill Sanders
> Sent: Monday, June 13, 2005 12:39 PM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Adam,
>
> Why not have a start and stop function for ns.record using the Date()
> object
> for a timer?
>
> HTH,
> Bill
> On Jun 13, 2005, at 7:31 AM, adam@jewdoo wrote:
>
>
>
>
> bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 7:45 am |
| Hi Bill,
my concern is somebody changing code on client side. like removing that part
about ns.close. in doing that, disk space will fill rapidly not to mention a
lot of costly bandwidth used up.
this idea keeps me awake nights
thanks in advance,
adam
----- Original Message -----
From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:07 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> Adam,
>
> I was talking about the CS. As soon as you invoke ns.publish ("fileName",
> record), start the timer. and then fire ns.close() when the time's up.
> Stefan's method is equally effective and simple. I agree that recording
> on the CS is a lot cleaner.
>
> HTH,
> Bill
> On Jun 13, 2005, at 7:52 AM, adam@jewdoo wrote:
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Bill Sanders 2005-06-13, 7:45 am |
| Adam,
Just a quick one. If you're concerned about changing code, you can
use a "SS Security" bounce -- before starting the record, a call to a
SS script looks for a variable related to key elements associated
with the timing. It's super easy to code, and it's difficult to hack.
HTH,
Bill
On Jun 13, 2005, at 8:12 AM, adam@jewdoo wrote:
> Hi Bill,
>
> my concern is somebody changing code on client side. like removing
> that part about ns.close. in doing that, disk space will fill
> rapidly not to mention a lot of costly bandwidth used up.
>
> this idea keeps me awake nights
>
> thanks in advance,
>
> adam
>
> ----- Original Message ----- From: "Bill Sanders"
> <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:07 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-06-13, 7:45 am |
| if you deploy a referrer check as well as edit your vhost.xml then noone can
take your swf, modify it and connect to your server. What they can do is
hotlink the swf but they cannot modify code and run it.
Stefan
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewdoo
Sent: Monday, June 13, 2005 1:12 PM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Hi Bill,
my concern is somebody changing code on client side. like removing that part
about ns.close. in doing that, disk space will fill rapidly not to mention a
lot of costly bandwidth used up.
this idea keeps me awake nights
thanks in advance,
adam
----- Original Message -----
From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:07 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> Adam,
>
> I was talking about the CS. As soon as you invoke ns.publish ("fileName",
> record), start the timer. and then fire ns.close() when the time's up.
> Stefan's method is equally effective and simple. I agree that recording
> on the CS is a lot cleaner.
>
> HTH,
> Bill
> On Jun 13, 2005, at 7:52 AM, adam@jewdoo wrote:
>
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 7:45 am |
| Hi Bill,
thanks for your reply, im looking into it.
adam
----- Original Message -----
From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:20 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> Adam,
>
> Just a quick one. If you're concerned about changing code, you can
> use a "SS Security" bounce -- before starting the record, a call to a
> SS script looks for a variable related to key elements associated
> with the timing. It's super easy to code, and it's difficult to hack.
>
> HTH,
> Bill
>
> On Jun 13, 2005, at 8:12 AM, adam@jewdoo wrote:
>
>
> bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 7:45 am |
| Hi Stefan,
im not altogether sure i understand. at the moment i have in place on the
server remoting to check and validate username & password. that seems to
work fine. is that what you mean?
regarding vhost.xml, what exactly in that file do i edit / change (and what
does that do for me)?
assuming somebody takes a decompiler, the code can be taken and rewritten
however this person sees fit. as long as they provide a proper username and
password.
thanks in advance,
adam
----- Original Message -----
From: "Stefan Richter" <stefan-fMeCE+ULXElEfu+5ix1nRw@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:25 PM
Subject: RE: [FlashComm] controlling amount of time user can record
> if you deploy a referrer check as well as edit your vhost.xml then noone
> can
> take your swf, modify it and connect to your server. What they can do is
> hotlink the swf but they cannot modify code and run it.
>
> Stefan
>
>
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewdoo
> Sent: Monday, June 13, 2005 1:12 PM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Bill,
>
> my concern is somebody changing code on client side. like removing that
> part
> about ns.close. in doing that, disk space will fill rapidly not to mention
> a
> lot of costly bandwidth used up.
>
> this idea keeps me awake nights
>
> thanks in advance,
>
> adam
>
> ----- Original Message -----
> From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:07 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
>
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Wouter van Vliet / webclusive 2005-06-13, 7:45 am |
| I'm not sure how simple this would be with flash, but as the referrer
information comes somehow from the client I wouldn't even think about
thrusting it. And if Adam fears somebody might tamper with his code, ..
well, I usually don't trust any user input data. Not even if i'm the
only user ;)
Adam's thing is actually something I've been struggling with some time
ago (and will be facing again very soon). The approach I'd want to do is
like this (but haven't been able to accomplish):
- CS: connect, send login creds
- SS: check creds, send login ok/false
- CS: ns.play(somestream, record)
- SS: catch a signal the moment the client starts to record video,
start a timer, when timer ends kill netsream
- CS: catch signal 'on netstream being killed'
It's step four I'm stuck with and couldn't figure out how to do .. but
the idea seems pretty much as secure as it could possibly get.
Wouter
Stefan Richter wrote:
> if you deploy a referrer check as well as edit your vhost.xml then noone can
> take your swf, modify it and connect to your server. What they can do is
> hotlink the swf but they cannot modify code and run it.
>
> Stefan
>
>
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewdoo
> Sent: Monday, June 13, 2005 1:12 PM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Bill,
>
> my concern is somebody changing code on client side. like removing that part
> about ns.close. in doing that, disk space will fill rapidly not to mention a
> lot of costly bandwidth used up.
>
> this idea keeps me awake nights
>
> thanks in advance,
>
> adam
>
> ----- Original Message -----
> From: "Bill Sanders" <wdsanders-Wuw85uim5zDR7s880joybQ@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:07 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
--
Met vriendelijke groet,
Wouter van Vliet
WEBclusive
Calandstraat 1
2521 AD Den Haag
http://www.webclusive.com
http://flashcom.pagina.nl
Tel +31 (0) 70 3699 817
Fax +31 (0) 70 4450 321
Mob +31 (0) 615 397 471
E-mail wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-13, 5:45 pm |
| Hi Wouter,
what i do for step four is, i start publishing live from client to server
first. using netstream.send, or netconnection.call, i contact server and
invoke the ns.play and ns.record. i dont use an interval to close stream at
desired time. instead i use the length parameter in Stream when i play it:
Stream.play(streamName, [startTime, length, reset,
remoteConnection])SS_ns.play(name, -1, 60) would for example play a stream
being published from client, for 60 seconds.when 60 is reached it stops and
triggers an event that you can catch using .onStatus and in doing that u can
do whatever you want.adam.----- Original Message -----
From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:46 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> I'm not sure how simple this would be with flash, but as the referrer
> information comes somehow from the client I wouldn't even think about
> thrusting it. And if Adam fears somebody might tamper with his code, ..
> well, I usually don't trust any user input data. Not even if i'm the only
> user ;)
>
> Adam's thing is actually something I've been struggling with some time ago
> (and will be facing again very soon). The approach I'd want to do is like
> this (but haven't been able to accomplish):
>
> - CS: connect, send login creds
> - SS: check creds, send login ok/false
> - CS: ns.play(somestream, record)
> - SS: catch a signal the moment the client starts to record video,
> start a timer, when timer ends kill netsream
> - CS: catch signal 'on netstream being killed'
>
> It's step four I'm stuck with and couldn't figure out how to do .. but the
> idea seems pretty much as secure as it could possibly get.
>
> Wouter
>
> Stefan Richter wrote:
>
> --
>
> Met vriendelijke groet,
> Wouter van Vliet
>
> WEBclusive
> Calandstraat 1
> 2521 AD Den Haag
>
> http://www.webclusive.com
> http://flashcom.pagina.nl
>
> Tel +31 (0) 70 3699 817
> Fax +31 (0) 70 4450 321
> Mob +31 (0) 615 397 471
> E-mail wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Frédéric v. Bochmann 2005-06-13, 8:45 pm |
| Hey Brian,
That method is like the method Adam was mentioning in his first email, I
call it server-side playback recording :P
You guys where mentioning the quality get quite less good when that method
is used. How bad does it get?
Fredz./
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewdoo
Sent: June 13, 2005 9:22 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Hi Wouter,
what i do for step four is, i start publishing live from client to server
first. using netstream.send, or netconnection.call, i contact server and
invoke the ns.play and ns.record. i dont use an interval to close stream at
desired time. instead i use the length parameter in Stream when i play it:
Stream.play(streamName, [startTime, length, reset,
remoteConnection])SS_ns.play(name, -1, 60) would for example play a stream
being published from client, for 60 seconds.when 60 is reached it stops and
triggers an event that you can catch using .onStatus and in doing that u can
do whatever you want.adam.----- Original Message -----
From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Monday, June 13, 2005 2:46 PM
Subject: Re: [FlashComm] controlling amount of time user can record
> I'm not sure how simple this would be with flash, but as the referrer
> information comes somehow from the client I wouldn't even think about
> thrusting it. And if Adam fears somebody might tamper with his code, ..
> well, I usually don't trust any user input data. Not even if i'm the only
> user ;)
>
> Adam's thing is actually something I've been struggling with some time ago
> (and will be facing again very soon). The approach I'd want to do is like
> this (but haven't been able to accomplish):
>
> - CS: connect, send login creds
> - SS: check creds, send login ok/false
> - CS: ns.play(somestream, record)
> - SS: catch a signal the moment the client starts to record video,
> start a timer, when timer ends kill netsream
> - CS: catch signal 'on netstream being killed'
>
> It's step four I'm stuck with and couldn't figure out how to do .. but the
> idea seems pretty much as secure as it could possibly get.
>
> Wouter
>
> Stefan Richter wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
>
> --
>
> Met vriendelijke groet,
> Wouter van Vliet
>
> WEBclusive
> Calandstraat 1
> 2521 AD Den Haag
>
> http://www.webclusive.com
> http://flashcom.pagina.nl
>
> Tel +31 (0) 70 3699 817
> Fax +31 (0) 70 4450 321
> Mob +31 (0) 615 397 471
> E-mail wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| adam@jewdoo 2005-06-14, 7:45 am |
| Fr=E9d=E9ric,
i recal recording quality being better, just in general. one thing that=20
sticks out now is when i record a snapshot from server, the flv when play=
ed=20
back with just netstream & no fcom seems to have a couple seconds of leed=
=20
time which makes playing back snap without fcom impossible. when i record=
a=20
lengthier flv, i have no probs playing it without fcom. this mind you was=
nt=20
always true. this little (big) change occured after i installed recent fc=
om=20
patch. my approach since flash mx 2004 has been to only use fcom when=20
needed, like... ~need~ fcom to record but, for all playbacks, there is no=
=20
real need. and things worked fine like that, until the patch. after the=20
patch, certain methods needed a recode. so now though i still record=20
snapshots using server, i have to use netstream plus fcom to play them ba=
ck,=20
which isnt a big deal in the grand scheme since snapshots only come out t=
o=20
about 5k.
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Tuesday, June 14, 2005 1:49 AM
Subject: RE: [FlashComm] controlling amount of time user can record
> Hey Brian,
>
> That method is like the method Adam was mentioning in his first email, =
I
> call it server-side playback recording :P
>
> You guys where mentioning the quality get quite less good when that met=
hod
> is used. How bad does it get?
>
>
> Fredz./
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewd=
oo
> Sent: June 13, 2005 9:22 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Wouter,
>
> what i do for step four is, i start publishing live from client to serv=
er
> first. using netstream.send, or netconnection.call, i contact server an=
d
> invoke the ns.play and ns.record. i dont use an interval to close strea=
m=20
> at
> desired time. instead i use the length parameter in Stream when i play =
it:
>
> Stream.play(streamName, [startTime, length, reset,
> remoteConnection])SS_ns.play(name, -1, 60) would for example play a str=
eam
> being published from client, for 60 seconds.when 60 is reached it stops=
=20
> and
> triggers an event that you can catch using .onStatus and in doing that =
u=20
> can
>
> do whatever you want.adam.----- Original Message -----=20
> From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:46 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
..[vbcol=seagreen]
nly[vbcol=seagreen]
=20[vbcol=seagreen]
>
ike[vbcol=seagreen]
=20[vbcol=seagreen]
>
one[vbcol=seagreen]
is[vbcol=seagreen]
at[vbcol=seagreen]
>
p.[vbcol=seagreen]
ing[vbcol=seagreen]
>
nds[vbcol=seagreen]
ose[vbcol=seagreen]
er[vbcol=seagreen]
g[vbcol=seagreen]
>
o[vbcol=seagreen]
()[vbcol=seagreen]
y[vbcol=seagreen]
sh=20[vbcol=seagreen]
>
ime[vbcol=seagreen]
snt[vbcol=seagreen]
..=20[vbcol=seagreen]
>
>
>
ng[vbcol=seagreen]
tly[vbcol=seagreen]
>
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>=20
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Frédéric v. Bochmann 2005-06-14, 8:45 pm |
| Thank you very much Adam,
I'm about to start a project that will let users create video to be =
played
back by other users. We are thinking of using the flash player 7 =
progressive
download feature for the playback, and using fcomm for the recording.
You are mentioning you are having issues about playing back short =
streams
because of some 'couple seconds of leed'.
For this project, I might simply stick with the flash-client recording =
it
directly to the server.
PS: About server side: 'couple seconds of leed'.
I've worked on some project that involved centralizing the streams in =
one
stream; no matter from which stream it came from it had to be =
played-back on
a centralized stream on which all clients would listen to. So, I've had =
to
manage some crazy server-side stream swapping and recording, which also
involved using some play-listing of streams to obtain a unique and =
continues
stream, and that had no unnecessary delays in it.
I've noticed issues myself with SS-stream playback-recording in those
projects. I'm thinking that, what you have experienced might have been
caused by the default server-side stream bufferTime length
(Stream.bufferTime). Flash communication server has this default =
server-side
stream buffer set to 2 seconds (depending on the xml configuration =
files).=20
This buffer time can be easily adjusted on a specific instance of a =
stream
object with it's bufferTime property value.
So, you basically set it to zero seconds, and by so, that specific
server-side made stream that is recording to disk, will not buffer =
streams
it plays before actually displaying them, thus recording them.=20
- (Hope u got that)-
Also, remember that putting the bufferTime to 0 will reduce the quality =
of
your stream, making it skip potentially still incoming data.
Fredz./
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of =
adam@jewdoo
Sent: June 14, 2005 8:48 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Fr=E9d=E9ric,
i recal recording quality being better, just in general. one thing that=20
sticks out now is when i record a snapshot from server, the flv when =
played=20
back with just netstream & no fcom seems to have a couple seconds of =
leed=20
time which makes playing back snap without fcom impossible. when i =
record a=20
lengthier flv, i have no probs playing it without fcom. this mind you =
wasnt=20
always true. this little (big) change occured after i installed recent =
fcom=20
patch. my approach since flash mx 2004 has been to only use fcom when=20
needed, like... ~need~ fcom to record but, for all playbacks, there is =
no=20
real need. and things worked fine like that, until the patch. after the=20
patch, certain methods needed a recode. so now though i still record=20
snapshots using server, i have to use netstream plus fcom to play them =
back,
which isnt a big deal in the grand scheme since snapshots only come out =
to=20
about 5k.
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Tuesday, June 14, 2005 1:49 AM
Subject: RE: [FlashComm] controlling amount of time user can record
> Hey Brian,
>
> That method is like the method Adam was mentioning in his first email, =
I
> call it server-side playback recording :P
>
> You guys where mentioning the quality get quite less good when that =
method
> is used. How bad does it get?
>
>
> Fredz./
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of =
adam@jewdoo
> Sent: June 13, 2005 9:22 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Wouter,
>
> what i do for step four is, i start publishing live from client to =
server
> first. using netstream.send, or netconnection.call, i contact server =
and
> invoke the ns.play and ns.record. i dont use an interval to close =
stream=20
> at
> desired time. instead i use the length parameter in Stream when i play =
it:
>
> Stream.play(streamName, [startTime, length, reset,
> remoteConnection])SS_ns.play(name, -1, 60) would for example play a =
stream
> being published from client, for 60 seconds.when 60 is reached it =
stops=20
> and
> triggers an event that you can catch using .onStatus and in doing that =
u=20
> can
>
> do whatever you want.adam.----- Original Message -----=20
> From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:46 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
...[vbcol=seagreen]
only[vbcol=seagreen]
time=20[vbcol=seagreen]
>
like[vbcol=seagreen]
but=20[vbcol=seagreen]
>
noone[vbcol=seagreen]
do is[vbcol=seagreen]
that[vbcol=seagreen]
>
up.[vbcol=seagreen]
recording[vbcol=seagreen]
[vbcol=seagreen]
>
ends[vbcol=seagreen]
close[vbcol=seagreen]
rather[vbcol=seagreen]
recording[vbcol=seagreen]
>
to[vbcol=seagreen]
"record")[vbcol=seagreen]
Date ()[vbcol=seagreen]
only[vbcol=seagreen]
publish=20[vbcol=seagreen]
>
totTime[vbcol=seagreen]
isnt[vbcol=seagreen]
from[vbcol=seagreen]
ability.=20[vbcol=seagreen]
>
would[vbcol=seagreen]
[vbcol=seagreen]
>
>
setting[vbcol=seagreen]
greatly[vbcol=seagreen]
>
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>=20
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
|
| Fr=E9d=E9ric ,
wow man... thanks for that heads up i appreciate it. will commit to memor=
y=20
for later use. as i mentioned i re-coded already and things work, just no=
t=20
how i wanted hehe. i may later go back and redo the redo because even tho=
=20
playing snaps with fcom isnt such a big deal as their size is so small, i=
do=20
plan to have many users on site one fine day after i launch and the=20
bandwidth, little as it may appear to me now, is sure to add up quickly.=20
money will be an issue until site is making money, when that day does hap=
pen=20
i guess it wont matter much but that day is not today
thanks again,
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, June 15, 2005 2:47 AM
Subject: RE: [FlashComm] controlling amount of time user can record
Thank you very much Adam,
I'm about to start a project that will let users create video to be playe=
d
back by other users. We are thinking of using the flash player 7 progress=
ive
download feature for the playback, and using fcomm for the recording.
You are mentioning you are having issues about playing back short streams
because of some 'couple seconds of leed'.
For this project, I might simply stick with the flash-client recording it
directly to the server.
PS: About server side: 'couple seconds of leed'.
I've worked on some project that involved centralizing the streams in one
stream; no matter from which stream it came from it had to be played-back=
on
a centralized stream on which all clients would listen to. So, I've had t=
o
manage some crazy server-side stream swapping and recording, which also
involved using some play-listing of streams to obtain a unique and contin=
ues
stream, and that had no unnecessary delays in it.
I've noticed issues myself with SS-stream playback-recording in those
projects. I'm thinking that, what you have experienced might have been
caused by the default server-side stream bufferTime length
(Stream.bufferTime). Flash communication server has this default server-s=
ide
stream buffer set to 2 seconds (depending on the xml configuration files)=
..
This buffer time can be easily adjusted on a specific instance of a strea=
m
object with it's bufferTime property value.
So, you basically set it to zero seconds, and by so, that specific
server-side made stream that is recording to disk, will not buffer stream=
s
it plays before actually displaying them, thus recording them.
- (Hope u got that)-
Also, remember that putting the bufferTime to 0 will reduce the quality o=
f
your stream, making it skip potentially still incoming data.
Fredz./
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewdoo
Sent: June 14, 2005 8:48 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Fr=E9d=E9ric,
i recal recording quality being better, just in general. one thing that
sticks out now is when i record a snapshot from server, the flv when play=
ed
back with just netstream & no fcom seems to have a couple seconds of leed
time which makes playing back snap without fcom impossible. when i record=
a
lengthier flv, i have no probs playing it without fcom. this mind you was=
nt
always true. this little (big) change occured after i installed recent fc=
om
patch. my approach since flash mx 2004 has been to only use fcom when
needed, like... ~need~ fcom to record but, for all playbacks, there is no
real need. and things worked fine like that, until the patch. after the
patch, certain methods needed a recode. so now though i still record
snapshots using server, i have to use netstream plus fcom to play them ba=
ck,
which isnt a big deal in the grand scheme since snapshots only come out t=
o
about 5k.
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Tuesday, June 14, 2005 1:49 AM
Subject: RE: [FlashComm] controlling amount of time user can record
> Hey Brian,
>
> That method is like the method Adam was mentioning in his first email, =
I
> call it server-side playback recording :P
>
> You guys where mentioning the quality get quite less good when that met=
hod
> is used. How bad does it get?
>
>
> Fredz./
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam@jewd=
oo
> Sent: June 13, 2005 9:22 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Wouter,
>
> what i do for step four is, i start publishing live from client to serv=
er
> first. using netstream.send, or netconnection.call, i contact server an=
d
> invoke the ns.play and ns.record. i dont use an interval to close strea=
m
> at
> desired time. instead i use the length parameter in Stream when i play =
it:
>
> Stream.play(streamName, [startTime, length, reset,
> remoteConnection])SS_ns.play(name, -1, 60) would for example play a str=
eam
> being published from client, for 60 seconds.when 60 is reached it stops
> and
> triggers an event that you can catch using .onStatus and in doing that =
u
> can
>
> do whatever you want.adam.----- Original Message -----=20
> From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:46 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
..[vbcol=seagreen]
nly[vbcol=seagreen]
>
ike[vbcol=seagreen]
>
one[vbcol=seagreen]
is[vbcol=seagreen]
at[vbcol=seagreen]
>
p.[vbcol=seagreen]
ing[vbcol=seagreen]
>
nds[vbcol=seagreen]
ose[vbcol=seagreen]
er[vbcol=seagreen]
g[vbcol=seagreen]
>
o[vbcol=seagreen]
()[vbcol=seagreen]
y[vbcol=seagreen]
sh[vbcol=seagreen]
>
ime[vbcol=seagreen]
snt[vbcol=seagreen]
..[vbcol=seagreen]
>
>
>
ng[vbcol=seagreen]
tly[vbcol=seagreen]
>
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D---------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D---------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Frédéric v. Bochmann 2005-06-15, 8:46 pm |
| Hey Adam,
I'm happy that my experience might one day come to use for someone else.
Keep up the good work ;)
Fredz./
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of adam
Sent: June 15, 2005 5:33 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Fr=E9d=E9ric ,
wow man... thanks for that heads up i appreciate it. will commit to =
memory=20
for later use. as i mentioned i re-coded already and things work, just =
not=20
how i wanted hehe. i may later go back and redo the redo because even =
tho=20
playing snaps with fcom isnt such a big deal as their size is so small, =
i do
plan to have many users on site one fine day after i launch and the=20
bandwidth, little as it may appear to me now, is sure to add up quickly. =
money will be an issue until site is making money, when that day does =
happen
i guess it wont matter much but that day is not today
thanks again,
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, June 15, 2005 2:47 AM
Subject: RE: [FlashComm] controlling amount of time user can record
Thank you very much Adam,
I'm about to start a project that will let users create video to be =
played
back by other users. We are thinking of using the flash player 7 =
progressive
download feature for the playback, and using fcomm for the recording.
You are mentioning you are having issues about playing back short =
streams
because of some 'couple seconds of leed'.
For this project, I might simply stick with the flash-client recording =
it
directly to the server.
PS: About server side: 'couple seconds of leed'.
I've worked on some project that involved centralizing the streams in =
one
stream; no matter from which stream it came from it had to be =
played-back on
a centralized stream on which all clients would listen to. So, I've had =
to
manage some crazy server-side stream swapping and recording, which also
involved using some play-listing of streams to obtain a unique and =
continues
stream, and that had no unnecessary delays in it.
I've noticed issues myself with SS-stream playback-recording in those
projects. I'm thinking that, what you have experienced might have been
caused by the default server-side stream bufferTime length
(Stream.bufferTime). Flash communication server has this default =
server-side
stream buffer set to 2 seconds (depending on the xml configuration =
files).
This buffer time can be easily adjusted on a specific instance of a =
stream
object with it's bufferTime property value.
So, you basically set it to zero seconds, and by so, that specific
server-side made stream that is recording to disk, will not buffer =
streams
it plays before actually displaying them, thus recording them.
- (Hope u got that)-
Also, remember that putting the bufferTime to 0 will reduce the quality =
of
your stream, making it skip potentially still incoming data.
Fredz./
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of =
adam@jewdoo
Sent: June 14, 2005 8:48 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] controlling amount of time user can record
Fr=E9d=E9ric,
i recal recording quality being better, just in general. one thing that
sticks out now is when i record a snapshot from server, the flv when =
played
back with just netstream & no fcom seems to have a couple seconds of =
leed
time which makes playing back snap without fcom impossible. when i =
record a
lengthier flv, i have no probs playing it without fcom. this mind you =
wasnt
always true. this little (big) change occured after i installed recent =
fcom
patch. my approach since flash mx 2004 has been to only use fcom when
needed, like... ~need~ fcom to record but, for all playbacks, there is =
no
real need. and things worked fine like that, until the patch. after the
patch, certain methods needed a recode. so now though i still record
snapshots using server, i have to use netstream plus fcom to play them =
back,
which isnt a big deal in the grand scheme since snapshots only come out =
to
about 5k.
-adam
----- Original Message -----=20
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Tuesday, June 14, 2005 1:49 AM
Subject: RE: [FlashComm] controlling amount of time user can record
> Hey Brian,
>
> That method is like the method Adam was mentioning in his first email, =
I
> call it server-side playback recording :P
>
> You guys where mentioning the quality get quite less good when that =
method
> is used. How bad does it get?
>
>
> Fredz./
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of =
adam@jewdoo
> Sent: June 13, 2005 9:22 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] controlling amount of time user can record
>
> Hi Wouter,
>
> what i do for step four is, i start publishing live from client to =
server
> first. using netstream.send, or netconnection.call, i contact server =
and
> invoke the ns.play and ns.record. i dont use an interval to close =
stream
> at
> desired time. instead i use the length parameter in Stream when i play =
it:
>
> Stream.play(streamName, [startTime, length, reset,
> remoteConnection])SS_ns.play(name, -1, 60) would for example play a =
stream
> being published from client, for 60 seconds.when 60 is reached it =
stops
> and
> triggers an event that you can catch using .onStatus and in doing that =
u
> can
>
> do whatever you want.adam.----- Original Message -----=20
> From: "Wouter van Vliet / webclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Monday, June 13, 2005 2:46 PM
> Subject: Re: [FlashComm] controlling amount of time user can record
>
>
...[vbcol=seagreen]
only[vbcol=seagreen]
time[vbcol=seagreen]
>
like[vbcol=seagreen]
but[vbcol=seagreen]
>
noone[vbcol=seagreen]
do is[vbcol=seagreen]
that[vbcol=seagreen]
>
up.[vbcol=seagreen]
recording[vbcol=seagreen]
>
ends[vbcol=seagreen]
close[vbcol=seagreen]
rather[vbcol=seagreen]
recording[vbcol=seagreen]
>
to[vbcol=seagreen]
"record")[vbcol=seagreen]
Date ()[vbcol=seagreen]
only[vbcol=seagreen]
publish[vbcol=seagreen]
>
totTime[vbcol=seagreen]
isnt[vbcol=seagreen]
from[vbcol=seagreen]
ability.[vbcol=seagreen]
>
would[vbcol=seagreen]
>
>
setting[vbcol=seagreen]
greatly[vbcol=seagreen]
>
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D---------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D---------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|