The OBE blog
FOSDEM is the largest Open Source conference in Europe (and in the world?) where over 5000+ people attend to hear more about Open Source. This year in association with the EBU and FOMS, we are organising an "Open media devroom" allowing people to present and discuss various Open Source projects relating to multimedia, and for our part of the session, relating especially to broadcast.
There's a lot going on and we urge you to talk about anything related using the information below:
Dear open source in broadcasting community,
We have submitted an application to get a developer room for presentations dedicated to media at FOSDEM 2015 in Brussels (https://fosdem.org/2015/ ).
It has been accepted for the first day on Saturday 31th January as "Open media devroom" and we co-organise it with the FOMS community.
So now the call for participation is opened.
If you are interested to present, please register your submission directly on this link: https://penta.fosdem.org/
You need to create an account and then go to "create event" to give the details of your presentation.
IT IS VERY IMPORTANT TO SELECT THE "OPEN MEDIA DEVROOM" TRACK IN YOUR SUBMISSION. Otherwise, we won't see it and it will appear in other tracks that we don't control.
The deadline for submission is: 1st December 2014.
Presentation are recorded and will be made available with CC-BY licence by FOSDEM.
The timeslot for presentation is 20 minutes and it is foreseen to have panel discussions also (40 minutes).
We will then have to select submission together with FOMS community and final schedule is expected to be published by 30th December.
The OBE C-100 platform is the first broadcast encoder/decoder to support Opus audio. But why are we doing this? This post explains some of the background behind implementing Opus for Broadcast Contribution.
Disclaimer: This analysis is merely an objective analysis of the coding features the encoder uses and not an analysis of the subjective or objective picture quality of the encoder. It’s also worth saying that this information is from a small clip but in the main short clips can provide a good indication of the coding decisions an encoder is making.
Early stage encoders like the one used in the BBC World Cup UHD trial are interesting in that they provide an insight into the development process of a encoder and what coding tools encoder manufacturers have decided to use first (often with limited processing power). This information usually remains under NDA but public use of the encoder means anyone can perform analysis on it.
A very good introduction to HEVC coding tools can be found here: http://forum.doom9.org/showthread.php?t=167081
Thanks to the help provided by Parabola Research in producing this post. You can download a bitstream analysis report from Parabola Explorer Pro 3.0 below. This report helped produce the analysis below.
In no particular order:
All in all, not really a surprise. At this early stage it's no real surprise that people like Netflix are saying “We're not seeing efficiency gains being claimed by HEVC encoding vendors"1 and such a limited use of the toolkit is the main reason why
The report from Parabola Explorer Pro can be found here: http://downloads.obe.tv/Parabola-Explorer-Pro-analysis-of-Rio-Stream.pdf
As announced the BBC have launched a UHD1 channel using HEVC on the COM8 multiplex. This uses standard DVB-T2 modulation parameters and can be captured using an off the shelf USB capture stick. FFmpeg supports HEVC decoding and by extension most other Open Source multimedia software. So the output of ffprobe looks like this:
Input #0, mpegts, from 'BBCUHD1.ts': Duration: 00:00:45.35, start: 404.054433, bitrate: 35862 kb/s Program 61440 Metadata: service_name : Test service_provider: Stream #0:0[0x65]: Video: hevc (Main) ( / 0x0024), yuv420p(tv), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x66](eng): Audio: aac_latm ( / 0x0011), 48000 Hz, stereo, fltp Program 61504 Metadata: service_name : Test. service_provider: Stream #0:0[0x65]: Video: hevc (Main) ( / 0x0024), yuv420p(tv), 3840x2160 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x66](eng): Audio: aac_latm ( / 0x0011), 48000 Hz, stereo, fltp
As expected Main Profile HEVC at 59.94 fps is used. Let's try decoding it (Sandy Bridge Xeon 4-cores 3.4GHz):
./ffmpeg -benchmark -i BBCUHD1.ts -f rawvideo -y /dev/null
frame= 187 fps= 45 q=0.0 size= 2272050kB time=00:00:03.11 bitrate=5966002.6kbit
45fps is not bad but significantly below 59.94fps to watch the match in realtime. On the OpenHEVC decoder that will eventually have parts merged in FFmpeg on a 2x 6 core Xeon, it's possible to decode at around 127fps. This is because it has intrinsics for more functions (notably the transforms) than mainline FFmpeg. However, FFmpeg does not accept intrinsics for maintenance and performance reasons. Plans are afoot to get this viewable in realtime before the first match is on. More technical information will be posted in due course.
At the moment the feed is showing a recording of some trees and the back of the W12 Media Village: http://www.obe.tv/images/UHD.png
Read part two which has an analysis of the HEVC encoding technology here: http://obe.tv/about-us/obe-blog/item/13-a-look-at-the-hevc-encoder-bbc-uhd-world-cup-part-2