On 31 January 2010 21:47, Mo McRoberts wrote:
>
> On 31-Jan-2010, at 20:58, Brian Butterworth wrote:
>
> > Hell freezes over? Or
> http://www.bbc.co.uk/info/policies/syndication.shtml perhaps.
>
> The latter was what I had in mind…
>
> > I would have a play with get_player on the command line, t
On 31-Jan-2010, at 20:58, Brian Butterworth wrote:
> Hell freezes over? Or http://www.bbc.co.uk/info/policies/syndication.shtml
> perhaps.
The latter was what I had in mind…
> I would have a play with get_player on the command line, that shows what
> other format there really out there.
I’m
On 31 January 2010 20:35, Mo McRoberts wrote:
>
> What happens to news.bbc.co.uk when the number of users who DON’T have
> Flash support is significant? i.e., measured in hundreds of thousands? What
> about iPlayer? What happens when the in-browser DRM option ceases to exist?
>
Hell freezes over
On 27-Jan-2010, at 16:19, Dave Crossland wrote:
> Well exactly, there are THREE main desktops, and one doesn't and wont have
> h264 preinstalled.
>
> This wouldn't be a problem if The Guardian and other news broadcasters
> stopped bystanding and made the videos they publish available in Xiph f
Well exactly, there are THREE main desktops, and one doesn't and wont have
h264 preinstalled.
This wouldn't be a problem if The Guardian and other news broadcasters
stopped bystanding and made the videos they publish available in Xiph
formats earlier; they continue to squander their significant in
> That's on-demand content, not broadcast. The two are encoded
> via separate systems.
Were we not talking about the iPlayer videos?... derp
-
Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Un
On 27 Jan 2010, at 11:59, Christopher Woods wrote:
>> On 27 Jan 2010, at 08:31, Mo McRoberts wrote:
>>> that's a good point: I wonder how much of the broadcast output *is*
>>> encoded in real-time? all of it?
>>
>> I believe so.
>
>
> Not unless they've changed their previous policy of ingesti
> On 27 Jan 2010, at 08:31, Mo McRoberts wrote:
> > that's a good point: I wonder how much of the broadcast output *is*
> > encoded in real-time? all of it?
>
> I believe so.
Not unless they've changed their previous policy of ingesting popular /
headline shows prior to their airing, then maki
On 27 Jan 2010, at 08:31, Mo McRoberts wrote:
> that's a good point: I wonder how much of the broadcast output *is*
> encoded in real-time? all of it?
I believe so.
> after all, live programming is in the minority on BBC1-4, and assuming
> things sit on sensible boundaries and are pre-packetised
Kieran Kunhya wrote:
For 720p25 you might need more than 3.5Mbps for more
demanding scenes. (Except increasing the bitrate or using a
better encoder will make iPlayer look better than the
broadcast...)
You do get an awful lot better results when you
are not compressing in real time, of course, b
From: Brian Butterworth
> On DVB-T it is everything. BBC One used to have reserved bandwidth, but is
> now statmuxed with everything else. My assumption is the BBC delivers
> motion-JPEG to the regional encoders and the services are statmuxed from
> there.
Don't know the gory technical details,
> For 720p25 you might need more than 3.5Mbps for more
> demanding scenes. (Except increasing the bitrate or using a
> better encoder will make iPlayer look better than the
> broadcast...)
>
> You do get an awful lot better results when you
> are not compressing in real time, of course, because yo
2010/1/27 Mo McRoberts
> On Wed, Jan 27, 2010 at 08:20, Brian Butterworth
> wrote:
>
> > You do get an awful lot better results when you are not compressing in
> real
> > time, of course, because you can use all the MPEG4 forward references,
> the
> > ones you don't get when you real time encode
On Wed, Jan 27, 2010 at 08:20, Brian Butterworth wrote:
> You do get an awful lot better results when you are not compressing in real
> time, of course, because you can use all the MPEG4 forward references, the
> ones you don't get when you real time encode.
that's a good point: I wonder how muc
2010/1/26 Kieran Kunhya
>
>
> For 720p25 you might need more than 3.5Mbps for more demanding scenes.
> (Except increasing the bitrate or using a better encoder will make iPlayer
> look better than the broadcast...)
>
You do get an awful lot better results when you are not compressing in real
tim
> Having said all that, my entirely subjective conclusions at
> the moment are that the 720p video I get out of ffmpeg+x264
> when encoded as Baseline at around 3Mbps[0] compares
> extremely favourably to the iPlayer HD content (which is
> High profile, if memory serves) at the same bitrate. I
> do
On 26-Jan-2010, at 20:19, Kieran Kunhya wrote:
> Older macs without H.264 hardware acceleration also have a very basic version
> of the spec through Quicktime because Apple don't seem to fix any bugs with
> it.
It’s not just older Macs. Basically, if you don’t restrict yourself to Baseline
yo
> What I don't understand is that of the three main desktop
> platforms
> Firefox gets installed on - Windows and Mac - both have
> H.264 decoders
> *on the machine already* in the form of Windows Media and
> QuickTime
> APIs. Microsoft and Apple have presumably solved whatever
> licensing
> proble
There should have been another sentence in my post, sorry. Yes, xvid being
divx backwards is a geeky joke.
Of course DivX ;-) in itself was a sly homage to a doomed-to-fail industry
attempt :D And before XviD, once upon a time its parent was called Project
Mayo... Remember that heady time of
There should have been another sentence in my post, sorry. Yes, xvid being
divx backwards is a geeky joke.
2010/1/26 Paul Webster
> On Tue, 26 Jan 2010 15:17:34 +, Brian wrote:
>
>
>
> >Aside from this XVID is DIVX backwards. This is because all the ITU-T
> >standards are DECODING standa
On Tue, 26 Jan 2010 15:17:34 +, Brian wrote:
>Aside from this XVID is DIVX backwards. This is because all the ITU-T
>standards are DECODING standards, not encoding ones. This is to allow
>commercial operators to create their own encoders, with the decoding being
>in the public domain.
Re
ucer
>
> BBC R&D North Lab,
> 1st Floor Office, OB Base,
> New Broadcasting House, Oxford Road,
> Manchester, M60 1SJ
> -Original Message-
> From: owner-backst...@lists.bbc.co.uk [mailto:
> owner-backst...@lists.bbc.co.uk] On Behalf Of Mo McRoberts
> Sent: 26 January 2010
On Mon, Jan 25, 2010 at 16:57, Ian Forrester wrote:
> Somewhat related to the discussion already going on?
>
> http://www.guardian.co.uk/technology/blog/2010/jan/25/firefox-open-video-support
>
> Idealists or pioneers?
>
> Interesting block at the bottom,
>
> "Web video has never really been open,
sage-
From: owner-backst...@lists.bbc.co.uk [mailto:owner-backst...@lists.bbc.co.uk]
On Behalf Of Mo McRoberts
Sent: 26 January 2010 12:55
To: backstage@lists.bbc.co.uk
Subject: Re: [backstage] Users just want video to work. You Mozilla people are
such idealists?
On Tue, Jan 26, 2010 at 12:48,
On Tue, Jan 26, 2010 at 12:48, Ian Forrester wrote:
> I've always been interested how x.264 and h.264 related to each other and
> co-exist. Is its simply a case like how Divx and Xvid work together or is
> there more ?
[the question wasn't directed at me, but...]
I'm not sure I follow? x264 i
Open source H.264 isn't pursued by MPEG-LA anyway. The issue of encoders is
fine, you just use x264 (which is the project I work on), which is the best
H.264 encoder in the world in the majority of use-cases.
-
You work on the x.264 project? Tell us more...
I've always been inter
On 25 Jan 2010, at 18:59, Barry Carlyon wrote:
> (have they finished the HTML 5 Spec yet?)
The definitive answer to this common question is here:
http://www.w3.org/html/wg/#sched
The short answer is "no". But that doesn't stop people from implementing bits
of it in browsers of course, despite
On 25-Jan-2010, at 18:59, Barry Carlyon wrote:
> Surely tho some clever person will write a plugin for Firefox to enable the
> H.264 codec, assuming they can get a version that will plugin/addon nicely
As far as I know, FF provides no plugin interface for and
codecs.
It’s been suggested
>
>
>
> In the meantime, though, Firefox is going to get left behind. Some
> sites will go to the trouble of transcoding to Theora, but mostly
> they'll just run with H.264 + Flash or QuickTime fallback (which works
> pretty well in my testing, if done carefully).
>
>
Surely tho some clever person
>
> > "Web video has never really been open, unencumbered
> and free. We've had Real Networks RM format, Apple's
> QuickTime, Microsoft's Windows Media Video (now standardised
> as VC-1), the DivX and XviD codecs, and Adobe Flash among
> others. There might never be one open standard, simply
> bec
On Mon, Jan 25, 2010 at 16:57, Ian Forrester wrote:
> "Web video has never really been open, unencumbered and free. We've had Real
> Networks RM format, Apple's QuickTime, Microsoft's Windows Media Video (now
> standardised as VC-1), the DivX and XviD codecs, and Adobe Flash among
> others. Th
Somewhat related to the discussion already going on?
http://www.guardian.co.uk/technology/blog/2010/jan/25/firefox-open-video-support
Idealists or pioneers?
Interesting block at the bottom,
"Web video has never really been open, unencumbered and free. We've had Real
Networks RM format, Apple's
32 matches
Mail list logo
