Re: [backstage] BBC iPlayer and the Nokia N900
On Thu, Dec 31, 2009 at 20:50, Dave Crossland d...@lab6.com wrote: 2010/1/1 Tim Dobson li...@tdobson.net: it was suggested initially that GNU/Linux was pretty much irrelevant Only by ignorant assholes. :-) Making it a “GNU/Linux” issue misses the point, really: the OS itself is fairly irrelevant, and there’s no proprietary magic which can be incanted in order to make things suddenly wonderful on all Linux devices (in part by definition). The key is of course relying on open standards rather than FLV-in-RTMP for iPlayer. ’course, when the web-based iPlayer was launched, browser support for video / was practically nonexistant. Now… not so much. This, in a roundabout way, renders the old argument of “we don’t want to require everyone to have an H.264 decoder installed” somewhat moot, as video / makes it pretty easy to serve H.264 to those who support it and fall back to Flash for those who don’t. Of course, the _real_ issue is that serving content using standards which are now years old in formats which are widely-supported doesn’t account for DRM, despite its worthlessness: all of the other issues are pretty much red herrings compared to this. M. - 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 Thu, Dec 31, 2009 at 13:25, Kieran Kunhya kie...@kunhya.com wrote: 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. Right. The decoding is largely a non-issue. The issue is the compositing engine. Essentially: a) VLC, when _not_ using the GPU, doesn’t struggle remotely as much as Flash b) VLC also overlays text and graphics over video 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). Either way, of course, it’s still Adobe’s problem, and was Macromedia’s before that, and one either could have expended significant resources improving upon when it was decided to position Flash as a universal video playback platform. 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. M. - 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 iPlayer and the Nokia N900
Mo McRoberts wrote: On Thu, Dec 31, 2009 at 20:50, Dave Crossland d...@lab6.com wrote: 2010/1/1 Tim Dobson li...@tdobson.net: it was suggested initially that GNU/Linux was pretty much irrelevant Only by ignorant assholes. :-) Making it a “GNU/Linux” issue misses the point, really: the OS itself is fairly irrelevant, and there’s no proprietary magic which can be incanted in order to make things suddenly wonderful on all Linux devices (in part by definition). The key is of course relying on open standards rather than FLV-in-RTMP for iPlayer. ’course, when the web-based iPlayer was launched, browser support for video / was practically nonexistant. Now… not so much. This, in a roundabout way, renders the old argument of “we don’t want to require everyone to have an H.264 decoder installed” somewhat moot, as video / makes it pretty easy to serve H.264 to those who support it and fall back to Flash for those who don’t. Of course, the _real_ issue is that serving content using standards which are now years old in formats which are widely-supported doesn’t account for DRM, despite its worthlessness: all of the other issues are pretty much red herrings compared to this. Good points. Yes, I think you are right actually, I was sightly missing the point, you, however, have cleared it up quite nicely. :) The default Maemo browser is essentially Firefox 3.5+ which supports video / (not natively H.264 though, but that's a different debate). With regards to DRM, well, I think some people are generally coming round to the idea that it may not be the be all and end all. We'll have to see what happens, but it wouldn't surprise me if 2010 was the year video DRM got dropped as DRM for audio and in music has been in the last year or two... Time will tell, but hear is to hoping. :) Have a good new year everyone! Tim - 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 Fri, Jan 1, 2010 at 13:19, Kieran Kunhya kie...@kunhya.com wrote: 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. On which platforms? As I said, I’m not talking about Windows *at all* here. 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. …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) 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. 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. Again, not touched Windows at all here, but on the Mac at least video / can play back 1080p video with about ~20% of one CPU core being utilised without skipping frames and still allowing downscaling. Flash, in contrast, can’t play back 720p _except_ fullscreen (so no downscaling), consumes about 160% of a single CPU core in doing so, and barely manages the full framerate. Attempt to downscale, and 25fps video drops to about eight frames per second and CPU usage spikes. The scope for improving and optimising video / in successive browser releases is significant and promising; the scope for improving Flash’s video playback is nil, unless you’re Adobe: there are no competing implementations of any note. Flash’s video playback is a dead end, effectively. M. - 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 iPlayer and the Nokia N900
On Fri, Jan 1, 2010 at 13:19, Tim Dobson li...@tdobson.net wrote: We'll have to see what happens, but it wouldn't surprise me if 2010 was the year video DRM got dropped as DRM for audio and in music has been in the last year or two... I'm not that hopeful. I think the biggest driver behind the dropping of DRM for audio was that the music industry painted themselves into a corner with Apple+iTunes+FairPlay. The only way they could break the iTunes monopoly and regain some sense of control was to go DRM free. The same situation doesn't really exist for video. Maybe media executives will come to their senses and realize that DRM isn't worth the money they spend on it in 2010, but I doubt it - I'm fairly certain that what they're actually paying for is that feeling of being in control and not some technical method to stop piracy. Scot
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] BBC iPlayer and the Nokia N900
Tim Dobson wrote: The default Maemo browser is essentially Firefox 3.5+ which supports video / (not natively H.264 though, but that's a different debate). With regards to DRM, well, I think some people are generally coming round to the idea that it may not be the be all and end all. We'll have to see what happens, but it wouldn't surprise me if 2010 was the year video DRM got dropped as DRM for audio and in music has been in the last year or two... Heh, what's ironic is that the next Maemo device is likely to have a very solid and secure DRM capability :) http://wiki.maemo.org/MaemoSecurity David (A Maemo/Mer dev) -- Don't worry, you'll be fine; I saw it work in a cartoon once... - 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/
