Re: [backstage] Ping...
I ended up stealing Mo's ideas about open source broadcast*, having read about them on this list, and am now working to get a similar concept** production ready and deployed at well known names in the US and Europe.. * https://github.com/nexgenta/txsuite/blob/master/README.mdown** https://github.com/kierank/broadcastencoder/wiki --- On Fri, 3/6/11, Mo McRoberts m...@nevali.net wrote: On 3 Jun 2011, at 16:21, Ant Miller wrote: Meanwhile, some of us have jumped over to the dark side…
Re: [backstage] Streaming video on variable bandwidth connection?
Can I pick your brains please. :) I'm trying to work out what technology to use; Situation: Mobile Linux computer connected via 3G/GPRS to internet. The computer is likely to encounter fluctuating connectivity where it connectivity drops between low GPRS signal, full HDPSA signal and completely offline. Objective: I'm trying to find a technology to stream [live] video from a V4L2 device to 'the internet' over the able connection. The connection only needs to be one way. Caveat: Ideally I need to work out something that makes a 'best effort' judgement based on the amount/quality of bandwidth available and and streams the best picture it can. Eg. Where loads of bandwidth is available, there is a nice picture and where there isn't, there isn't a nice picture, but there isn't nothing. Does anything like this exist? Ideally something I can pull the video out in something resembling a sane format would be cool. Bonus points if it's easily scriptable... See http://x264dev.multimedia.cx/archives/286 You could even make the application talk to the 3G driver (possibly by reading /proc/whatever now and then, so that it can adapt based on the signal strength/type). If there's packet loss you can also use periodic intra refresh mode which will give you some error resiliency. I'd recommend also using UDP because 3G latency is pretty rubbish. There's a slice-max-size option which means you could put a single H.264 slice inside a UDP packet, though your decoder will have to support doing this. (And if you really wanted to go the full shebang you could have a main receiver communicate with the transmit server to invalidate reference frames which the decoder didn't receive...) - 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] Enabling NVIDIA GPU acceleration on iPlayer videos...
I think the iPlayer app in MythTV or Boxee should let you watch using hardware acceleration. --- On Mon, 10/1/11, Christopher Woods chris...@infinitus.co.uk wrote: From: Christopher Woods chris...@infinitus.co.uk Subject: RE: [backstage] Enabling NVIDIA GPU acceleration on iPlayer videos... To: backstage@lists.bbc.co.uk Date: Monday, 10 January, 2011, 13:24 It's proably the h264 decoder of the flash player, it's quite buggy and a bit of a cpu hog, Good news is adobe are making it better all the time, so a lot of the early buggyiness is gone, it's just the cpu concerns that are about, Indeed, 10.2 is much better and regular 1080p plays at 30fps thanks to the NVidia ION GPU acceleration. (I've also tried both the 10.1 beta and the final release as bundled in Chrome). Unfortunately the iPlayer web player doesn't seem to be presenting the H.264 video in a manner in which the ION GPU acceleration can be enabled to accelerate the video decoding, which seems to be the problem here. (given YouTube works perfectly playing 1080p with GPU acceleration and the iPlayer's 720p overwhelms the machine on CPU-only decoding). - 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] Enabling NVIDIA GPU acceleration on iPlayer videos...
There's always get_iplayer.py. You can pipe the output straight into mplayer. --- On Mon, 10/1/11, Christopher Woods chris...@infinitus.co.uk wrote: From: Christopher Woods chris...@infinitus.co.uk Subject: RE: [backstage] Enabling NVIDIA GPU acceleration on iPlayer videos... To: backstage@lists.bbc.co.uk Date: Monday, 10 January, 2011, 14:24 I think the iPlayer app in MythTV or Boxee should let you watch using hardware acceleration. Well, Boxee doesn't want to fully hardware accelerate. The colourspace is squashed, which indicates it's *trying* to use hardware acceleration (the colourspace is being squashed into 16-235, which is a problem on all NVidia cards to do with hardware YUY - RGB conversion, and has been for years) but the CPU usage is still topping out and playback is occasionally jumpy. (Also, it doesn't even have BBC HD in the iPlayer app) Time to go try and compile MythTV... - 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] API into iPlayer content
Wii isn't too difficult to figure out, though it's more complicated. I have actually had a little look at Wii iplayer myself to see how H.264 decoding is done on such a feeble device. There are lots of layers of encrypted data but people have figured out how to decrypt them. I think the ipad is a plain http stream - nothing fancy in that regard. --- On Fri, 1/10/10, Paul Jakma p...@jakma.org wrote: From: Paul Jakma p...@jakma.org Subject: Re: [backstage] API into iPlayer content To: backstage@lists.bbc.co.uk Date: Friday, 1 October, 2010, 12:07 On Fri, 1 Oct 2010, David Dorward wrote: You mean iPhone here I guess: iPad - has low quality video which has been being yanked for ages. I suspect this has gone under the heading of acceptable loss iPad - I'm yet to see someone pulling the video data from the iPlayer web app they use here. Is there a way lurking around somewhere? iPad has been rooted. Also Apple use the same signing cert for all iOS devices, and the client cert appears reasonably generic for iOS - so regardless of official support, an iPhone may well have the same level of access as iPad. PS3 - flash, same as the main iPlayer Meh, the video is still accessible - doesn't matter whether it was an RTMPE or HTTPS stream that delivers the bits.. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: People who fight fire with fire usually end up with ashes. -- Abigail Van Buren - 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] BBC Archiver
On 18-Jul-2010, at 12:05, Brian Butterworth wrote: Personally, whilst there are a few design decisions I might personally have done differently, I think the change is clearly one for the better. this. M. Henry Ford: If I had asked my customers what they wanted, they would have said a faster horse. - 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] BBC Trust approves Project Canvas ...
Does anyone else see this as the BBC effectively bailing out other broadcasters by providing a common platform backed with licence fee funded content and development? No, this is what I'd expect the BBC to do. It serves the public when market-based squabbles over alternative technological platforms don't happen, and everyone just gets on with innovating atop a good-enough platform, rather than frittering away consumers' time and money by playing platform argy-bargy. That's a very interesting point - I've never really thought of Canvas as a form of market failure correction. - 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] BBC Trust approves Project Canvas ...
Does anyone else see this as the BBC effectively bailing out other broadcasters by providing a common platform backed with licence fee funded content and development? It's unlikely such a wide group of companies would ever reach a consensus otherwise without the BBC. Anything similar would probably take many more years to develop because of all the wrangling or even be homebrew or developed by an outsider (e.g. Boxee). The DRM and payment model is standardised and presumably reasonably secure which reduces the duplicate work required by other broadcasters and makes the user-experience better (one payment gateway, one box etc.). - 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] Freeview HD Content Management
a) broadcast in other countries without this scheme or an equivalent b) distributed widely prior to it hitting the UK And on BBC HD on satellite to the UK and large parts of Europe. The horse-and-cart makers still can't stand the existence of the car... Won't be long until the DRM is (symbolically) broken anyway. - 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] Does the BBC ever respond to web site feedback?
I reported this a few weeks ago, on a different story. It never got fixed, and the problem keeps happening. Forward your complaint to the Daily Mail ;) - 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] Re: [backstage] Re: [backstage] Re: get_iplay er 2.77 release (was Re: [backstage] get_ipla yer dropped in response to BBC’s lack of su pport for open source)
What actually needs to happen is that Open Source needs to call the BBCs bluff by actually implementing the SWF verification stuff and producing an application with a compelling user experience that matches or is better than anything else on offer. --- On Thu, 27/5/10, Richard P Edwards re...@mac.com wrote: From: Richard P Edwards re...@mac.com Subject: Re: [backstage] Re: [backstage] Re: get_iplayer 2.77 release (was Re: [backstage] get_iplayer dropped in response to BBC’s lack of support for open source) To: backstage@lists.bbc.co.uk Date: Thursday, 27 May, 2010, 16:07 I thought this was an interesting summary http://www.freesoftwaremagazine.com/columns/bbc_drm_and_demise_get_iplayer_what_hell_going I read some quite thought provoking stories of what the Publishers are up to . so once PACT and other old fashioned societies get involved, then the unintended consequences could be quite tragic. Rich On 27 May 2010, at 09:47, Brian Butterworth wrote: I think the people from PACT got it all banned. After all, they have their own interests to look after, you can't blame them. It's not as if the money is from the public or anything. On 26 May 2010 23:28, Alex Cockell a...@acockell.eclipse.co.uk wrote: Hi folks, Considering it's now being handled here - do we have anyone with any clout as to getting get_iplayer supported officially? Just thinking that there is precedent for a download/streaming engine separate to playback client - just look toward the EBU... :) Watching with interest... Alex -- Alex Cockell Reading, Berks, UK a...@acockell.eclipse.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/ -- Brian Butterworth follow me on twitter: http://twitter.com/briantist web: http://www.ukfree.tv - independent digital television and switchover advice, since 2002
Re: Looking for hotshot video develeopers to work at the BBC (was RE: [backstage] Fancy joining BBC RD?)
I’ve been slowly rewriting the build logic to be
auto{conf,make}+libtool-driven (I’m targeting an expanded
set of platforms — OpenSolaris, Mac OS X and Linux — so
autoconf helps an awful lot).
There was shock amongst other x264 developers (myself not included since I
don't know enough about the merits of buildsystems to comment!) and ffmpeg
developers as to why you created an autoconf fork of x264 and ffmpeg.
-
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] BBC World Cup video
I see that the new World Cup site is up: http://news.bbc.co.uk/sport1/hi/football/world_cup_2010/video/ Is the new 6mbit 1024x576 VP6 video (why VP6 not H.264?) on the first page going to be the standard for World Cup video? - 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] BBC News online stream quality drop?
And now the H.264/AAC workflow is in place... How about bumping the audio up to AAC+? AAC at 128kbps should be transparent provided the encoder is up to scratch. Making it AAC+ would probably keep the audio the same quality or perhaps reduce it slightly in my opinion because the algorithms it uses have to guess the higher frequencies. AAC+ is really designed for lower bitrates. - 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] Free films in 1080p?
We're going to be committing Blu-Ray compatible encoding in x264 soon, which will be the first open-source Blu-Ray compatible encoder, and we plan to release a free downloadable Blu-Ray image to coincide with this. We really don't want to release something like Big Buck Bunny or Elephants Dream for the umpteenth time so we're looking for something else (length doesn't matter much) The conditions are: Must be free Must look good in 1080p Must have a high-quality master available to us Are there any good suggestions for what we could use? The only two which are contenders so far are Bergensbanen from NRK, a 7.5 hour train journey (!), or Fairytale from the SVT HD test set (though we haven't yet been able to track down anyone who has a full copy) (For the H.264 nerds out there, another developer added multiple slice support a few months ago and I wrote a large part of NAL-HRD which were the missing pieces we didn't have that Blu-Ray requires) - 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] RE: BBC Flash video and deinterlacing - is this really the best we can get?
From: Brian Butterworth briant...@freeview.tv Subject: Re: [backstage] RE: BBC Flash video and deinterlacing - is this really the best we can get? To: backstage@lists.bbc.co.uk Date: Sunday, 7 March, 2010, 19:15 It occurred to me the other day that one solution to the problem might be to delinterlace the scrolling credits used at the end of programmes on the originals. It might even make them easier to read. But then they'll scroll in a jerky fashion. - 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] RE: BBC Flash video and deinterlacing - is this really the best we can get?
Clearly you need a motion-compensated deinterlacer. ;-) It's still not going to be as good in 25p as it will in 50i in my opinion unless the scroll speed is reduced. Though judging by recent attempts to destroy end credits on virtually every channel I doubt slower speeds will be tolerated... Presumably soon there won't be any end credits but instead viewers will be directed to /programmes . - 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] RE: BBC Flash video and deinterlacing - is this really the best we can get?
Don't TV Catchup have both a low- and high- quality streams, where the HQ ones are interlaced? Not aware of multiple streams - only ever watch at the highest possible quality :) However, it certainly doesn't look like it's been encoded as interlaced (which would make absolutely NO sense whatsoever). Flash doesn't have a deinterlacer afaik so that's not possible. - 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] A quick Dolby E question
--- On Sun, 28/2/10, Christopher Woods chris...@infinitus.co.uk wrote: From: Christopher Woods chris...@infinitus.co.uk Subject: RE: [backstage] A quick Dolby E question To: backstage@lists.bbc.co.uk Date: Sunday, 28 February, 2010, 18:05 SurCode's stuff can produce 24-bit Dolby-E iirc. Also AJA cards can work with Dolby-E but you have to do it right to preserve the metadata. Telestream's FlipFactory (a bit like also allows decoding and encoding of Dolby-E if you configure your 'factory' correctly, PDF at [1]. Wikipedia:Dolby_E also mentions that SoundCode from Neyrinck supports the format. [2] From that document Flipfactory only seems to support 16/20 bit modes. I've tried both SoundCode and Surcode and they are only 16/20 bit as well. - 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] A quick Dolby E question
A teeny bit off-topic but I'm sure there are people on the list that know the answer. Does 24-bit Dolby E actually exist? If so what produces it? Thanks in advance. - 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] BBC Flash video and deinterlacing - is this really the best we can get?
--- On Tue, 9/2/10, Anthony McKale anthony.mck...@bbc.co.uk wrote: From: Anthony McKale anthony.mck...@bbc.co.uk Subject: Re: [backstage] BBC Flash video and deinterlacing - is this really the best we can get? To: backstage@lists.bbc.co.uk Date: Tuesday, 9 February, 2010, 10:48 You'll find youtube has the same problem http://www.youtube.com/watch?v=oHg5SJYRHA0 Ant On 09/02/2010 00:51, Christopher Woods chris...@infinitus.co.uk wrote: I've noticed that for some reason blend deinterlacing is still being used on all BBC Video footage (iPlayer, inline footage on News/Sports sites, etc). It looks naff, causes image doubling in areas of high movement and makes scrolling credits harder to read. (Also don't think it looks as good and halves the perceived framerate) As reference, the doubling is very noticeable on a recent episode of Hustle in the 'action areas': http://i46.tinypic.com/14jxctd.png (a deck of cards is being fountained upwards, falling down onto the camera - note the overlapping ghosts of the moving cards). I first wondered if this was a limitation of how Flash renders interlaced-encoded video, but I happened to be watching a particular sporting event via an unofficial Justin.tv stream and the motion was fluid and crisp. From that I can only assume all BBC videos are encoded as progressive, and as such the Blend deinterlacing is burnt in, with the same going for Live streams... If the content is being deinterlaced from a broadcast source, why not use Bob or Weave? Blend just looks awful, motorsports/action looks dire and even regular stuff looks pants. In the case of Youtube you don't know whether the user already uploaded it with blended fields. Youtube's ingest/encode chain is based on mencoder (a very old one at that) and if I remember rightly they use one of the deinterlacers built in to mencoder. Bob wouldn't be particularly useful because doubling the framerate, whilst making the image more fluid, would require higher system requirements. Weave would be worse than blending because it would leave combing artefacts everywhere. Flash doesn't have any deinterlacer built-in. There are plenty of free pixel-adaptive deinterlacers out there though such as Yadif or a decomb filter could be used. There are even some painfully slow motion compensated ones that would be probably be in the same league as expensive snell and wilcox equipment. - 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] BBC Flash video and deinterlacing - is this really the best we can get?
--- On Tue, 9/2/10, Stephen Jolly st...@jollys.org wrote: From: Stephen Jolly st...@jollys.org Subject: Re: [backstage] BBC Flash video and deinterlacing - is this really the best we can get? To: backstage@lists.bbc.co.uk Date: Tuesday, 9 February, 2010, 15:55 On 9 Feb 2010, at 11:42, Kieran Kunhya wrote: There are plenty of free pixel-adaptive deinterlacers out there though such as Yadif or a decomb filter could be used. There are even some painfully slow motion compensated ones that would be probably be in the same league as expensive snell and wilcox equipment. If you could provide details of motion-compensated software deinterlacers that are comparable in quality to the S+W ones, that would be really interesting and useful. TIA, S The two that are the best are TempGaussMC_beta1mod and MCBob2 both with nnedi2 as the interpolation mode. Expect speeds of 0.1fps or so... A few years back someone did a comparison with s+w hardware (can't find the link unfortunately); the hardware won but not by a large margin. However, the software deinterlacers aren't developed much any more. (probably because a lot of material is progressive these days) - 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] Users just want video to work. You Mozilla people are such idealists?
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 you can use all the MPEG4 forward references, the ones you don't get when you real time encode. Real-time encoding with Bi-predictive frames (B-frames) in H.264 doesn't work like that. There's a frame delay in order for B-frame encoding to take place. Most encoders worth their while also have a lookahead for deciding frame-types and bit rate allocation. (Sometimes this is called 2-pass realtime, which is a bit of a misnomer for marketing reasons. Some marketing people for manufacturers seem to spread this myth that more passes is always better). Using x264 with a recent CPU, if you ran it at realtime even at 720...@3mbit you'd most likely do better than the £50k+ broadcast encoder at 1080i merely because we're generations ahead of most (if not all) of the H.264 hardware and software out there. Naturally, with 2-pass you can allocate bits more efficiently but the benefits aren't as significant as they once were. - 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] Users just want video to work. You Mozilla people are such idealists?
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 problems exist for H.264 decoding. Only Windows 7 has native H.264 (which isn't actually compliant in a few places last time I checked). XP/Vista don't however. 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. - 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] Users just want video to work. You Mozilla people are such idealists?
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 don’t know whether this is down to me not being able to spot the difference from 10 inches away from the screen, whether it’s that x264 is a better encoder than whatever Red Bee uses, or whether it’s simply the case that High Profile is used because Flash can decode it more efficiently[1] than if it were Baseline. Also, noting that at 720p25, 3Mbps ought to be enough! x264 is almost certainly better than whatever Red Bee use though I think the keyframe interval in iPlayer is lower than the x264 defaults. (and the ffmpeg presets aren't very good) In theory High and Baseline should have approximately the same decode complexity since the High Profile features should reduce bitrate. The overhead of High Profile should then be cancelled out by this lower bitrate. iPlayer does disable CABAC which is an easy way of reducing Flash performance. 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...) - 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] Users just want video to work. You Mozilla people are such idealists?
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 because some content owners will want to include DRM (Digital Rights Management) copy restrictions. DRM isn't the issue for proprietary formats in my opinion since that's generally a container-level issue as opposed to a codec level issue. (MKV had support for DRM and there are various incarnations for .mp4. You could also say Flash RTMP is an (albeit large) extension of .flv) Because of the way video codec standardisation works and flaws in the software patent system all video codecs have features which are patented. In spite of what Xiph/Mozilla might say Theora almost certainly has patented features; nobody has done an exhaustive search because of the cost in time and money. However, the web would benefit from having an open, unencumbered and free video format that enabled HTML programmers to include a video as easily as they now include a headline or a photo, wouldn't it? How do we get to that? Reform of the patent system. open, unencumbered, free etc. is just Xiph/Mozilla propaganda. Not the way Mozilla is going about it, that's for sure - they're trying to solve all of the problems at once, but without any support from the people who _need_ to support this stuff in order for it to be effective. Without the likes of Microsoft and Apple getting behind Theora and giving it a clean bill of health, patent-wise (and in Apple's case, making use of silicon which decodes it), it's going to go nowhere fast and people will abandon Firefox for Chrome if they want video. A clean bill of health is near-impossible because *trivial things* are patented in video compression. The silicon is already out there for H.264 in millions of devices so reinventing the wheel is silly. Perhaps Xiph/Mozilla stood a chance in 2003 but this is far too late. The way I suspect this will, eventually, play out is that under pressure from stakeholders, software *decoders* for H.264 will become exempted from the patent regime by the MPEG-LA. This still leaves the thorny issue of encoders and the sites streaming the content, but that's far less of an issue for the end-user, and another battle for another day. 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. Dirac, as lovely as it is, doesn't have the traction, and doesn't (in its current form) seem to be too well-suited to the vast range of applications that H.264 is used for. Wavelet video compression still isn't ready for prime-time so to speak. 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). Now that Flash 10.1 has hardware acceleration anyone requiring content security will still use Flash. Quicktime is the only decoder which manages to be worse than Flash in terms of features and performance. - 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] Freeview HD Content Management
I like the way Ofcom have totally missed the point about Linux/Open Source presuming it refers to STBs running Linux. - 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] Freeview HD Content Management
Well, it would, and that's the easiest way to make the point about it. The fact it'll affect people running MythTV et al themselves *as well* is less of a concern for them (or the BBC). What I mean is most (all?) the complaints before were from people wanting to watch on a Linux PC. (Irrelevant anyway because they are only blocking DVB-SI not the MPEG-2 PSI* which will still give you channels; they just won't be named and will have no EPG but both pieces of information can be downloaded from the internet anyways.) *unless they've conveniently decided to (incorrectly) group MPEG-2 PSI with DVB-SI. The reality is, STB manufacturers don't really have the luxury of being able to: a) ignore the licensing terms of the open source DVB stacks; b) reverse-engineer the decoding tables; c) obtain the tables from the BBC but breach the non-disclosure terms; or d) release a box which doesn't support FVHD GPL issues are pretty minor; a legal way of including the licenced codes could be fudged into the system. It can be done in the same way people have Linux mobile phones with a closed GSM stack. Low cost Chinese knockoff STBs won't care about the Freeview logo and will just get the codes from whoever reverse engineers them. On the other hand, while (technically-minded) consumers wouldn't be permitted to do any of those things easier, nobody would come knocking on the door if they reverse-engineered the Huffman tables themselves and used them solely in order to make linux-dvb on their PC work. The minor snag is that this is a completely unrealistic scenario, because people who have successfully decoded them will want to (a) give others the tables or (b) give others a utility for decoding the tables, and people who can't figure it out will plead to be sent copies of it, and everyone will fall afoul of the EUCD's anti-circumvention provisions. IANAL but there are also reverse engineering exemptions for interoperability purposes. (made stronger by the non-commercial use) The silly thing is this isn't going to deter anyone. Cheap boxes with reverse engineered codes will soon roll off the factory line in China. Again DRM is just affecting ordinary people wanting to record things for personal use. Nobody is going to replace all their devices at home with HDCP compatible ones. This is like Adobe's RTMP DRM which is just gives content providers a nice walled garden feeling in spite of the RTMP passkey being the phrase Adobe Flash. - 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] Freeview HD Content Management
Well, it would, and that's the easiest way to make the point about it. The fact it'll affect people running MythTV et al themselves *as well* is less of a concern for them (or the BBC). What I mean is most (all?) the complaints before were from people wanting to watch on a Linux PC. Er, no they weren’t. I was referring to the complaints which prompted the discussion about linux/open source in the consultation document. - 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] What is TV?
a) VLC, when _not_ using the GPU, doesn’t struggle remotely as much as Flash b) VLC also overlays text and graphics over video Again using the GPU for compositing. c) YV12-RGB _can_ be tightly optimised if you’re crazy enough to do things that way around The key there is that the YV12-RGB conversion that Flash does is slow, rather than it necessarily being software (i.e., it could be relatively efficient and still software). Thanks to overlays and other transforms the YV12-RGBA conversion has to be done that way can still be quite slow considering other browser threads have priority. It's not an easy problem to solve at high-resolutions while keeping the plugin size as low as possible. Also like VLC's upcoming DXVA implementation I think the Flash version is a hack by not actually using a proper renderer but pulling the processed frames beforehand. (I'm no Directshow expert so I can't explain how it's done there) However, if there is an ASIC on the PC designed to decode H.264 it might as well be used. Hopefully this will lead to more use of non-filmic framerates online. Such overuse of filmic framerates online and on TV and probably on IPTV will inevitably devalue the effect in my opinion. Frankly, the sooner the codec mess behind video / gets sorted out and Flash can be avoided in the few remaining contexts that it’s used, the better. video / doesn't have a proper method for specifying the buffering time. This means it can't formally support any of the modern video buffering features (such as HRD in H.264). Also the ogg container format doesn't have any index making the official method through javascript a non-starter. As far as I know most (all?) HTML5 video implementations suffer from similar/worse performance than flash thanks to browser compositing engines requiring RGB input. - 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] What is TV?
On which platforms? As I said, I’m not talking about Windows *at all* here. It uses an appropriate renderer for the platform, which by default would be GPU accelerated. (I don't feel like looking up the names for each one right now though...) …yes. It does it backwards. Given a focus on rendering video (and overlaying limited-movement sprites atop video) it makes far more sense to convert everything to match the video and composite that way, rather than converting frames of rapidly-changing video to RGB for output (usually via some device with a path optimised for non-RGB video rendering) The reason this happens is because different video cards vary vastly in the way they treat YV12 (especially considering flash's wide range of machines/dirvers that it runs on). It's very difficult to get a consistent result without going through an established API so RGB is used instead. video / doesn't have a proper method for specifying the buffering time. This means it can't formally support any of the modern video buffering features (such as HRD in H.264). Also the ogg container format doesn't have any index making the official method through javascript a non-starter. It’s early days, but it’s already significantly more promising than Flash has been for quite some time now. Forgot to say this makes streaming that doesn't stop-start near-impossible. - 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] What is TV?
--- On Wed, 30/12/09, Brian Butterworth briant...@freeview.tv wrote: Why the Flash iPlayer client can't use the hardware acceleration. I get lots of dropped frames watching through the iPlayer Desktop. The new Flash 10.1 beta uses DXVA (DirectX Hardware Video Acceleration). However it has problems with scaling right now. The main reason they didn't do this earlier is because of paranoia about buggy video drivers causing crashes and potential security issues. This is windows-only right now (presumably because Apple won't give Adobe access to the necessary APIs). When DXVA goes into the main player, iPlayer should be able to improve their HD encoding parameters (e.g. turning CABAC on, more reference frames etc.) However I doubt this will happen because the streams might well end up looking better than the broadcast albeit only at 25p. - 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] What is TV?
This is windows-only right now (presumably because Apple won't give Adobe access to the necessary APIs). Er, what? Where did that presumption come from? Nothing else on the Mac or Linux has a problem with video compositing. VLC, which does it entirely in software too, has _no_ issues. Quartz, QuickTime, and OpenGL, which can be hardware-accelerated, are thoroughly documented. GPU vendor agnostic H.264 bitstream decoding on Macs is only possible with Quicktime - there is no public API for H.264 bitstreaming as far as I know. Such a thing is not possible with Linux. (There are only separate vendor APIs on Linux such as VDPAU) Compositing is done on the GPU in VLC (as part of whatever renderer VLC uses - VMR9 on windows if I recall correctly) whereas in Flash it's a slow software based YV12-RGB conversion in order for overlaying text/graphics amongst other things. Also various issues with running inside a browser window slow it down. - 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] iPlayer on Freesat in November.
No obvious statement that it can play the upcoming Freeview HD content but I presume that this is the plan. I'm not sure where they're going to get DVB-T2 chipsets from... - 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] FYI: Open iPlayer
What is so important about the content/metadata ingest and delivery system that is the iPlayer that it needs to be licenced as opposed to being developed in-house at a broadcaster? --- On Tue, 20/10/09, David Tomlinson d.tomlin...@tiscali.co.uk wrote: From: David Tomlinson d.tomlin...@tiscali.co.uk Subject: [backstage] FYI: Open iPlayer To: backstage@lists.bbc.co.uk Date: Tuesday, 20 October, 2009, 6:59 PM http://www.theregister.co.uk/2009/10/20/bbc_trust_rejects_iplayer_federation/ The BBC Trust has shelved a plan that would have allowed broadcasters such as Channel 4, ITV and Five to share the Beeb's iPlayer. The so-called Open iPlayer project was meant to establish a new commercial service separate from BBC Worldwide, that would licence the Corporation's hugely popular video-on-demand technology to third parties. We concluded that the open iPlayer plans in their proposed form, combining both commercial and public service elements, were too complicated, said BBC Trustee Diane Coyle in a statement today. http://www.bbc.co.uk/bbctrust/news/press_releases/october/open_iplayer.shtml The Trust is open to considering an alternative proposal for the licensing of the iPlayer technology to third parties if that can be done on a simple, fair and commercial basis, said Coyle. - 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] The BBC is encrypting its HD signal by the back door
http://www.guardian.co.uk/technology/2009/sep/29/bbc-hd-encryption Ok I know we talked about it before but here he (cory) is again, but this time in the Guardian. Cheers, Secret[] Private[] Public[x] Ian Forrester Senior Backstage Producer, BBC RD 01612444063 | 07711913293 ian.forres...@bbc.co.uk (here's hoping this works) While I don't support this obfuscation of SI information, a lot of the arguments in that article aren't particularly good or don't make sense. Also because one can't have a reasoned discussion in any newspaper comment section these days, I will make my point here. Break existing equipment, such as HD laptop cards that have open drivers. Because of DVB-T2, no such devices are on the market yet. Generate a mountain of e-waste, because manufacturers won't be able to produce set-top boxes that downsample the HD signal and feed it through a digital output to existing SD tuners and recorders. No idea what he's talking about here. If an STB could decode the H.264, why would downscaling be a primary function of the device? What digital output is he talking about? Freeze out British entrepreneurs, such as the manufacturers of the Promise TV, who produce video recorders that run on open source software. If anything the open source community will be the first to find a workaround. There are a lot of programs out there to read damaged transport streams - ITV HD on Freesat was slightly obfuscated as an h.222 stream but people made it work. BBC HD used MBAFF in H.264 and someone wrote a patch. The same will happen or people will just continue to use satellite. Kieran. - 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/
