|
Size: 6994
Comment: Tekst for studentoppgaver.
|
← Revision 20 as of 2015-11-29 21:27:04 ⇥
Size: 8179
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| This project is hoping to unite traditional TV-medium with the Internet. TV has always been sort of «analog» and one way communication. There is always an editor that will decide the content of the channel, and the viewers have rarely been able to participate, or contribute to the actual broadcasts. Today we have editing programs on a PC, and we can record, edit and publish right out of the box. Since all people can publish on the web, then why should they not be able to publish their content on the TV - medium? | |
| Line 3: | Line 4: |
| This project is hoping to unite traditional TV-medium with the internet. TV has always been sort of «analoge» , and one way comunication. There is always a editor that will decide the content of the channle, and the viewers have never beed able to participate, or contribute to the actual broadcasts. Today we have editing programs on a PC, and we can record, edit and publish right out of the box. Since all people can record edit and publish on the web, then why shuldnt they be able to publish their content on the TV - medium. |
Right now there are few solutions, and those that exists are proprietary and based on expensive hardware. |
| Line 12: | Line 6: |
| Rigth now there are few solutions, and those that exists are properiatory, and based on expencive hardware.... |
Why not make an open TV channel based on open and free software? |
| Line 15: | Line 8: |
| So how about a computer with a SDI card, and VLC.... | TV should not be controlled by few. It should be possible to make a broadcast system available to all. How about a computer with a SDI card, and an open media player controlled by the web? http://www.frikanalen.no/ |
| Line 18: | Line 15: |
| == Backend == This is where all the media is stored, it's a computer with multiple SAN devices over fibre channel. |
|
| Line 19: | Line 18: |
| == Backend == | When a person is uploading a video it can be uploaded directly to this server. |
| Line 21: | Line 20: |
| This is where all the media is stored, it's a computer with multiply SAN devices over fiber channel. |
The file server has a watchfolder for the transcoder. After transcoding, meta data will be updated in the scheduler showing that the media is available for broadcast. The transcoded file is stored in a broadcast safe format on the backend. The backend is the hub storing files for other systems. Transcoded files for web is also available on the backend. |
| Line 24: | Line 22: |
| When a person is uploading a video, it can be uploaded direct to this server. |
This system is already created, as well as its central database. |
| Line 27: | Line 24: |
| The File server then has a watchfolder to the transcoder solution for easy transcoding, and meta data veryfing to the sched uler. this is for easy file acsess to files from other systems. |
All the communication will be documented in the servers API. |
| Line 31: | Line 26: |
| This system is already created, as well as its sentral database. | == Scheduler == This is a system that generates a playlist from a web based user interface. This system has a stand alone database and is a "controller" for the open playout system. It has a web based interface for video registration, and a playlist configurator. A web based scheduler is already implemented in silverlight and can be used as a model for a new scheduler based on open standards. |
| Line 33: | Line 29: |
| All the comunication will be documented in the servers API. == Sceduler == This is a system that generaters a playlist, from a web based user interface This platform has a standalone database and is "controller" for the open playout system. It has a web based interface for video registration, and playlist configurator. === "system flow" === Acsess the web site, and registrer a video. Upload the video to backend from this site, and publish the content to the monthely scheduler for playout. you can then also access the video in various formats online for viewing purpeses, as a comunity channel |
=== "intended workflow" === Access the web site and register a video. Publish the content on the schedule (calender) for playout. On the registered video it should be possible to upload the videofile to a predefined folder on the backend. If this is done prior to the scheduled time of broadcast, the video will be aired. If the video is not uploaded in time, the user and the administrator should be warned by mail. |
| Line 50: | Line 33: |
| Transcoding solution needs to get "what ever format" from Backen and transcode it for broadcast and web (in open standard formats). On a communitysite you can then access the video for validating what you schedule or add comments to vidoes that has been uploaded by other users. Ideally the trascoder should be network based so you can connect new modules to accelerate transcoding. | |
| Line 51: | Line 35: |
| Transocding solution needs to get "what ever format" from Backend, for trasncoding to Broadcast, web and open standard formats. Hopefully it can also be network based, so you can connect new modules to accelerate transcoding === "flow" === The system gets a file in a folder, takes the file and transcodes, renames and moves it according to the scheduler database system. if a new computer on the network presents itself to the trascoder as a module, it will add it to the system for accelerated transcoding. |
=== "intended workflow" === The system gets a file in a folder, takes the file and transcodes, renames and moves it according to the schedulers database. if a new computer on the network presents itself to the transcoder as a module, it will add it to the system for accelerated transcoding. |
| Line 64: | Line 39: |
| The player is the final output of the system, totally controlled by the scheduling system that tells what to play when. The player should also be able to pass trough live rtsp/http streams on scheduled time slots. | |
| Line 65: | Line 41: |
| The player is the final output of the system, totaly controled by the schedluresystem, that tells what to play when. The player should aslo be able to pass trough live rtsp/http streams for Live broadcasting. === "player" === Gets playlist and time from Scheduler and copyes the files from backend for direct playout. If the sceduled item is a live source, the feed will be played as a normal item. |
=== "intended workflow" === Fetch the playlist from the schedulers database, copy the files needed for the day from backend and play the videos on the SDI output according to the schedule. If the scheduled item is a live source, the feed will be played as a normal item. |
| Line 76: | Line 45: |
| Frikanalen today have working implementations of all these modules, created by the company Never.no using Microsoft technology. | |
| Line 77: | Line 47: |
| Today we have all of theese modules working, the company Never.no created it, based on microsoft thecnology. |
The backend is a Windows 2003 server with SAN storage and a tape robot attached. The upload system is based on FileFlow, a third party application. The systems API is SOAP based and uses a MS SQL database to store meta-data. |
| Line 80: | Line 49: |
| The backend is a full windows 2003 server with a tape robot attached, it also has a uploading system on it called Fileflow. The systems API is based on SOAP witch connects to a Microsoft SQL database. |
The scheduler is implemented using Microsoft Silverlight. It presents the content of the video database and allows the user to schedule content two weeks in advance. |
| Line 84: | Line 51: |
| The Scheduler, and admin interface is based on Microsoft Silverlight thecnology. This is where you have the video database, that connects to the scheduler and you can add content to the scheduler , |
The transcoding system is split in two, one to generate DV-AVI files used for TV broadcasting, and one to generate Windows Media and Ogg Theora files for web publishing. The first uses Adobe Aftereffects, and the second uses Microsoft Expression Encoder 3. Both are quite slow single unit systems which do not handle parallell processing. |
| Line 88: | Line 53: |
| The transcoding system for broadcast is based on Adobe Aftereffects (including format conversion). We also use Microsoft Expression Encoder 3 for transcoding to web formats. Both are single unit system that is quite slow and not optimized for parallell processing. |
The playout system is based on a Harris video server with a CG-module attached (Character Generator). |
| Line 93: | Line 55: |
| The playout system is based on a Harris video playout with a CGI module attached. |
Since Frikanalen have a fully operational backend and frontend system, why should we need to replace them? This project is not aimed at replacing the system we have, but to add modules making this democratic tool available to all. With open standards on the web-based scheduling, more effecient transcoding and cheap implementations of playout we hope to spread the concept of public access TV. |
| Line 96: | Line 57: |
| Since we have a fully operational background services, then we dont need to change it, says some... We want all users of the big internett to be included into this «party» and that´s why we creating this project. |
The project will be creating 3 modules that can be attached to the existing system, talking to the backend system over the SOAP API, and be based on free and open standards. It will also replace the playout unit with a standard PC / MAC with a SDI graphics card. |
| Line 101: | Line 59: |
| The project will be creation of 3 modules that can be attached to this system, talking to this system over the SOAP API, and be a «none» Silverlight thecnology, it will also replace the playout unit with a standard PC / MAC with a SDI computer card. The system needs also to be standalone units, for integration with other systems, so use open formats, talk over open formats then all systems can comunicate, |
The modules need to be standalone units, not to waste time while other modules are in development. Free and open formats must be used and code must be well documented assuring all modules to work together in the final integration. |
| Line 111: | Line 62: |
| The playout module is our highest priority. The idea is to fetch information from the schedule and play out the videoes at the scheduled time. When there are «holes» in the shedule betweeen videos, «What's next» type of poster with an animated background should be shown. For larger gaps, a set of filler videos should be automatically scheduled. | |
| Line 112: | Line 64: |
| The playout module is our first priority. The idéa is to lissen on the commands from the scheduler, and play out the videoes at the correct time from the sceduler. When there are none videos to be played. We want «show info» to be shown on the channel, creating a «Whats next» type of poster, with a animated background. |
Qualifications: |
| Line 118: | Line 66: |
| Qualifications: | * basic knowledge of VLC, or a player with similar capabillites * XML parsing knowledge * general codec knowledge |
| Line 120: | Line 70: |
| * basic knowlage of VLC, or a player with similar capebilitys * reverse enginering existing scheduler system, for getting the playlist * Image magic * general codec knowlage its preffered with Some openGL / openCL skills is also good to know to comunucate with the Video play out card. |
It is an advantage to have some OpenGL / OpenCL skills to be able to get the SDI graphics card working. |
| Line 129: | Line 73: |
| This module is the main control which connects the Player with the videos and their scheduled time of broadcast. It should be designed with the ability to communicate with all planned playout modules, even the Harris Video server (and CG) being used today. | |
| Line 130: | Line 75: |
| This system is the main controll system, witch connects the Player with the videos, and the Database. it´s design need to be «standalone» with the posibility to talk to all systems, even the expensive Harris Video server. This system needs acsess to the all ready existing Backend system and Scedule system, it needs to be a «clone» of the existing system. but with the posibillytis to also work as a standalone system First off, today this is a «Slave» sceduler for the Silverlight scheduler, where you,get the information on what to play from. Then, aftter the scheduler can be a slave to the master scheduler, the project moves on to be a stand alone scheduler, with upload posibilytis, to backend, and controll of the transcoding system. |
The database should be able to register input from the Silverlight scheduler as well as this new scheduler based on open standards. In that way the playout will be functional as a apare (operational redundancy) as well as a parallell distribution with unique scheduled items. |
| Line 150: | Line 81: |
| * Basic video knowlage / VLC / Transcoding | * Basic video knowledge / VLC / Transcoding |
| Line 154: | Line 85: |
| To get «Whatever filetype» to known formats, as .dv for the playout system, Ogg Theora for the web system, and the posibilyty for other formats, as MP4, X264, MPEG 2... |
The transcoder should get «Whatever file type and codec» uploaded transcoded to several pre defined output formats. DV-AVI for the playout system, Ogg Theora for the web system, and the possibility for other formats, as MP4, X264, MPEG 2... |
| Line 158: | Line 87: |
| There are a lot of open encoders out there, you have te FFMPEG project, witch a lot is based on, you have Handbrake, and not to menton VLC. |
There are a lot of open encoders out there; you have the FFMPEG project and applications like Handbrake, VLC etc. |
| Line 162: | Line 89: |
| This project aims to get a working transcoder to talk to the Scheduler system, and the Backend system. |
This project aims to get a working open and network based transcoder to utilize the scheduler and the backend system. |
| Line 165: | Line 91: |
| When a user uploads the file, the Scheduler database system tells the transcoder, «now the file is ready» the transcoder takes the file and transcodes it to various formats as spessyfied in the sheduler system. |
When a user has uploaded the file the database will tell the transcoder that the file is ready for transcoding. The file will then be transcoded to various formats. The scheduler will recognize a clip as online when the DV-AVI is transcoded. When the Ogg Theora file is ready it will be avalable on web (if the clip is published). |
| Line 169: | Line 93: |
| If posible, the transcoder system shuld be able to swap feeld orders, normalise the sound volume, check 4*3 VS 16*9, also multiply computers rendering farm. |
The transcoder should also be able to swap field orders, normalise the sound volume, check 4*3 VS 16*9 and transform pixel aspect according to output settings. Ideally it should use multiple computers as a rendering farm. |
| Line 175: | Line 97: |
| * Codec knowlage * Transcoding knowlage * Video knowlage * Pearl , Mysql and PHP * Network and TCP/UDP knowlage |
* Codec knowledge * Transcoding knowledge * Video knowledge * Perl, MySQL/PostgreSQL and PHP * Network and TCP/UDP knowledge |
Welcome to this projects PDF file.
This project is hoping to unite traditional TV-medium with the Internet. TV has always been sort of «analog» and one way communication. There is always an editor that will decide the content of the channel, and the viewers have rarely been able to participate, or contribute to the actual broadcasts. Today we have editing programs on a PC, and we can record, edit and publish right out of the box. Since all people can publish on the web, then why should they not be able to publish their content on the TV - medium?
Right now there are few solutions, and those that exists are proprietary and based on expensive hardware.
Why not make an open TV channel based on open and free software?
TV should not be controlled by few. It should be possible to make a broadcast system available to all.
How about a computer with a SDI card, and an open media player controlled by the web?
Module based
Backend
This is where all the media is stored, it's a computer with multiple SAN devices over fibre channel.
When a person is uploading a video it can be uploaded directly to this server.
The file server has a watchfolder for the transcoder. After transcoding, meta data will be updated in the scheduler showing that the media is available for broadcast. The transcoded file is stored in a broadcast safe format on the backend. The backend is the hub storing files for other systems. Transcoded files for web is also available on the backend.
This system is already created, as well as its central database.
All the communication will be documented in the servers API.
Scheduler
This is a system that generates a playlist from a web based user interface. This system has a stand alone database and is a "controller" for the open playout system. It has a web based interface for video registration, and a playlist configurator. A web based scheduler is already implemented in silverlight and can be used as a model for a new scheduler based on open standards.
"intended workflow"
Access the web site and register a video. Publish the content on the schedule (calender) for playout. On the registered video it should be possible to upload the videofile to a predefined folder on the backend. If this is done prior to the scheduled time of broadcast, the video will be aired. If the video is not uploaded in time, the user and the administrator should be warned by mail.
Transcoder
Transcoding solution needs to get "what ever format" from Backen and transcode it for broadcast and web (in open standard formats). On a communitysite you can then access the video for validating what you schedule or add comments to vidoes that has been uploaded by other users. Ideally the trascoder should be network based so you can connect new modules to accelerate transcoding.
"intended workflow"
The system gets a file in a folder, takes the file and transcodes, renames and moves it according to the schedulers database. if a new computer on the network presents itself to the transcoder as a module, it will add it to the system for accelerated transcoding.
Player
The player is the final output of the system, totally controlled by the scheduling system that tells what to play when. The player should also be able to pass trough live rtsp/http streams on scheduled time slots.
"intended workflow"
Fetch the playlist from the schedulers database, copy the files needed for the day from backend and play the videos on the SDI output according to the schedule. If the scheduled item is a live source, the feed will be played as a normal item.
Page 4
Frikanalen today have working implementations of all these modules, created by the company Never.no using Microsoft technology.
The backend is a Windows 2003 server with SAN storage and a tape robot attached. The upload system is based on FileFlow, a third party application. The systems API is SOAP based and uses a MS SQL database to store meta-data.
The scheduler is implemented using Microsoft Silverlight. It presents the content of the video database and allows the user to schedule content two weeks in advance.
The transcoding system is split in two, one to generate DV-AVI files used for TV broadcasting, and one to generate Windows Media and Ogg Theora files for web publishing. The first uses Adobe Aftereffects, and the second uses Microsoft Expression Encoder 3. Both are quite slow single unit systems which do not handle parallell processing.
The playout system is based on a Harris video server with a CG-module attached (Character Generator).
Since Frikanalen have a fully operational backend and frontend system, why should we need to replace them? This project is not aimed at replacing the system we have, but to add modules making this democratic tool available to all. With open standards on the web-based scheduling, more effecient transcoding and cheap implementations of playout we hope to spread the concept of public access TV.
The project will be creating 3 modules that can be attached to the existing system, talking to the backend system over the SOAP API, and be based on free and open standards. It will also replace the playout unit with a standard PC / MAC with a SDI graphics card.
The modules need to be standalone units, not to waste time while other modules are in development. Free and open formats must be used and code must be well documented assuring all modules to work together in the final integration.
Project one - playout
The playout module is our highest priority. The idea is to fetch information from the schedule and play out the videoes at the scheduled time. When there are «holes» in the shedule betweeen videos, «What's next» type of poster with an animated background should be shown. For larger gaps, a set of filler videos should be automatically scheduled.
Qualifications:
- basic knowledge of VLC, or a player with similar capabillites
- XML parsing knowledge
- general codec knowledge
It is an advantage to have some OpenGL / OpenCL skills to be able to get the SDI graphics card working.
Project two - scheduler
This module is the main control which connects the Player with the videos and their scheduled time of broadcast. It should be designed with the ability to communicate with all planned playout modules, even the Harris Video server (and CG) being used today.
The database should be able to register input from the Silverlight scheduler as well as this new scheduler based on open standards. In that way the playout will be functional as a apare (operational redundancy) as well as a parallell distribution with unique scheduled items.
Qualifications:
- Ajax and general web programing, XML, PHP
- Mysql programing, as a main database
- Basic video knowledge / VLC / Transcoding
Project three - transcoder
The transcoder should get «Whatever file type and codec» uploaded transcoded to several pre defined output formats. DV-AVI for the playout system, Ogg Theora for the web system, and the possibility for other formats, as MP4, X264, MPEG 2...
There are a lot of open encoders out there; you have the FFMPEG project and applications like Handbrake, VLC etc.
This project aims to get a working open and network based transcoder to utilize the scheduler and the backend system.
When a user has uploaded the file the database will tell the transcoder that the file is ready for transcoding. The file will then be transcoded to various formats. The scheduler will recognize a clip as online when the DV-AVI is transcoded. When the Ogg Theora file is ready it will be avalable on web (if the clip is published).
The transcoder should also be able to swap field orders, normalise the sound volume, check 4*3 VS 16*9 and transform pixel aspect according to output settings. Ideally it should use multiple computers as a rendering farm.
Qualifications:
- Codec knowledge
- Transcoding knowledge
- Video knowledge
- Perl, MySQL/PostgreSQL and PHP
- Network and TCP/UDP knowledge