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



  • Media professionals, how do you validate broadcast-ready content?

    Videomenthe uses its distributor background of broadcast solutions and services, to design its own media workflow solutions dedicated to the audiovisual industry.
    The company keeps adding features to Eolementhe, its key platform dedicated to the workflows creation, processing, validation, sharing and delivery of media files. 
    The new one includes a ‘Media Library’ function and keeps the advantage of the extremely easy-to-use and friendly interface of Eolementhe, allowing every user to prepare and deliver video files.
    The Eolementhe’s ‘Media Library’ offers basic functions to prepare a video: selection of a thumbnail, the possibility to fill the editorial metadata and generate automatically the technical metadata with the option to download a report file; insert a trim with TC in/TC out to generate a video clip. 

    “Content is king”… Bill Gates said it in 1996, and this statement still echoes in so many sectors!
    Regarding the media industry, the growing number of files and formats to process is redefining our working methods, that’s a fact. Create and deliver high-quality media files is a brain-teaser for both, content providers and broadcasters. On top of that, the proliferation of technical mandatory specifications regarding files delivery, do not facilitate the fluidity of files processing operations. 
    Thus, validation processes are time-consuming, pricey and files exchange methods are often unsecured. Not simple to prepare media files… And, the key to success and we all know it, is to deliver a mass of high quality contents. So -in reference to a trendy word- the validation step has to be ‘agile’ with new tools streamlining the collaboration, making faster and smoother this crucial step prior to the video playout.
    So, wouldn’t it be great to have a common workflows solution allowing both content makers and distribution platforms to validate compliant media files easily?

    For instance, when having journalists in the field, files processing operations are difficult to integrate into a routine, because of time constraints, the equipment they have at their disposal etc. 
    So, one of the solution consists in ingesting the video on the ground, filling the elementary editorial metadata in order to resume the file processing later. With Eolementhe, our solution to process media files, and thanks to its pause option, back at the office, the journalists pick up where they left off.
    After connecting to Eolementhe, they click on the Media Library tab. This feature permits to stream the video, extract a screenshot, add comments per timecode, complete the editorial metadata, generate both technical and editorial reports and also create video clips. Once the editorial part is finished, the users set off its technical workflow, for example with transcoding, quality control, subtitling insertion and delivery. After only a few clicks, the video is prepared and ready to be distributed on several playout platforms.

    Another use case is the validation process between partners (internal and external): let’s take the example of a video delivery from production or post-production houses to TV channels. Before getting the broadcast-ready file, the video has to be editorially and technically approved. Consequently, several back and forth of files are performed before getting the video stamped ‘broadcast-ready’.

    Eolementhe makes this communication between internal and/or external partners easier and faster. Indeed, it enables both, the editorial validation with the media library feature ; and the technical validation of files with the workflow editor. Partners exchange their comments and files via Eolementhe to get the ‘broadcast-ready’ files. In addition, several standards are available via pre-filled metadata forms, allowing non-technical users as well, to create technical compliant files.

    Thanks to the single web-based interface of Eolementhe, reachable via a browser, the users, create compliant files including technical and editorial metadata, process, share, deliver and receive media files. So, Eolementhe reduces considerably the time to air by providing a platform focused on cost and time saving.
    So, media professionals, seek an easy-to-use solution to prepare and validate your media files? We guess you found it with Eolementhe… There is only one thing left to do, watch the demo!

  • 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!