Re: [backstage] RTMP stream URL resolving script

[Phil Wilson]

Still doesn't explain how midnight is handled or what the timezone is!


At this point, I'm going to bow out of the conversation. Feel free to curse me for being 
stupid, misleading, insulting or whatever.


It seems to me that you have some reasonably fundamental misunderstandings about all the 
technologies involved, from JavaScript, to FLV, to RTMP and Apache, discussion of which I 
view as OT for this thread.


Good luck.

Phil
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Andy]

On 24/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
> As far as I know, Apache cannot stream files.

The client does the streaming. Apache does the serving.
Technically possible with any HTTP server.

Adam Wrote:
> Apache is okay, but no security and it can only do http,

It has very few bugs and vulnerabilities for it's size. It can also do HTTPS.
It also drops privileges once it has bound to the listening port (I think).
I would have thought that would be considered some security.

Phil wrote:
> >> Red5 ..
> >> VLC
>
> Even if these were OK, do they work on the massive scale required by the BBC?

I haven't done stress tests on them. But if they are different streams
then it's more a case of duplication and whether the OS can handle
requests fast enough.

> I'm going to stick my neck out and suggest that neither of these
> servers are capable of handling this load as-is.

Guess work or actual fact?

> An RTMP client needs to have an execution environment.

What precisely needs to be in this execution environment? Do I
actually need to write a full Flash environment, that seems a bit
excessive for just streaming a file wouldn't you agree?

I think what I was planning is a little out of my league if it
involves writing a Flash implementation in Java. Please reconsider
using sensible formats.

> 
> See the JavaScript Date documentation for your favourite implementation, such 
> as
> http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date

Still doesn't explain how midnight is handled or what the timezone is!

Upon closer inspection I notice the Beeb is carefully setting it's
times one minute before the hour and one minute after. Thus I doubt
the Midnight condition is ever going to happen. Well done!

Timezone wise it seems to be irrelevant for the Flash player as the
Server sets the time it generated the page. Appears to be in GMT. Do I
have to wait till summer to find out if it switches to BST or whether
it stays on GMT?
Of course I could parse the dateNow field as well but my intention
would be to cache the page to avoid repeated page loads.


> 
> These are generated by the BBC, so you probably don't need to know,

It would help to be able to sanity check what I parse.
If I "mis parse" something I wouldn't want to request stupid pages would I?
I guess I could just guess where it is sensible and issue a warning to the user.
Would be nice to have a definitive answer, these IDs are being
generated somewhere so someone must know what set they are generated
from.

> I would hope that most of your other questions become redundant if an API 
> appears,
> as has been suggested.

As would I, but no API yet so the answers would be good.

I Wrote:
> I therefore assumed that RTMP could still be used but wasn't
> the recommended approach. I may have been wrong though.

Typographical Error. I thought HTTP but somehow typed RTMP. It should
of course read:
"I therefore assumed that HTTP could still be used"

Andy

-- 
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Matt Barber]

On Jan 24, 2008 11:39 AM, Matt Barber <[EMAIL PROTECTED]> wrote:

> You are correct in saying that apache cannot stream files, the only
> possibility is to progressively download the data, otherwise known as 'http
> streaming', which is, as previously mentioned, inefficient compared to other
> more suitable methods.
>
> I think that part of the problem is that today there are so many solutions
> offering to solve the issue of getting streaming video/audio from one place
> to another, each with a different combination of encoder, decoder, wrapper
> and transport. This ambiguity, and choice, may be what is slowing down the
> development of 'free' implementations. But then who can argue against the
> fact that choice is a good thing? Always a difficult issue to address.
>
> This discussion is interesting because it brings forward the possibility
> of standards, without the major pressure of commercial success driving
> results. It's interesting to see what suggestions are being made.
>
>
>
> On Jan 24, 2008 11:10 AM, Phil Wilson <[EMAIL PROTECTED]> wrote:
>
> > (for some reason Andy's reply didn't make it to my mail client, but I've
> > read it online
> > here: http://www.mail-archive.com/backstage@lists.bbc.co.uk/msg07375.html
> > - I'd really
> > appreciate it if the Backstage page about the mailing list would link to
> > the HTML archive!)
> >
> > >> Apache has the power to serve files over HTTP. You should check it
> > out
> > >> http://www.apache.org/ . Stick a file in a location it can access and
> > >> clients can stream from it.
> >
> > As far as I know, Apache cannot stream files.
> >
> > >> Red5 ..
> > >> VLC
> >
> > Even if these were OK, do they work on the massive scale required by the
> > BBC? According to
> > http://news.bbc.co.uk/1/hi/technology/7187967.stm they'd need to be
> > support streaming
> > 250,000 programmes a day. I'm going to stick my neck out and suggest
> > that neither of these
> > servers are capable of handling this load as-is.
> >
> > I can't answer all your other questions because I don't know all the
> > answers, but here are
> > a few:
> >
> > "Does this mean an RTMP
> > client needs to have a full interpreter for some programming language"
> >
> > An RTMP client needs to have an execution environment.
> >
> > 
> >
> > See the JavaScript Date documentation for your favourite implementation,
> > such as
> >
> > http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date
> >
> > 
> >
> > These are generated by the BBC, so you probably don't need to know,
> > other than ensuring
> > you encode as UTF-8 to make sure you can handle a broad character set.
> > Java encodes String
> > objects to UTF-8 internally by default.
> >
> > I would hope that most of your other questions become redundant if an
> > API appears, as has
> > been suggested.
> >
> > Cheers,
> >
> > Phil
> > -
> > Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe,
> > please visit
> > http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
> >  Unofficial list archive:
> > http://www.mail-archive.com/backstage@lists.bbc.co.uk/
> >
>
>

Here's an open letter written from the CEO of Brightcove before CES to try
to get some attention about open standards, some of you may have seen it but
here it is anyway:

http://www.brightcove.com/about_brightcove/perspectives/open-internet-television-letter-to-ce-industry.cfm

Also apologies for my 'above post replying', I am so used to it, it didn't
cross my mind to change on a mailing list!

./Matt

Re: [backstage] RTMP stream URL resolving script

[Matt Barber]

You are correct in saying that apache cannot stream files, the only
possibility is to progressively download the data, otherwise known as 'http
streaming', which is, as previously mentioned, inefficient compared to other
more suitable methods.

I think that part of the problem is that today there are so many solutions
offering to solve the issue of getting streaming video/audio from one place
to another, each with a different combination of encoder, decoder, wrapper
and transport. This ambiguity, and choice, may be what is slowing down the
development of 'free' implementations. But then who can argue against the
fact that choice is a good thing? Always a difficult issue to address.

This discussion is interesting because it brings forward the possibility of
standards, without the major pressure of commercial success driving results.
It's interesting to see what suggestions are being made.


On Jan 24, 2008 11:10 AM, Phil Wilson <[EMAIL PROTECTED]> wrote:

> (for some reason Andy's reply didn't make it to my mail client, but I've
> read it online
> here: http://www.mail-archive.com/backstage@lists.bbc.co.uk/msg07375.html- 
> I'd really
> appreciate it if the Backstage page about the mailing list would link to
> the HTML archive!)
>
> >> Apache has the power to serve files over HTTP. You should check it out
> >> http://www.apache.org/ . Stick a file in a location it can access and
> >> clients can stream from it.
>
> As far as I know, Apache cannot stream files.
>
> >> Red5 ..
> >> VLC
>
> Even if these were OK, do they work on the massive scale required by the
> BBC? According to
> http://news.bbc.co.uk/1/hi/technology/7187967.stm they'd need to be
> support streaming
> 250,000 programmes a day. I'm going to stick my neck out and suggest that
> neither of these
> servers are capable of handling this load as-is.
>
> I can't answer all your other questions because I don't know all the
> answers, but here are
> a few:
>
> "Does this mean an RTMP
> client needs to have a full interpreter for some programming language"
>
> An RTMP client needs to have an execution environment.
>
> 
>
> See the JavaScript Date documentation for your favourite implementation,
> such as
>
> http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date
>
> 
>
> These are generated by the BBC, so you probably don't need to know, other
> than ensuring
> you encode as UTF-8 to make sure you can handle a broad character set.
> Java encodes String
> objects to UTF-8 internally by default.
>
> I would hope that most of your other questions become redundant if an API
> appears, as has
> been suggested.
>
> Cheers,
>
> Phil
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
>  Unofficial list archive:
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>

Re: [backstage] RTMP stream URL resolving script

[Phil Wilson]

(for some reason Andy's reply didn't make it to my mail client, but I've read it online 
here: http://www.mail-archive.com/backstage@lists.bbc.co.uk/msg07375.html - I'd really 
appreciate it if the Backstage page about the mailing list would link to the HTML archive!)



Apache has the power to serve files over HTTP. You should check it out
http://www.apache.org/ . Stick a file in a location it can access and
clients can stream from it.


As far as I know, Apache cannot stream files.


Red5 ..
VLC 


Even if these were OK, do they work on the massive scale required by the BBC? According to 
http://news.bbc.co.uk/1/hi/technology/7187967.stm they'd need to be support streaming 
250,000 programmes a day. I'm going to stick my neck out and suggest that neither of these 
servers are capable of handling this load as-is.


I can't answer all your other questions because I don't know all the answers, but here are 
a few:


"Does this mean an RTMP
client needs to have a full interpreter for some programming language"

An RTMP client needs to have an execution environment.



See the JavaScript Date documentation for your favourite implementation, such as 
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Date




These are generated by the BBC, so you probably don't need to know, other than ensuring 
you encode as UTF-8 to make sure you can handle a broad character set. Java encodes String 
objects to UTF-8 internally by default.


I would hope that most of your other questions become redundant if an API appears, as has 
been suggested.


Cheers,

Phil
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

> Have you ever used youtube? you can skip to any part of the video and
> it starts streaming from there. The only reason i can see adobe
> deprecating http is so you have to use their clients to use it!

Mike - http is not ideally suited to streaming, where the idea is to
provide smooth audio or video taking into account floopy network
bandwidth (with buffering...), client-side decoding speed, and viewing
the stream or flux while the file is still being downloaded. http is
of course fine for small clips. I believe Flash MX was the first
version to offer "streaming" and it was simulated streaming at that,
straight buffering with no network quality feedback if I remember
right. Sometimes close enough does count, as in horseshoes and hand
grenades a biker friend of mine used to say.

Also IIRC MPEG-1 was silent on IP transport while MPEG-2 may have had
something and MPEG-4 has a whole chapter on it.

The issue of open standards is of course perfectly valid. RealNetworks
for example has had great streaming for years but I believe their
protocols are entirely proprietary.

Sean


On Jan 24, 2008 11:42 AM, Sean DALY <[EMAIL PROTECTED]> wrote:
> I believe icecast would be a better FOSS candidate for a multicast
> on-demand streaming server than VLC.
>
> But really, any discussion of streaming must needs associate the file
> format container and codec and client-side application (browser
> plug-in, dedicated, ...). And on a large scale, the workflow, both
> media transcoding and metadata transformations.
>
> I wouldn't underestimate the technical difficulties of organising
> massive on-demand streaming, especially both historic and close behind
> on-air. Just the data storage alone is a major headache.
>
> And I won't even bring up DRM / authentification issues :-)
>
> Sean
>
>
>
> On Jan 24, 2008 11:16 AM, mike waterworth <[EMAIL PROTECTED]> wrote:
> > On 1/24/08, Adam <[EMAIL PROTECTED]> wrote:
> > >
> > >  Andy wrote:
> > >  On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >  Without looking it up, the previous reply (from a Gnash dev IIRC) was 
> > > that
> > > the BBC are
> > > using the latest version of Adobe Flash Streaming Server, and this has
> > > dropped support for
> > > streaming over HTTP.
> > >
> > >  I remembered it being described as deprecated. My interpretation of
> > > deprecated is that it isn't recommended to use it but it still can be
> > > used. Normally it means it will be removed sometime in the future. For
> > > instance I can use a Deprecated Method in Java and it will still wok
> > > but I will get a warning and it may be removed from Java in the
> > > future. I therefore assumed that RTMP could still be used but wasn't
> > > the recommended approach. I may have been wrong though. (Why would
> > > anyone remove something useful from a software application anyway?
> > > More importantly why would anyone trust a vendor that did that with
> > > their Mission Critical software applications?).
> > >
> > >  You seem to be confusing yourself as RTMP has not been removed and is the
> > > recommended approach with http apparently being deprecated.
> > >
> > >  They probably removed http streaming as it isn't that efficient and it
> > > makes it easy for people to download the flv videos.  With the streaming 
> > > the
> > > videos are harder to copy plus you get the benefits that if you skip 
> > > forward
> > > in a video you don't have to wait for the flv to download to that point.
> >
> > Have you ever used youtube? you can skip to any part of the video and
> > it starts streaming from there. The only reason i can see adobe
> > deprecating http is so you have to use their clients to use it!
> >
> > The bbc really should be more open about this.
> > So you want to open iplayer up to third party clients and get the open
> > source community involved? But yet you don't want to let them download
> > the shows?
> > The only thing stopping us from downloading the shows is no rtmp
> > client support outside of flash player, as soon as that happens anyone
> > could build a downloader client.
> > So what is your logic for closing us off then trying to open it up?
> > >
> > >
> > >
> > >  When YouTube upgrade, they too will probably lose support for
> > > streaming over HTTP as well.
> >
> > Not so sure, they have loads of third party clients (think apple tv)
> > that doesn't use rtmp and they wouldn't kill support for them.
> >
> >
> > >
> > >
> > >  They currently stream over HTTP don't they? This the BBC could
> > > *currently* do the same.
> > >
> > >  See above.  Like other people have pointed out when You Tube next upgrade
> > > they will probably stop the current http streams.
> > >
> > >
> > >
> > >  Also, I previously asked you if you knew of any alternatives the BBC 
> > > could
> > > have used. To
> > > quote you: "Any chance you could actually answer the questions I asked?"
> > >
> > >
> > >  To quote you:
> > >
> > >
> > >  This has also been answered before (the la

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

I believe icecast would be a better FOSS candidate for a multicast
on-demand streaming server than VLC.

But really, any discussion of streaming must needs associate the file
format container and codec and client-side application (browser
plug-in, dedicated, ...). And on a large scale, the workflow, both
media transcoding and metadata transformations.

I wouldn't underestimate the technical difficulties of organising
massive on-demand streaming, especially both historic and close behind
on-air. Just the data storage alone is a major headache.

And I won't even bring up DRM / authentification issues :-)

Sean


On Jan 24, 2008 11:16 AM, mike waterworth <[EMAIL PROTECTED]> wrote:
> On 1/24/08, Adam <[EMAIL PROTECTED]> wrote:
> >
> >  Andy wrote:
> >  On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
> >
> >
> >  Without looking it up, the previous reply (from a Gnash dev IIRC) was that
> > the BBC are
> > using the latest version of Adobe Flash Streaming Server, and this has
> > dropped support for
> > streaming over HTTP.
> >
> >  I remembered it being described as deprecated. My interpretation of
> > deprecated is that it isn't recommended to use it but it still can be
> > used. Normally it means it will be removed sometime in the future. For
> > instance I can use a Deprecated Method in Java and it will still wok
> > but I will get a warning and it may be removed from Java in the
> > future. I therefore assumed that RTMP could still be used but wasn't
> > the recommended approach. I may have been wrong though. (Why would
> > anyone remove something useful from a software application anyway?
> > More importantly why would anyone trust a vendor that did that with
> > their Mission Critical software applications?).
> >
> >  You seem to be confusing yourself as RTMP has not been removed and is the
> > recommended approach with http apparently being deprecated.
> >
> >  They probably removed http streaming as it isn't that efficient and it
> > makes it easy for people to download the flv videos.  With the streaming the
> > videos are harder to copy plus you get the benefits that if you skip forward
> > in a video you don't have to wait for the flv to download to that point.
>
> Have you ever used youtube? you can skip to any part of the video and
> it starts streaming from there. The only reason i can see adobe
> deprecating http is so you have to use their clients to use it!
>
> The bbc really should be more open about this.
> So you want to open iplayer up to third party clients and get the open
> source community involved? But yet you don't want to let them download
> the shows?
> The only thing stopping us from downloading the shows is no rtmp
> client support outside of flash player, as soon as that happens anyone
> could build a downloader client.
> So what is your logic for closing us off then trying to open it up?
> >
> >
> >
> >  When YouTube upgrade, they too will probably lose support for
> > streaming over HTTP as well.
>
> Not so sure, they have loads of third party clients (think apple tv)
> that doesn't use rtmp and they wouldn't kill support for them.
>
>
> >
> >
> >  They currently stream over HTTP don't they? This the BBC could
> > *currently* do the same.
> >
> >  See above.  Like other people have pointed out when You Tube next upgrade
> > they will probably stop the current http streams.
> >
> >
> >
> >  Also, I previously asked you if you knew of any alternatives the BBC could
> > have used. To
> > quote you: "Any chance you could actually answer the questions I asked?"
> >
> >
> >  To quote you:
> >
> >
> >  This has also been answered before (the last time you asked it, actually).
> > I'm not
> > entirely convinced you've actually been reading replies, or if you have,
> > actually paying
> > them much attention.
> >
> >  Apache has the power to serve files over HTTP. You should check it out
> > http://www.apache.org/ . Stick a file in a location it can access and
> > clients can stream from it.
> > Red5 likely still does HTTP. http://osflash.org/red5
> >
> > First hit on Google for "Video Streaming Software":
> > http://www.videolan.org/vlc/streaming.html
> > (VLC can behave as a server as well as doing playback)
> > Supports multiple formats and protocols.
> >
> >
> >  Apache is okay, but no security and it can only do http, VLC can do
> > different streams but it is only designed for streaming one video and makes
> > use of multicast and this is not available with many ISPs, so both of this
> > suggestions are unusable.
> >
> >  Adam
> >
>
>
> --
> This email proudly and graciously contributes to entropy.
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_li

Re: [backstage] RTMP stream URL resolving script

[mike waterworth]

On 1/24/08, Adam <[EMAIL PROTECTED]> wrote:
>
>  Andy wrote:
>  On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
>
>
>  Without looking it up, the previous reply (from a Gnash dev IIRC) was that
> the BBC are
> using the latest version of Adobe Flash Streaming Server, and this has
> dropped support for
> streaming over HTTP.
>
>  I remembered it being described as deprecated. My interpretation of
> deprecated is that it isn't recommended to use it but it still can be
> used. Normally it means it will be removed sometime in the future. For
> instance I can use a Deprecated Method in Java and it will still wok
> but I will get a warning and it may be removed from Java in the
> future. I therefore assumed that RTMP could still be used but wasn't
> the recommended approach. I may have been wrong though. (Why would
> anyone remove something useful from a software application anyway?
> More importantly why would anyone trust a vendor that did that with
> their Mission Critical software applications?).
>
>  You seem to be confusing yourself as RTMP has not been removed and is the
> recommended approach with http apparently being deprecated.
>
>  They probably removed http streaming as it isn't that efficient and it
> makes it easy for people to download the flv videos.  With the streaming the
> videos are harder to copy plus you get the benefits that if you skip forward
> in a video you don't have to wait for the flv to download to that point.

Have you ever used youtube? you can skip to any part of the video and
it starts streaming from there. The only reason i can see adobe
deprecating http is so you have to use their clients to use it!

The bbc really should be more open about this.
So you want to open iplayer up to third party clients and get the open
source community involved? But yet you don't want to let them download
the shows?
The only thing stopping us from downloading the shows is no rtmp
client support outside of flash player, as soon as that happens anyone
could build a downloader client.
So what is your logic for closing us off then trying to open it up?
>
>
>
>  When YouTube upgrade, they too will probably lose support for
> streaming over HTTP as well.

Not so sure, they have loads of third party clients (think apple tv)
that doesn't use rtmp and they wouldn't kill support for them.

>
>
>  They currently stream over HTTP don't they? This the BBC could
> *currently* do the same.
>
>  See above.  Like other people have pointed out when You Tube next upgrade
> they will probably stop the current http streams.
>
>
>
>  Also, I previously asked you if you knew of any alternatives the BBC could
> have used. To
> quote you: "Any chance you could actually answer the questions I asked?"
>
>
>  To quote you:
>
>
>  This has also been answered before (the last time you asked it, actually).
> I'm not
> entirely convinced you've actually been reading replies, or if you have,
> actually paying
> them much attention.
>
>  Apache has the power to serve files over HTTP. You should check it out
> http://www.apache.org/ . Stick a file in a location it can access and
> clients can stream from it.
> Red5 likely still does HTTP. http://osflash.org/red5
>
> First hit on Google for "Video Streaming Software":
> http://www.videolan.org/vlc/streaming.html
> (VLC can behave as a server as well as doing playback)
> Supports multiple formats and protocols.
>
>
>  Apache is okay, but no security and it can only do http, VLC can do
> different streams but it is only designed for streaming one video and makes
> use of multicast and this is not available with many ISPs, so both of this
> suggestions are unusable.
>
>  Adam
>


-- 
This email proudly and graciously contributes to entropy.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Adam]

Andy wrote:

On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
  

Without looking it up, the previous reply (from a Gnash dev IIRC) was that the 
BBC are
using the latest version of Adobe Flash Streaming Server, and this has dropped 
support for
streaming over HTTP.



I remembered it being described as deprecated. My interpretation of
deprecated is that it isn't recommended to use it but it still can be
used. Normally it means it will be removed sometime in the future. For
instance I can use a Deprecated Method in Java and it will still wok
but I will get a warning and it may be removed from Java in the
future. I therefore assumed that RTMP could still be used but wasn't
the recommended approach. I may have been wrong though. (Why would
anyone remove something useful from a software application anyway?
More importantly why would anyone trust a vendor that did that with
their Mission Critical software applications?).
  
You seem to be confusing yourself as RTMP has not been removed and is 
the recommended approach with http apparently being deprecated. 

They probably removed http streaming as it isn't that efficient and it 
makes it easy for people to download the flv videos.  With the streaming 
the videos are harder to copy plus you get the benefits that if you skip 
forward in a video you don't have to wait for the flv to download to 
that point.

When YouTube upgrade, they too will probably lose support for
streaming over HTTP as well.



They currently stream over HTTP don't they? This the BBC could
*currently* do the same.
  
See above.  Like other people have pointed out when You Tube next 
upgrade they will probably stop the current http streams.

Also, I previously asked you if you knew of any alternatives the BBC could have 
used. To
quote you: "Any chance you could actually answer the questions I asked?"



To quote you:
  

This has also been answered before (the last time you asked it, actually). I'm 
not
entirely convinced you've actually been reading replies, or if you have, 
actually paying
them much attention.



Apache has the power to serve files over HTTP. You should check it out
http://www.apache.org/ . Stick a file in a location it can access and
clients can stream from it.
Red5 likely still does HTTP. http://osflash.org/red5

First hit on Google for "Video Streaming Software":
http://www.videolan.org/vlc/streaming.html
(VLC can behave as a server as well as doing playback)
Supports multiple formats and protocols.

  
Apache is okay, but no security and it can only do http, VLC can do 
different streams but it is only designed for streaming one video and 
makes use of multicast and this is not available with many ISPs, so both 
of this suggestions are unusable.


Adam

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

On Jan 24, 2008 9:11 AM, Andy <[EMAIL PROTECTED]> wrote:
> On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
> > Without looking it up, the previous reply (from a Gnash dev IIRC) was that 
> > the BBC are
> > using the latest version of Adobe Flash Streaming Server, and this has 
> > dropped support for
> > streaming over HTTP.
>
> I remembered it being described as deprecated. My interpretation of
> deprecated is that it isn't recommended to use it but it still can be
> used. Normally it means it will be removed sometime in the future. For
> instance I can use a Deprecated Method in Java and it will still wok
> but I will get a warning and it may be removed from Java in the
> future. I therefore assumed that RTMP could still be used but wasn't
> the recommended approach. I may have been wrong though. (Why would
> anyone remove something useful from a software application anyway?
> More importantly why would anyone trust a vendor that did that with
> their Mission Critical software applications?).
>
I honestly can't tell whether you're being deliberately obtuse or not.
HTTP streaming is deprecated, not RTMP.

HTTP = The old way
RTMP = The new way

While I don't actually see the point either, I'm sure Adobe has its
reasons and since no one has any more suitable suggestions for how to
stream A/V content easily over the web then that's what's being used.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Andy]

On 23/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
> Without looking it up, the previous reply (from a Gnash dev IIRC) was that 
> the BBC are
> using the latest version of Adobe Flash Streaming Server, and this has 
> dropped support for
> streaming over HTTP.

I remembered it being described as deprecated. My interpretation of
deprecated is that it isn't recommended to use it but it still can be
used. Normally it means it will be removed sometime in the future. For
instance I can use a Deprecated Method in Java and it will still wok
but I will get a warning and it may be removed from Java in the
future. I therefore assumed that RTMP could still be used but wasn't
the recommended approach. I may have been wrong though. (Why would
anyone remove something useful from a software application anyway?
More importantly why would anyone trust a vendor that did that with
their Mission Critical software applications?).

> When YouTube upgrade, they too will probably lose support for
> streaming over HTTP as well.

They currently stream over HTTP don't they? This the BBC could
*currently* do the same.

> Also, I previously asked you if you knew of any alternatives the BBC could 
> have used. To
> quote you: "Any chance you could actually answer the questions I asked?"

To quote you:
> This has also been answered before (the last time you asked it, actually). 
> I'm not
> entirely convinced you've actually been reading replies, or if you have, 
> actually paying
> them much attention.

Apache has the power to serve files over HTTP. You should check it out
http://www.apache.org/ . Stick a file in a location it can access and
clients can stream from it.
Red5 likely still does HTTP. http://osflash.org/red5

First hit on Google for "Video Streaming Software":
http://www.videolan.org/vlc/streaming.html
(VLC can behave as a server as well as doing playback)
Supports multiple formats and protocols.

Now I have answered yours will you be answering my other questions?

Andy

-- 
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Phil Wilson]

The BBC knows
this and yet chose RTMP anyway. Any good explanation why HTTP works
for You Tube but not for the BBC? 


This has also been answered before (the last time you asked it, actually). I'm not 
entirely convinced you've actually been reading replies, or if you have, actually paying 
them much attention.


Without looking it up, the previous reply (from a Gnash dev IIRC) was that the BBC are 
using the latest version of Adobe Flash Streaming Server, and this has dropped support for 
streaming over HTTP. When YouTube upgrade, they too will probably lose support for 
streaming over HTTP as well.


Feel free to validate this by searching the archive and checking Adobe's website. If it's 
not true, I'm sure we'd all like to know.


Also, I previously asked you if you knew of any alternatives the BBC could have used. To 
quote you: "Any chance you could actually answer the questions I asked?"


Phil
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

RE: [backstage] RTMP stream URL resolving script

[Deirdre Harvey]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andy
> Sent: 23 January 2008 13:36
> To: backstage@lists.bbc.co.uk
> Subject: Re: [backstage] RTMP stream URL resolving script

> On 22/01/2008, Deirdre Harvey <[EMAIL PROTECTED]> wrote:
> > Any chance you could stop with the accusations of dishonesty?
> 
> Any chance you could actually answer the questions I asked?

No chance at all, sorry. I don't know the answers.


-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Andy]

On 22/01/2008, Deirdre Harvey <[EMAIL PROTECTED]> wrote:
> Any chance you could stop with the accusations of dishonesty?

Any chance you could actually answer the questions I asked?

And if I seem to be a bit annoyed I am. I spent quite a bit of time
writing something and now it looks like it is useless because It was
told FLV/RTMP was like PDF and thus I assumed there would be an easy
way of reading/playing it in Java. I can not find a simple, suitably
licensed way of doing this. (suggestions welcome). (JMF does not
appear to support the BBCs choice of Adobe Formats).

Oddly if the BBC had used the more traditional method of streaming I
could have at least fetched it over HTTP (which is reasonably trivial
in Java) and then tried to run it through something like mPlayer.

And even if I did find a way of doing it in Java it would most likely
not work on anything mobile due to the lack of hardware support for
the format.

The worst thing is the BBC is using these protocols to lock out Linux.
Remember that Adobe Flash is banned on Linux Tablets. The BBC knows
this and yet chose RTMP anyway. Any good explanation why HTTP works
for You Tube but not for the BBC? Other than the BBC is extremely
pro-Microsoft?

Andy

-- 
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

RE: [backstage] RTMP stream URL resolving script

[Deirdre Harvey]

Andy,

Any chance you could stop with the accusations of dishonesty? I think
Ian's general demeanour and hard work for backstage deserve a little
more respect than being accused of being (even unintentionally)
dishonest without good reason. 

I don't get the impression that you mean to be quite so combative and
aggressive, but it kind of sours the atmosphere around here. How about
assuming a misunderstanding the next time and only accusing people of
lying if there is good reason to believe they are trying to mislead you?

d.

Deirdre Harvey :: Web Producer :: BBC Newsline ::
Newsroom :: BBC Broadcasting House :: Ormeau Avenue :: Belfast BT2 8HQ
::
ph. 02890 338264

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Forrester
> Sent: 22 January 2008 18:34
> To: backstage@lists.bbc.co.uk
> Subject: RE: [backstage] RTMP stream URL resolving script
> 
> Oh and I think Mr Forrester may have been a tad dishonest (possibly
> unintentionally) when claiming RTMP and FLV where just like 
> PDF and that anyone can create readers for them. PDF is an 
> ISO standard! I can't find formal standards for RTMP and FLV, 
> did I miss them somewhere? Tried RFC/IETF and ISO, neither 
> have anything.
> 
> 
> I meant before PDF become a ISO standard, and I didn't mean 
> to compare them as standards but rather proprietary standards 
> which got turned into standards.
> 
> Of course it was all unintentional :(
> 
> Sorry for the upset this might have caused :(
> 
> Ian Forrester
> 
> This e-mail is: [x] private; [] ask first; [] bloggable
> 
> Senior Producer, BBC Backstage
> BC5 C3, Media Village, 201 Wood Lane, London W12 7TP
> email: [EMAIL PROTECTED]
> work: +44 (0)2080083965
> mob: +44 (0)7711913293
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andy
> Sent: 22 January 2008 14:02
> To: backstage@lists.bbc.co.uk
> Subject: Re: [backstage] RTMP stream URL resolving script
> 
> On 21/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> > Back to RTMP. I was looking at the documentation and some 
> of the code 
> > for RTMP with a view to maybe porting it into this script. 
> It's really 
> > quite nasty!
> 
> If only there was a nice simple document. Unfortunately it 
> all appears to be reverse engineered. And thus there are 
> parts that are clear guess work (or just plain not defined. 
> Like the randomish data used near the beginning of the handshake).
> 
> At the risk of going wildly of topic. Is there anywhere that 
> describes all this business with remote procedure calls? Does 
> this mean an RTMP client needs to have a full interpreter for 
> some programming language and isn't allowing unauthenticated 
> remote entities to make function calls on your system a "bad 
> idea". I can think of lots of unfriendly function calls one 
> would not want people to make.
> 
> >  Any extensions to this script from me are likely going to 
> be calls to 
> > apps importing the rtmp.c written for Gnash.
> 
> PHP calls to a C library? (Sorry been a very long time since 
> I did PHP, many years, ah the good old days )
> 
> I was trying to write a little something in Java to basically 
> determine what programs where available, what versions where 
> available and some details about them.
> 
> Ran into one massive problem. Well 2, one I have more 
> important commitments that come first, and 2: How does one 
> obtain a list of whats on iPlayer without spidering the 
> entire A to Z each time? Is there something one can put in 
> the filter URL parameter that says "only programs added since 
> X"? Or a way of listing more than 6 entries at a time?
> 
> 
> Oh and I think Mr Forrester may have been a tad dishonest (possibly
> unintentionally) when claiming RTMP and FLV where just like 
> PDF and that anyone can create readers for them. PDF is an 
> ISO standard! I can't find formal standards for RTMP and FLV, 
> did I miss them somewhere? Tried RFC/IETF and ISO, neither 
> have anything.
> 
> Also would it be possible to get the stream in a sensible format?
> If you ever want iPlayer on a mobile use a viable format. For 
> reference Android (Google's Mobile Platform) supports MPEG4 and H.264.
> How about a stream in one of those formats?
> 
> The biggest problem with getting iPlayer on exotic devices is 
> the BBC lack of public documentation and no simple way of 
> finding out things that should be documented fully somewhere.
> 
> As an example here is some questions I had after only a few 
> hours work on some Java code:
> The versions listed on the HTML page have a 

RE: [backstage] RTMP stream URL resolving script

[Ian Forrester]

Oh and I think Mr Forrester may have been a tad dishonest (possibly
unintentionally) when claiming RTMP and FLV where just like PDF and that anyone 
can create readers for them. PDF is an ISO standard! I can't find formal 
standards for RTMP and FLV, did I miss them somewhere? Tried RFC/IETF and ISO, 
neither have anything.


I meant before PDF become a ISO standard, and I didn't mean to compare them as 
standards but rather proprietary standards which got turned into standards.

Of course it was all unintentional :(

Sorry for the upset this might have caused :(

Ian Forrester

This e-mail is: [x] private; [] ask first; [] bloggable

Senior Producer, BBC Backstage
BC5 C3, Media Village, 201 Wood Lane, London W12 7TP
email: [EMAIL PROTECTED]
work: +44 (0)2080083965
mob: +44 (0)7711913293
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy
Sent: 22 January 2008 14:02
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] RTMP stream URL resolving script

On 21/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> Back to RTMP. I was looking at the documentation and some of the code 
> for RTMP with a view to maybe porting it into this script. It's really 
> quite nasty!

If only there was a nice simple document. Unfortunately it all appears to be 
reverse engineered. And thus there are parts that are clear guess work (or just 
plain not defined. Like the randomish data used near the beginning of the 
handshake).

At the risk of going wildly of topic. Is there anywhere that describes all this 
business with remote procedure calls? Does this mean an RTMP client needs to 
have a full interpreter for some programming language and isn't allowing 
unauthenticated remote entities to make function calls on your system a "bad 
idea". I can think of lots of unfriendly function calls one would not want 
people to make.

>  Any extensions to this script from me are likely going to be calls to 
> apps importing the rtmp.c written for Gnash.

PHP calls to a C library? (Sorry been a very long time since I did PHP, many 
years, ah the good old days )

I was trying to write a little something in Java to basically determine what 
programs where available, what versions where available and some details about 
them.

Ran into one massive problem. Well 2, one I have more important commitments 
that come first, and 2: How does one obtain a list of whats on iPlayer without 
spidering the entire A to Z each time? Is there something one can put in the 
filter URL parameter that says "only programs added since X"? Or a way of 
listing more than 6 entries at a time?


Oh and I think Mr Forrester may have been a tad dishonest (possibly
unintentionally) when claiming RTMP and FLV where just like PDF and that anyone 
can create readers for them. PDF is an ISO standard! I can't find formal 
standards for RTMP and FLV, did I miss them somewhere? Tried RFC/IETF and ISO, 
neither have anything.

Also would it be possible to get the stream in a sensible format?
If you ever want iPlayer on a mobile use a viable format. For reference Android 
(Google's Mobile Platform) supports MPEG4 and H.264.
How about a stream in one of those formats?

The biggest problem with getting iPlayer on exotic devices is the BBC lack of 
public documentation and no simple way of finding out things that should be 
documented fully somewhere.

As an example here is some questions I had after only a few hours work on some 
Java code:
The versions listed on the HTML page have a date. What timezone is this meant 
to be in?
Am I correct in thinking the month is 0 indexed? And that the order
is: Year, Month, Day_Of_Month, Hour, Minutes, Seconds With Hour being expressed 
using the 24 hour clock?
And how precisely is Midnight represented?
And which elements are optional in the XML files?
Which elements can be repeated?
What are the different values of the id field in the element error returned 
when a stream is invalid? What do these values mean and when do they occur?
What are the acceptable characters in the PID?
What are the acceptable characters in the Token field?
How precisely does the filter argument in the URL for the iPlayer A to Z 
actually work?
It appears to be some kind of query language, what are the names of fields and 
operators?

Some of those would have been answered by the XML Schemes.

So if you really are interested in exotic platforms, then maybe telling people 
what they need to know would help!

Andy

--
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 22/01/2008, Stephen Stewart-CARDIFF <[EMAIL PROTECTED]> wrote:
> As it happens I've come across an open source flash streaming server
> called Red5 - just starting to have a look at it, but it seems quite
> good.

Did you also look at Cygnal, the Gnash server part? :-)

http://packages.debian.org/sid/gnash-cygnal

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 22/01/2008, Phil Wilson <[EMAIL PROTECTED]> wrote:
>
> > Also would it be possible to get the stream in a sensible format?
> > If you ever want iPlayer on a mobile use a viable format. For
> > reference Android (Google's Mobile Platform) supports MPEG4 and H.264.
> > How about a stream in one of those formats?
>
> Again, I think it's been mentioned before about "suitable streaming servers". 
> Can you
> suggest one?

Because Gnash's Cygnal supports all codecs, even ones not in the Adobe
server, it can support codecs that are more suited to mobile devices,
where power consumption reduction is a priority, that are less
processor intensive.

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

RE: [backstage] RTMP stream URL resolving script

[Stephen Stewart-CARDIFF]

As it happens I've come across an open source flash streaming server
called Red5 - just starting to have a look at it, but it seems quite
good.
Anyone have any more experience with this? 


Stephen Stewart 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson
Sent: 22 January 2008 15:41
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] RTMP stream URL resolving script

Again, I think it's been mentioned before about "suitable streaming
servers". Can you suggest one?

Phil

-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Phil Wilson]

I
can't find formal standards for RTMP and FLV, did I miss them
somewhere? Tried RFC/IETF and ISO, neither have anything.


We have covered this before (multiple times I think).

RTMP is a proprietary protocol. It was reverse-engineered in late 2006 (I think). Adobe 
have not released a specification.


FLV can be either a proprietary format (which has been documented, more info: 
http://www.adobe.com/licensing/developer/fileformat/faq/) or a wrapper around H.264+HE-AAC.



Also would it be possible to get the stream in a sensible format?
If you ever want iPlayer on a mobile use a viable format. For
reference Android (Google's Mobile Platform) supports MPEG4 and H.264.
How about a stream in one of those formats?


Again, I think it's been mentioned before about "suitable streaming servers". Can you 
suggest one?


Phil
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Andy]

On 21/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> Back to RTMP. I was looking at the documentation and some of the code
> for RTMP with a view to maybe porting it into this script. It's really
> quite nasty!

If only there was a nice simple document. Unfortunately it all appears
to be reverse engineered. And thus there are parts that are clear
guess work (or just plain not defined. Like the randomish data used
near the beginning of the handshake).

At the risk of going wildly of topic. Is there anywhere that describes
all this business with remote procedure calls? Does this mean an RTMP
client needs to have a full interpreter for some programming language
and isn't allowing unauthenticated remote entities to make function
calls on your system a "bad idea". I can think of lots of unfriendly
function calls one would not want people to make.

>  Any extensions to this script from me are likely going
> to be calls to apps importing the rtmp.c written for Gnash.

PHP calls to a C library? (Sorry been a very long time since I did
PHP, many years, ah the good old days )

I was trying to write a little something in Java to basically
determine what programs where available, what versions where available
and some details about them.

Ran into one massive problem. Well 2, one I have more important
commitments that come first, and 2: How does one obtain a list of
whats on iPlayer without spidering the entire A to Z each time? Is
there something one can put in the filter URL parameter that says
"only programs added since X"? Or a way of listing more than 6 entries
at a time?


Oh and I think Mr Forrester may have been a tad dishonest (possibly
unintentionally) when claiming RTMP and FLV where just like PDF and
that anyone can create readers for them. PDF is an ISO standard! I
can't find formal standards for RTMP and FLV, did I miss them
somewhere? Tried RFC/IETF and ISO, neither have anything.

Also would it be possible to get the stream in a sensible format?
If you ever want iPlayer on a mobile use a viable format. For
reference Android (Google's Mobile Platform) supports MPEG4 and H.264.
How about a stream in one of those formats?

The biggest problem with getting iPlayer on exotic devices is the BBC
lack of public documentation and no simple way of finding out things
that should be documented fully somewhere.

As an example here is some questions I had after only a few hours work
on some Java code:
The versions listed on the HTML page have a date. What timezone is
this meant to be in?
Am I correct in thinking the month is 0 indexed? And that the order
is: Year, Month, Day_Of_Month, Hour, Minutes, Seconds
With Hour being expressed using the 24 hour clock?
And how precisely is Midnight represented?
And which elements are optional in the XML files?
Which elements can be repeated?
What are the different values of the id field in the element error
returned when a stream is invalid? What do these values mean and when
do they occur?
What are the acceptable characters in the PID?
What are the acceptable characters in the Token field?
How precisely does the filter argument in the URL for the iPlayer A to
Z actually work?
It appears to be some kind of query language, what are the names of
fields and operators?

Some of those would have been answered by the XML Schemes.

So if you really are interested in exotic platforms, then maybe
telling people what they need to know would help!

Andy

-- 
Computers are like air conditioners.  Both stop working, if you open windows.
-- Adam Heath
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

On Jan 21, 2008 1:49 PM, Noah Slater <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 21, 2008 at 01:34:14PM +, Fearghas McKay wrote:
> > [0] #insert smiley.h
>
> You mean #include, surely? Jeez, such a n00b. ;)

OK, that's much more familiar territory :D
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Noah Slater]

On Mon, Jan 21, 2008 at 01:34:14PM +, Fearghas McKay wrote:
> [0] #insert smiley.h

You mean #include, surely? Jeez, such a n00b. ;)

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Fearghas McKay]

On 21 Jan 2008, at 13:12, Iain Wallace wrote:


If this is a flame war then it's the most polite flame war I've ever
seen! You guys can't have ever posted in videogame forums. No one has
even had their sexual leanings questioned yet ;)


nah we are just being polite since you are new ;-)

Normal service will resume after the watershed! [0]

f

[0] #insert smiley.h
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

> > The one that says "Don't push this button"
> >
> > .cf Licencing discussions ad infinitum...
> >
> > Cheers
>
> Maybe he pressed it to see what happens...
>
> Aren't License flame wars fun? ;p
>
If this is a flame war then it's the most polite flame war I've ever
seen! You guys can't have ever posted in videogame forums. No one has
even had their sexual leanings questioned yet ;)

It seems like the controversy around GPLv3 is centred around an
anti-DRM clause, which is fine by me. GPLv3 will be included later
today :)
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Noah Slater]

On Mon, Jan 21, 2008 at 12:41:42PM +, vijay chopra wrote:
> FWIW I personally prefer BSD\MIT style licenses as I consider them to be
> more free than the GPL in that they allow anyone to play with your code in
> any way they like without forcing your own choice of license on
> them.

Of course what you really mean is that you want to give people the
freedom to restrict other peoples freedom, which seems a little
contradictory. But yes, we've argued this before vijay. ;)

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Peter Bowyer]

On 21/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> Any extensions to this script from me are likely going
> to be calls to apps importing the rtmp.c written for Gnash.

Make sure you observe the Gnash license conditions



-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

> At 12:05 + 21/1/08, Iain Wallace wrote:
> >
> >I'm finding this thread quite useful and interesting. Sorry if you
> >don't. You could always just filter it out in your mail client.
>
> If I was objecting to the thread I would have used words like 'ad nauseam'
> rather than 'ad infinitum' - I was just suggesting a scenario for what
> Peter was saying regarding the button.
>
> Licencing threads do come up here quite frequently and are a passionate
> subject for some list members. When you first asked for the discussion I
> thought you were being tongue in cheek as we had a big round of discussions
> last month.
>
> Next time I will put a smiley or something similar.

Ah, thought that might be it :P No, I've only been on the list a few weeks.

Back to RTMP. I was looking at the documentation and some of the code
for RTMP with a view to maybe porting it into this script. It's really
quite nasty! I think it'll be a while before I'm bored enough to
attempt that. Any extensions to this script from me are likely going
to be calls to apps importing the rtmp.c written for Gnash.

Iain
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[vijay chopra]

On 21/01/2008, Fearghas McKay <[EMAIL PROTECTED]> wrote:
>
>
> The one that says "Don't push this button"
>
> .cf Licencing discussions ad infinitum...
>
> Cheers


Maybe he pressed it to see what happens...

Aren't License flame wars fun? ;p

FWIW I personally prefer BSD\MIT style licenses as I consider them to be
more free than the GPL in that they allow anyone to play with your code in
any way they like without forcing your own choice of license on them.
However I've already had that discussion on this list, and don't want to go
there again. I still have the scorch marks.

I also have issues with the restrictive nature of parts of GPLv3 (and I'm
not alone in this), so if you're going to use a the GPL, I'd suggest GPL 2,
if it's good enough for Linux, it's good enough for me. Linus outlines my
complaints better than I can:

http://www.news.com/2100-7344-6031504.html
http://www.informationweek.com/blog/main/archives/2007/07/linux_creator_c.html
http://www.informationweek.com/management/showArticle.jhtml?articleID=198001445

Vijay.

Re: [backstage] RTMP stream URL resolving script

[Fearghas McKay]

Iain

At 12:05 + 21/1/08, Iain Wallace wrote:
>
>I'm finding this thread quite useful and interesting. Sorry if you
>don't. You could always just filter it out in your mail client.

If I was objecting to the thread I would have used words like 'ad nauseam'
rather than 'ad infinitum' - I was just suggesting a scenario for what
Peter was saying regarding the button.

Licencing threads do come up here quite frequently and are a passionate
subject for some list members. When you first asked for the discussion I
thought you were being tongue in cheek as we had a big round of discussions
last month.

Next time I will put a smiley or something similar.

f
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

> >> Did you not see the sign next to the button you just pressed?
> >>
> > I'm sorry?
>
> The one that says "Don't push this button"
>
> .cf Licencing discussions ad infinitum...
>
I'm finding this thread quite useful and interesting. Sorry if you
don't. You could always just filter it out in your mail client.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Fearghas McKay]

On 21 Jan 2008, at 11:36, Iain Wallace wrote:


Did you not see the sign next to the button you just pressed?


I'm sorry?


The one that says "Don't push this button"

.cf Licencing discussions ad infinitum...

Cheers

f
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

On Jan 21, 2008 10:59 AM, Peter Bowyer <[EMAIL PROTECTED]> wrote:
> On 20/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> > Maybe we need a discussion on the pros and cons of the various OSS
> > licenses. Recommend me one!
>
> Did you not see the sign next to the button you just pressed?
>
I'm sorry?
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Peter Bowyer]

On 20/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> Maybe we need a discussion on the pros and cons of the various OSS
> licenses. Recommend me one!

Did you not see the sign next to the button you just pressed?


-- 
Peter Bowyer
Email: [EMAIL PROTECTED]
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 20/01/2008, Dave Crossland <[EMAIL PROTECTED]> wrote:
> On 20/01/2008, Michael Sparks <[EMAIL PROTECTED]> wrote:
> >
> > It's worth noting that license 5 is the weakest level of control a developer
> > can exert. Someone can take your work and either restrict your ability to 
> > take
> > changes (that you can release as 5) by either re-releasing your work in a
> > derivative licensed under 4) or 1).
>
> This is a common misconception.

I'd like to retract my assertion that Michael misconceived of the
licensing situation for "5" style licenses in relation to "4" style
ones. What he says above is correct, and I apologise for suggesting
otherwise.

There is an issue related to what he said that I am reminded of by
what he said: Wanting a BSD only codebase is substantially different
from GPL parts _needing_ the whole codebase to be GPL.

If someone _wants_ a codebase to remain _fully_ under "5" style (X11)
licenses, they will not be able to do so if someone makes a
contribution to the codebase under a "4" style (GPL) license.

But there is no _need_ for a codebase to remain fully under X11 style
licenses, and no _need_ for a codebase to remain fully under GPL style
licenses either.

It is possible for a codebase to be a mix of X11 and GPL style
licenses, even having code under two licenses in one file.

The GPL does not require all code in a program to be GPL, only to be
GPL compatible.

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Michael Sparks]

On Monday 21 January 2008 08:47:27 Dave Crossland wrote:
...
> > At that point I'm bowing out of that discussion, since otherwise I'll be
> > breaking a new year's resolution :)
> My apologies if I cause you to break it, but this is a sutble point of
> GPL licensing I only understood a few months ago.

I'm sorry, I'm not playing - especially if you fail to read what's written.
I'll try one last time off list, but it's incredibly tedious when you present 
bogus arguments without reading what's written.


Michael.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

Apparently my mail client is messing up my line endings. Apologies,
please see http://pastebin.com/f281a6f41
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 21/01/2008, Michael Sparks <[EMAIL PROTECTED]> wrote:> On Sunday 20 January 
2008 21:33:18 Dave Crossland wrote:>> The resulting work (as a whole) has to be 
under the Affero GPL V3
The resulting work (as a whole) has to be under licenses compatiblewith the 
Affero GPL V3. That means, _no more restrictive_ than it;since the X11 license 
is less restrictive, they can be combined undermixed licenses.
> The new> improved gameover.c cannot be recombined back into the original 
> work> without the original developer changing their license or without the> 
> recipient granting them a BSD license on the new gameover.c .
This is incorrect :-) The Affero code can even be copied into theoriginal X.c, 
as 
perhttp://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-40002.2
> > With most "5" style licenses, such as X11 or BSD licenses, you can not> > 
> > relicense (technically, "sublicense") the source code under "4" style> > 
> > licenses,>> That is not what I said. I said:>> > > re-releasing your work 
> > in a derivative licensed under 4) or 1).>> That's not the same as what you 
> > said. (Take a BSD program, add in a call to> GNU readline without which the 
> > program won't function & the derivative work> has to be licensed as a whole 
> > as GPL - ie "a derivative licensed under 4)" )
If you write FreeBSD licensed code, and I add in a call to GNUreadline without 
which the program won't function, the derivative workhas to be licensed as a 
whole as GPL-or-less, ie "a derivativelicensed under 4) and 5)".
Your FreeBSD code remains under the license you specified, becausethat license 
does not permit sublicensing. If I distributed thederivative work licensed as a 
whole as GPL, I would be illegallysublicensing your code.
> > but you can combine sourcecode files with mixed licenses> > into a single 
> > program.>> Absolutely, and you also have to remember that if a project that 
> > was BSD> licensed only, if you add GPL'd portions in, those GPL'd 
> > extensions and> modifications cannot be reincorporated back into the BSD 
> > mainline (without> changing the license of the mainline or without a BSD 
> > license being granted> back to (at minimum) the mainline) - as demonstrated 
> > above.
Those GPL'd extensions and modifications can be reincorporated backinto the BSD 
mainline (without changing the license of the mainline orwithout a BSD license 
being granted back to (at minimum) the mainline)but "in a single source file it 
is typically very difficult, and oftencompletely infeasible, to determine which 
parts of such a file arecovered by permissive terms. If the goal is to make 
additional codeavailable under permissive terms only, the method described in § 
2.3should be used."
§ 2.3 = 
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html#x1-50002.3
> So, whilst the code is open & free software, the improvements are denied> to 
> the original developer (unless they change their license of their system> as 
> a whole, or cease redistributing), in a /similar/ way that the code being> 
> released as proprietary software denies the same author access to code.
The improvements are free software though, so no essential softwarefreedom is 
trampled. Let's not get religious about licensing, eh? :-D
> At that point I'm bowing out of that discussion, since otherwise I'll be> 
> breaking a new year's resolution :)
My apologies if I cause you to break it, but this is a sublte point ofGPL 
licensing I only understood a few months ago.
-- Regards,Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Michael Sparks]

On Sunday 20 January 2008 21:33:18 Dave Crossland wrote:
> On 20/01/2008, Michael Sparks <[EMAIL PROTECTED]> wrote:
> > It's worth noting that license 5 is the weakest level of control a
> > developer can exert. Someone can take your work and either restrict your
> > ability to take changes (that you can release as 5) by either
> > re-releasing your work in a derivative licensed under 4) or 1).
>
> This is a common misconception.

No, it's not a misconception. It's trivial to demonstrate with a useless toy
program. You can easily extend this to any larger work.

Suppose for example I create a program X:

(none of this is intended/likely to compile btw - it's an illustration :-)

X.c
/* licensed under the BSD license */
#include 

void gameover() {
printf("gameover\n");
}

int main(int argc, char *argv) {
   gameover()
   return 0;
}
/* - */

Recipient A refactors this:

gameover.c
/* licensed under the BSD license */
void gameover() {
printf("gameover\n");
}

X.c
/* licensed under the BSD license */
#include 
#include "gameover.c"

int main(int argc, char *argv) {
   gameover();
   return 0;
}
/* - */

That's a compliant change.

They create a test suite as well which tests that the file:
   * gameover.c contatins a function gameover that performs in a particular
  way. (Not unusual to add tests when refactoring)

Recipient B then creates API compatible reimplementation of gameover.c
based on this test, not based on the code. This is again, a compliant
change (throwing away code and writing your own).

gameover.c - from B
/* licensed under the Affero GPL V3 */
#include 
void
gameover() {
fprint(stdout, "gameover\n");
}

X.c - from B
/* licensed under the BSD license */
#include 
#include "gameover.c"

int main(int argc, char *argv) {
   gameover();
   return 0;
}
/* - */

The resulting work (as a whole) has to be under the Affero GPL V3. (The
individual files are under separate licenses at this point though). The new
improved gameover.c cannot be recombined back into the original work
without the original developer changing their license or without the
recipient granting them a BSD license on the new gameover.c .

(this is indeed, part of the point of the GPL - if the original developer
could do recombine the new GPL only code without an explicit BSD grant or 
without changing their license, the GPL wouldn't be doing it's job of
ensuring that new code stayed GPL - whatever version you pick :)

> With most "5" style licenses, such as X11 or BSD licenses, you can not
> relicense (technically, "sublicense") the source code under "4" style
> licenses, 

That is not what I said. I said:

> > re-releasing your work in a derivative licensed under 4) or 1).

That's not the same as what you said. (Take a BSD program, add in a call to 
GNU readline without which the program won't function & the derivative work 
has to be licensed as a whole as GPL - ie "a derivative licensed under 4)" )

> but you can combine sourcecode files with mixed licenses 
> into a single program.

Absolutely, and you also have to remember that if a project that was BSD
licensed only, if you add GPL'd portions in, those GPL'd extensions and
modifications cannot be reincorporated back into the BSD mainline (without
changing the license of the mainline or without a BSD license being granted
back to (at minimum) the mainline) - as demonstrated above.

So, whilst the code is open & free software, the improvements are denied
to the original developer (unless they change their license of their system
as a whole, or cease redistributing), in a /similar/ way that the code being
released as proprietary software denies the same author access to code.

That's what I meant by :

> > It's worth noting that license 5 is the weakest level of control a
> > developer can exert. Someone can take your work and either restrict your
> > ability to take changes (that you can release as 5) by either
> > re-releasing your work in a derivative licensed under 4) or 1).

As a specific example, the originator of the work (X.c) would not be able to
take the changes (improvements) in the GPL'd derivative (gameover.c, X.c
from B) to incorporate back into their BSD (only) version. If they could, the
GPL would be bust.

Note: I'm not passing a judgement on this being good or bad, just expanding
on what I said.

At that point I'm bowing out of that discussion, since otherwise I'll be 
breaking a new year's resolution :)

:-)


Michael.
--
*personal opinions only & not a lawyer :) *
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 20/01/2008, Matthew Somerville <[EMAIL PROTECTED]> wrote:
>
> I can't see any difference between the Expat licence and the X11 license
> which you include above

You are right, there is none, I stand corrected; apologies and thank
you for pointing this out :-)

I remembered X11 being under BSD but it is under the Expat license.
I'll drop "expat" since its obscure and refer to X11 from now on :-)

> I can't see your earlier linking either,

Ah, it was in an offlist mail; apologies

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Matthew Somerville]

Dave Crossland wrote:

With most "5" style licenses, such as X11 or BSD licenses, you can not
relicense (technically, "sublicense") the source code under "4" style
licenses, but you can combine sourcecode files with mixed licenses
into a single program.


[...]


The Expat license, that I linked to earlier in the thread, permits
sublicensing, which is why I recommend it.


I can't see any difference between the Expat licence and the X11 license 
which you include above (I can't see your earlier linking either, I'm 
looking at the one at http://www.jclark.com/xml/copying.txt as compared to 
http://www.xfree86.org/3.3.6/COPYRIGHT2.html#3 ).


ATB,
Matthew  |  http://www.dracos.co.uk/
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

> That's misleading (I'm sure non-intentionally). Microsoft have indeed used BSD
> code in their systems in the past and as I recall it was the TCP/IP stack -
> or portions thereof

Hmmm I meant aside from the TCP/IP stack -- after all, David Wheeler
mentions that in the article I linked to -- I should have been more
explicit. But, again, I have no proof, so l will call it just a rumor
:-)

However I am not at all sure Microsoft respects its licensing
obligations regarding reused code. The Services for Unix package
contains licence texts (including GPLv1, GPLv2, and BSD) but no source
code, nor any indication of where to find it.

Sean


On Jan 20, 2008 10:35 PM, Michael Sparks <[EMAIL PROTECTED]> wrote:
> On Sunday 20 January 2008 17:01:43 Sean DALY wrote:
> > A longstanding rumor, for which I have no proof, is that parts of
> > Microsoft's network code was simply copied from BSD code, which if
> > true would naturally explain why Microsoft is so hesitant to documents
> > its protocols not to mention its code.
>
> That's misleading (I'm sure non-intentionally). Microsoft have indeed used BSD
> code in their systems in the past and as I recall it was the TCP/IP stack -
> or portions thereof. This isn't exactly uncommon and if you're choosing a
> TCP/IP stack to use, there are worse choices :-)
>
> However they *have* complied with the BSD license - if you look in the manuals
> distributed with windows you will find the appropriate statements.
>
> It is however not exactly a secret (or even a rumour!) - eg it's trivial to
> find here:
> * http://support.microsoft.com/kb/306819/en-us
>
> (you'll see the various notices they're required to include)
>
> I *believe* (but have no evidence beyond "I've been told") that they've been
> reported to have rewritten that code since then, so I'd guess they no longer
> need those statements. (I don't have a copy of Vista, so can't (and have no
> inclination to) check :)
>
> The reason for Microsoft not documenting it protocols and code in the way
> demanded by some is IMO likely to be for some other reason. I'm going to
> refrain from speculating why. I will note that documenting protocols allows
> for multiple implementations - enabling competition. I suspect therefore
> their decision is based on whether they can see value in competition in that
> space or not. (if it grows the market, then everyone benefits including them -
> since although their share shrinks the pie grows increasing their income. If
> the market is at peak size, it shrinks their market share whilst not growing
> the size of the pie, reducing their income)
>
> Beyond speculating that their decision is based on cold hard money, I'm not
> speculating further :-)
>
>
> Michael.
>
> *personal opinions only*
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Michael Sparks]

On Sunday 20 January 2008 17:01:43 Sean DALY wrote:
> A longstanding rumor, for which I have no proof, is that parts of
> Microsoft's network code was simply copied from BSD code, which if
> true would naturally explain why Microsoft is so hesitant to documents
> its protocols not to mention its code.

That's misleading (I'm sure non-intentionally). Microsoft have indeed used BSD 
code in their systems in the past and as I recall it was the TCP/IP stack - 
or portions thereof. This isn't exactly uncommon and if you're choosing a 
TCP/IP stack to use, there are worse choices :-)

However they *have* complied with the BSD license - if you look in the manuals 
distributed with windows you will find the appropriate statements.

It is however not exactly a secret (or even a rumour!) - eg it's trivial to
find here:
* http://support.microsoft.com/kb/306819/en-us

(you'll see the various notices they're required to include)

I *believe* (but have no evidence beyond "I've been told") that they've been
reported to have rewritten that code since then, so I'd guess they no longer
need those statements. (I don't have a copy of Vista, so can't (and have no
inclination to) check :)

The reason for Microsoft not documenting it protocols and code in the way
demanded by some is IMO likely to be for some other reason. I'm going to 
refrain from speculating why. I will note that documenting protocols allows 
for multiple implementations - enabling competition. I suspect therefore 
their decision is based on whether they can see value in competition in that
space or not. (if it grows the market, then everyone benefits including them - 
since although their share shrinks the pie grows increasing their income. If 
the market is at peak size, it shrinks their market share whilst not growing 
the size of the pie, reducing their income)

Beyond speculating that their decision is based on cold hard money, I'm not 
speculating further :-)


Michael.

*personal opinions only*
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

On Jan 20, 2008 9:10 PM, Michael Sparks <[EMAIL PROTECTED]> wrote:
> On Sunday 20 January 2008 15:35:12 Iain Wallace wrote:
> > Maybe we need a discussion on the pros and cons of the various OSS
> > licenses. Recommend me one!
>
> Summary: 

That's really useful, thanks! I think I'll go for a GPL license. I
can't really imagine why someone wouldn't want reciprocity in their
license. If someone makes something cool from my code I want to read
the source and see how they did it. I'll read up on GPLv3 and AGPLv3.

Iain
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 20/01/2008, Michael Sparks <[EMAIL PROTECTED]> wrote:
>
> It's worth noting that license 5 is the weakest level of control a developer
> can exert. Someone can take your work and either restrict your ability to take
> changes (that you can release as 5) by either re-releasing your work in a
> derivative licensed under 4) or 1).

This is a common misconception.

With most "5" style licenses, such as X11 or BSD licenses, you can not
relicense (technically, "sublicense") the source code under "4" style
licenses, but you can combine sourcecode files with mixed licenses
into a single program.

http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
explains how to do this in depth.

The Expat license, that I linked to earlier in the thread, permits
sublicensing, which is why I recommend it.

-- 
Regards,
Dave
(Personal opinion only!)
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Michael Sparks]

On Sunday 20 January 2008 15:35:12 Iain Wallace wrote:
> Maybe we need a discussion on the pros and cons of the various OSS
> licenses. Recommend me one!

Summary:
   1 Copyright notice applied & enforced.
   2 No license - falls back to copyright law.
   3 Implied license (what you've done) - tentatively allowed to do stuff, but
  not very strong license as to what can be done with it. (technically
  falls back to copyright law meaning can't do anything, but your email is
  an implied license))
   4 License with "reciprocity clause". This means "if you do things (eg
  create a derivative work) with my code under this license and you
  redistribute this, you have to redistribute your code under the same
  license". Examples: GPL, MPL
   5 License without reciprocity clause. Not quite but close to "do what you
  like with this, but attribute me & don't remove this notice", doesn't
  constrain your choice of license for derivative work.
  Examples: BSD, MIT, Apache licenses
   6 Notice saying "released to the public domain". Unfortunately, as I
  understand things, not actually doable in the UK. 

Since 6 can't be done in the UK, many people who would choose 6 use 5. 

It's worth noting that license 5 is the weakest level of control a developer
can exert. Someone can take your work and either restrict your ability to take
changes (that you can release as 5) by either re-releasing your work in a
derivative licensed under 4) or 1). People who are don't like this (for 
various reasons) with this often choose either 4 or 1 up-front. 

Both the 4) & 5) camps can produce evidence as to why each is better than the 
other for various purposes, so I'm going to refrain from that :) Both camps 
can give ideological as well as pragmatic reasons in favour of their views as 
well.

Lawrence Rosen's book is also very readable: 
   * Open Source Licensing - ISBN: 0131487876

Different licenses have different benefits for differing groups. One creates
an artificial scarce resource that can be exploited for financial gain, one
can be used with an intent to allow all users to be able to modify and extend
the code by aiming to protect this ability from being taken away, and one 
allows the developer to wash their hands of this and make it someone else's 
problem :-)

Regards,


Michael.

 *This is not legal advice, and any opinions there not really intended, and
   certainly not anyone else's or any company's either :-) *
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Noah Slater]

On Sun, Jan 20, 2008 at 06:23:31PM +, Dave Crossland wrote:
> How would you feel if some developer who receive your program can
> improve it and then tell people, even you as the original author, that
> you can't share that version with your friends, or see how their
> improvement works, or build upon their work as they built upon yours?

I am a CouchDB developer. 

We recently switched from GPL to the Apache licence. Now, I would like
to get it out of the way that I am unhappy with the switch, but as I
am not the primary developer, I decided to go along with the move.

The reason I am not happy is because Amazon could come along one day
and take all the code I had slaved over for so many hours, put a team
of 10 developers on improving it full time, and then release as a
competing product, be that closed source or via a web service.

Suddenly, all that time I had put into the project is being used
against me to compete. Not only that, but the competing product is
completely non-free, so it's not like /anyone/ benifits.

> Sean mentions GPLv3 may be criticised for being "too complicated" but
> that seems like a sham to me; the GPL isn't longer than an average
> sunday newspaper article and is written for a software developer
> audience in mind.

Lets remember that we are talking about legal documents here, not
poems. That the GPL is so long is a testiment to how complicated
copyright law is any how many precautions need to be taken to prevent
things like I just described from happening.

-- 
Noah Slater 

"Creativity can be a social contribution, but only in so far as
society is free to use the results." - R. Stallman
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Rob Myers]

Dave Crossland wrote:

Sean mentions GPLv3 may be criticised for being "too complicated" 


The GPL2 was "too complicated" until GPL3 was released. Now GPL2 is 
perfect. ;-) The FSF should release a GPL4, let that be criticized for 
being too complex, withdraw it, and then everyone will be happy. ;-)


- Rob.
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 20/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
>
> Maybe we need a discussion on the pros and cons of the various OSS
> licenses. Recommend me one!

Using any free software license is good, and I hope you'll consider
which is best based on how they promote and protect software freedoms
for _all_ users of your program.

How would you feel if some developer who receive your program can
improve it and then tell people, even you as the original author, that
you can't share that version with your friends, or see how their
improvement works, or build upon their work as they built upon yours?

I would feel annoyed if that happened to me - even angry, if I had put
a lot of effort into the program. Peter Ferne has suggested that using
a free software license that permits that kind of antisocial behavior
would "keep everyone happy," but I think by "everyone" he means only a
few proprietary developers, not all the users of your program.

The GPL ensures this won't happen for software that runs on everyone's
own computers, and the Affero GPL ensures this won't happen for
software that runs on network servers.

http://www.gnu.org/licenses/quick-guide-gplv3.html explains why the
GPL is the best license for making a program free and keeping it that
way.

Because this might program may be run on a server and used though a
network, the Affero GPLv3 is better than the plain GPLv3. AGPLv3 is a
cutting edge license, just released in November last year, and a good
example of an Affero webapp you may have used is
http://petitions.pm.gov.uk/ :-)

Sean mentions GPLv3 may be criticised for being "too complicated" but
that seems like a sham to me; the GPL isn't longer than an average
sunday newspaper article and is written for a software developer
audience in mind.

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

I have found David Wheeler's analysis of the GPL vs. BSD-style
licences very helpful:

GPL, BSD, and NetBSD - why the GPL rocketed Linux to success
http://www.dwheeler.com/blog/2006/09/01/

Debates on this topic can be endless, in particular since the arrival
of the GPLv3 which had to be updated 17 years after its introduction
in 1991 and which is usually criticised for being "too complicated"
compared to GPLv2 or BSD. That said, I agree with Mr. Wheeler that the
GPL is a stronger incentive for companies to fight fair.

A longstanding rumor, for which I have no proof, is that parts of
Microsoft's network code was simply copied from BSD code, which if
true would naturally explain why Microsoft is so hesitant to documents
its protocols not to mention its code.

Sean



On Jan 20, 2008 4:35 PM, Iain Wallace <[EMAIL PROTECTED]> wrote:
> Maybe we need a discussion on the pros and cons of the various OSS
> licenses. Recommend me one!
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

Maybe we need a discussion on the pros and cons of the various OSS
licenses. Recommend me one!
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

I stand corrected. Concerning Corporation X, I should have said
"without attribution and without source code".

Sean


On Jan 19, 2008 2:22 PM, Dave Crossland <[EMAIL PROTECTED]> wrote:
> On 19/01/2008, Sean DALY <[EMAIL PROTECTED]> wrote:
> > Well, it's "public domain" then, which is fine
>
> The public domain exists in the UK only for works that have expired
> from copyright; its only in the USA that you can legally assign a work
> into the public domain before its term expires. Thus Creative Commons
> recently retracted its "PD" license in favor of "CC 0".
>
> > as long as you don't
> > mind Corporation X incorporating and selling your code.
>
> The GPL doesn't prohibit Corporation X incorporating and selling your code.
>
> --
> Regards,
> Dave
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 19/01/2008, Sean DALY <[EMAIL PROTECTED]> wrote:
> Well, it's "public domain" then, which is fine

The public domain exists in the UK only for works that have expired
from copyright; its only in the USA that you can legally assign a work
into the public domain before its term expires. Thus Creative Commons
recently retracted its "PD" license in favor of "CC 0".

> as long as you don't
> mind Corporation X incorporating and selling your code.

The GPL doesn't prohibit Corporation X incorporating and selling your code.

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Sean DALY]

Well, it's "public domain" then, which is fine as long as you don't
mind Corporation X incorporating and selling your code.

Often, a simple copyright notice saying "this notice must accompany
all subsequent versions of this code" is better than nothing.

Sean




On Jan 19, 2008 12:46 AM, Iain Wallace <[EMAIL PROTECTED]> wrote:
> > >> I'll do that, but for now it's for anyone to use. If you make
> > >> something amazing from it, credit me in the readme ;)
> > >
> > > I don't want to get into a discussion about the pros and cons of
> > > GPL v3 but I would much prefer to see an MIT or BSD style licence.
> > > Can I put in a plea for dual licensing to keep everybody happy?
> >
> > Well I have to say that Iain's licence seems so much more simple,
> > understandable and easy to use :-)
> >
> Yes, the previous discussion is an example of why I don't
> automatically stick licenses on my code. Maybe everyone else has read
> the relevant open source licenses in detail and weighed up the pros
> and cons of each, but I haven't and it's unlikely I'll ever be bored
> enough to do so.
>
> At the end of the day, aren't we all just trying to advance each
> other's understanding? And maybe get a mention on El Reg ;)
>
> I'm not going to sue anyone for using a code snippet I wrote one evening.
>
> Iain
>
> -
> Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
> visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
> Unofficial list archive: 
> http://www.mail-archive.com/backstage@lists.bbc.co.uk/
>
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

> >> I'll do that, but for now it's for anyone to use. If you make
> >> something amazing from it, credit me in the readme ;)
> >
> > I don't want to get into a discussion about the pros and cons of
> > GPL v3 but I would much prefer to see an MIT or BSD style licence.
> > Can I put in a plea for dual licensing to keep everybody happy?
>
> Well I have to say that Iain's licence seems so much more simple,
> understandable and easy to use :-)
>
Yes, the previous discussion is an example of why I don't
automatically stick licenses on my code. Maybe everyone else has read
the relevant open source licenses in detail and weighed up the pros
and cons of each, but I haven't and it's unlikely I'll ever be bored
enough to do so.

At the end of the day, aren't we all just trying to advance each
other's understanding? And maybe get a mention on El Reg ;)

I'm not going to sue anyone for using a code snippet I wrote one evening.

Iain
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Fearghas McKay]

On 18 Jan 2008, at 17:57, Peter Ferne wrote:


I'll do that, but for now it's for anyone to use. If you make
something amazing from it, credit me in the readme ;)


I don't want to get into a discussion about the pros and cons of  
GPL v3 but I would much prefer to see an MIT or BSD style licence.  
Can I put in a plea for dual licensing to keep everybody happy?


Well I have to say that Iain's licence seems so much more simple,  
understandable and easy to use :-)


Iain - Thanks for the updated code I am sure it will see lots of use :-)

f


-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 18/01/2008, Peter Ferne <[EMAIL PROTECTED]> wrote:
> >> This is a great contribution - please consider licensing it under a
> >> free software license :-)
> >>
> >> ... I recommend the Affero GPLv3 :-)
> >
> > I'll do that, but for now it's for anyone to use. If you make
> > something amazing from it, credit me in the readme ;)
>
> I don't want to get into a discussion about the pros and cons of GPL
> v3 but I would much prefer to see an MIT or BSD style licence.

The purpose of dual licensing under a GPL and another free software
license is to provide GPL compatibility when the other license is not
GPL compatible for some minor reason. The GPLv3 resolves many of these
minor reasons, and the MIT and revised BSD licenses are already GPL
compatible so there is no reason to dual license with them.

> Can I put in a plea for dual licensing to keep everybody happy?

Can I put in a plea for Affero GPL licensing to keep software freedom
protected, even for web apps? :-)

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Peter Ferne]

This is a great contribution - please consider licensing it under a
free software license :-)

... I recommend the Affero GPLv3 :-)


I'll do that, but for now it's for anyone to use. If you make
something amazing from it, credit me in the readme ;)


I don't want to get into a discussion about the pros and cons of GPL  
v3 but I would much prefer to see an MIT or BSD style licence. Can I  
put in a plea for dual licensing to keep everybody happy?


TIA
--
petef
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Iain Wallace]

On Jan 18, 2008 4:26 PM, Dave Crossland <[EMAIL PROTECTED]> wrote:
> On 18/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
> >
> > It's written for PHP5 to be run from the command line under linux, e.g.
>
> This is a great contribution - please consider licensing it under a
> free software license :-)
>
> To do so, simply include a line like "Copyright (c) 2008, Your Name.
> See License.txt for details" in the source code, and then a
> license.txt in the zip file with the license you choose. I recommend
> the Affero GPLv3 :-)

I'll do that, but for now it's for anyone to use. If you make
something amazing from it, credit me in the readme ;)

Iain
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

Re: [backstage] RTMP stream URL resolving script

[Dave Crossland]

On 18/01/2008, Iain Wallace <[EMAIL PROTECTED]> wrote:
>
> It's written for PHP5 to be run from the command line under linux, e.g.

This is a great contribution - please consider licensing it under a
free software license :-)

To do so, simply include a line like "Copyright (c) 2008, Your Name.
See License.txt for details" in the source code, and then a
license.txt in the zip file with the license you choose. I recommend
the Affero GPLv3 :-)

-- 
Regards,
Dave
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/

[backstage] RTMP stream URL resolving script

[Iain Wallace]

Apologies if this is the second time this has hit the list...

This is a slightly better version of the script that I posted in the
XBMC forums thread that was linked in the "exotic devices" thread.
There are a number of people on here writing code to work out the RTMP
stream URL who might benefit from not having to do all the working out
themselves and just porting/improving this script.

http://strawp.net/files/download/iplayer_url.zip

It's written for PHP5 to be run from the command line under linux, e.g.

[EMAIL PROTECTED]:~$ iplayer_url b008s272
Getting meta data from
http://www.bbc.co.uk/iplayer/metafiles/episode/b008s272.xml...
Setting PID as b008s26r, based on versions available
title: Never Mind the Buzzcocks: Series  21
subtitle: Episode 9
Getting media selector from
http://www.bbc.co.uk/mediaselector/3/stream/check/iplayer?pid=b008s26r...

Stream URL:
rtmp://217.243.192.45:1935/ondemand?_fcs_vhost=cp41752.edgefcs.net&auth=daEd3aVavd8bZcDcQcyb.a.cjdrdJbYcWcb-bhKin0-b4-GnsDBqwoGDwGpyG&aifp=v001&slist=secure/b0008s26r-streaming68716188

Windows users might have to tweak it a little.

I don't have anything to test these in currently, but they appear to
match the URLs that the flash client produces.

Secondly, based on the replies that people post way after I post to
the thread, there's either a really big delay in my messages getting
through or they're not getting through at all. Could someone reply to
this when they get it. Due to the way gmail lays out the inbox you
can't really tell when the list server re-sends messages.

It's getting quite annoying having someone post the exact same thing I
just posted...

Cheers,
Iain
-
Sent via the backstage.bbc.co.uk discussion group.  To unsubscribe, please 
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.  
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/