+33 (0)4 67 17 41 56 contact@videomenthe.fr French version

Focus

Focus



  • Disruption? Certainly not! Continuity and flexibility are what we’re all about!

    Videomenthe's CEO, Muriel Le Bellac gives her point of view about "disruption"

    We live in a world in constant flux, and that’s a fact. Technological progress in the fields of both IT and telecommunications is changing traditional working practices significantly.

    Our world of professional broadcasting must meet the challenge of digitalisation of content and it is up to us to reassess methods of working in order to take advantage of these technological developments.

    Should we be alarmed by this? Because it means switching over from tape to file, from video converter to transcoder, from oscilloscope to probe software, from terrestrial broadcasting to internet streaming, from linear consumption of content to catch-up or on-demand, and also from TV screen to laptop, tablet or mobile phone screen, and so on.
    The content itself, however, must always go through the same stages of capture, editing and compliance prior to transmission live, by catch-up or on-demand.

    * So why talk about disruption?
    Is it not just a fantastic process of evolution that gives us the kind of freedom of audiovisual content consumption that was unimaginable just 20 years or so ago? After all, VOD has only been around since the beginning of the new millennium…
    Setting out from this starting point, as time has gone by it has been necessary to replace first the dedicated hardware platforms processing analogue sources, then digital baseband sources, with servers employing software solutions that handle live internet streaming and media files.
    Then came the tremendous resources provided by the arrival of the Cloud and high-speed internet…
    This made our developers very happy, but caused anxiety for our technical teams, fearing that they would be stripped of their own local infrastructure.
    One of the approaches is to view the Cloud, in the first instance, as simply an extension of the on-site facilities, making it possible to handle work overflow and peaks in activity, without over-expanding local infrastructures, which would then be operating well below capacity for most of the year.

    * And what about continuity?
    The idea then came about of using a dedicated portal for our work, employing the same tools as those used internally: the Cloud now starts to display signs of continuity and flexibility.

    Similarly, if we extend this reasoning to its logical conclusion and use this same workflow creation portal to run our own calculation farms in-house, from the point of view of users, only the interface and the resources as a whole matter. They are not concerned about the share of the load between their infrastructure and the one made available to them in the Cloud. Continuity and flexibility are our motto and form the foundations of Eolementhe©

    We are living in an exciting time which is allowing us to push back the limits in terms of processing and making our content available via multiple devices. We should take advantage of it to exploit every solution, every tried-and-tested revolutionary method, in a progressive and flexible way, to gain the greatest benefit from it.

    The On-Premises/Cloud hybrid approach without a doubt forms the basis for the new broadcasting practices of the future.
    The world of the media file allows us to employ far greater technical resources than ever before and to catch a glimpse of future links between our “On-Prem” ecosystem and the Cloud which could become quite seamless.

    “Adapt or Die”, the motto governing my work at the beginning of my professional career, which focussed on the transition from SD to HD video in the ‘90s, is once again highly applicable today: the telecom and Cloud networks offer us the prospect of mass broadcasting via multiple platforms and represent an incredible toolkit for developing our creativity and designing new packages in our field, which has so much to offer the media.

    So, let’s stop talking about disruptiveness and forge our way towards flexible interaction and wealth of content!


  • Episode 2! Project Management 3.0

    Next article! You haven't read the previous episode? It is the next one!

    Managing a project with GitHub
    The GitHub interface is easy to use and provides all of the tools required to manage a project. From management of resources, to sprint planning, to code management, there is no need for any additional tools.

    Team management made simple
    It’s very easy to create teams, add developers and assign them to one or more projects.
    Issues, for doing everything
    An issue is like a ticket, and may cover functionality, bugs, improvements, questions etc.

    GitHub issues
    • An issue may have tags such as: feature, bug, improvement, design, question, etc.
    • An issue may be assigned to one or several members of the team.
    • An issue has a description and everyone can discuss it, add comments, ask questions and so on.

    Milestones for each sprint
    GitHub milestones
    Stages can be created called milestones, which represent the sprints. Each sprint has a start and end date and contains a list of issues to be dealt with. The percentage of work completed is updated automatically as the issues are closed.

    A Kanban board, for an overview
    Kanban board
    This can be used to help organise the sprint, to check rapidly on the tasks that are in progress, those that have been completed, and to see who is working on what.

    Readme and Wiki, to document everything
    The readme of a project sets out all of the important information before starting. It allows you to know where to start and gives quite a precise idea of the overall operation. The wiki allows you to go a bit further into the details.

    Graphics, for easy analysis
    These enable you to have an overview of the work on each project, including, amongst other things:
    • Contributions, by developer
    • Code frequency, by day/week/month.
    • Table of commits, by branch

    Pull requests, to keep code separate
    Using pull requests, developers each work on their own version of the code and there is no risk of breaking the master branch which contains the production code. So, after thoroughly testing their code, the developers send a request to the person managing the master branch to add their modifications. The code is now analysed automatically, then manually, before being added or rejected.

    Searching the project
    The search field allows a term to be searched throughout the project. It can be filtered by issues, tags, commits, code, wiki etc.
    Using just the one tool for all of the aspects of a project is a real advantage. GitHub offers a limited number of functions, but includes the essentials, and everything works perfectly.
    ________________________________________
    Conclusion? As simple as:
    • Use GitHub to manage your projects.
    • Use Scrum sprints!

  • Project management 3.0 by Rémi!

    ________________________________________

    1. The traditional method
    This involves analysing the requirements, defining a product on the basis of a comprehensive set of specifications, formulating the product, developing it and testing it. A project may thus take several months to several years. The project manager has to set the key milestones for each stage. The study and analysis stages remain completely theoretical until the developers encounter problems that no one could have foreseen. The time taken up by the development stage of a project is therefore particularly unpredictable and often exceeds the duration and/or budget originally allowed for it.
    ________________________________________

    2. Agile methods

    These methods began to be developed in the United States, in 2001, with the dawning realisation of the increasing number of project development failures. So, a team of experts met and drew up a strategy setting out the approach that should be adopted to adapt the most readily to change and thus to respond best to clients’ expectations.
    The principle on which these methods are based is to divide the project up into several iterations, which cover the functions that come together to make up the final product. There are several advantages to working on a number of mini projects rather than one large project:
    • Developers no longer feel as if they are not making progress
    • The clients are regularly involved in the test stage of each function and give their input as required.
    • A “virtuous circle” is established.

    The Scrum approach
    Scrum is the most popular of the Agile methods. It involves defining all of the functions of the application in a backlog. The development team meets every 2 or 4 weeks to establish the functions it will implement during the coming 2 or 4 weeks. The cycle is repeated until the backlog tasks have been completed. These iterations are known as “sprints”. Once a sprint has been completed, there is a debrief and then the work begins again on a new set of functions.
    I find this method worthwhile, if you cut out all of the meetings it involves. Here is a list of all the occasions when the team has to meet for discussion:

    • Sprint planning: This is when the priorities are established for the upcoming sprint (allow half a day per sprint)

    • Daily scrum: This involves a meeting lasting several minutes every morning so that everyone involved can talk about what they did the day before, any difficulties they experienced and what they are going to do today. In theory, it shouldn’t last more than 15 minutes, but all it takes is for one person in the team to have a habit of talking for a bit too long and your morning is already almost over.

    • Backlog refinement: This involves estimating the time each task will take. This duration calculation is estimated in terms of points. So, in addition to being completely arbitrary and incomprehensible (1 point = how many hours?), the time spent on calculations in relation to functionality would often have been long enough to cover actually developing it (allow half a day per sprint).

    • Sprint review: This is the time set aside for reviewing the sprint that has just been completed. The conclusion: it is often concluded that the number of tasks scheduled was excessive and plans are made for the following sprint to be perfect! (The following sprint in fact goes as poorly as the previous one, and half a day per sprint must furthermore be set aside).

    All of these meetings are very time consuming. On average, a team of 4 developers loses “10 man-days” in meetings, every two weeks.
    The expression “agile” has become meaningless. In theory, the team ought to be able to adapt immediately to change. Unfortunately, I have attended meetings at which the project manager could not add a small task to the current sprint because this went “against Scrum methodology”.
    To conclude, the rapid sprints and iterations proposed by the Scrum method represent genuine progress in the management of projects. On the other hand, the excessive number of meetings and the lack of adaptability diminish the benefits of this method.

    In the next episode, I will talk about GitHub!

  • Baton 7: Cutting-edge tools

    New formats (He-AACv2, TTML subtitles, ProRes 4K content, etc…)

    Error detection enhancement (burned test and subtitles, PSE correction, etc.)

    More dedicated checks (SMPTE 2084 EOTF, lightness level (MaxFALL and MaxCLL), and ITU-R BT. 2020, ITU-R BS.1770-3)

    Improved usability : User interface enhancement

    Organizational QC policy to support a combination of automated and manual QC checks

    Multiple language detection

    BATON Media Player improvement


  • Xpress: features enhancements

    All Bitrates in Single File check box option added to the Xpress Transcoder MBTS

    A new option for creating Fixed sized GOP has been added to the Xpress Transcoder MBTS

    Timestamp Offset option added to the Xpress Transcoder MBTS

    MaxBitrate and avgBitrate descriptor boxes added to MP4 files with AAC audio

    AudioChannelConfiguration element added to DASH MPD adaptation set

    Accessibility element added to DASH MPD adaptation set