Differences between revisions 2 and 12 (spanning 10 versions)
Revision 2 as of 2009-11-12 20:30:40
Size: 6994
Comment: Tekst for studentoppgaver.
Revision 12 as of 2009-11-13 11:11:53
Size: 7462
Comment: Rewrite page 4.
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?
Line 18: Line 13:
== Backend ==
This is where all the media is stored, it's a computer with multiple SAN devices over fibre channel.
Line 19: Line 16:
== Backend == When a person is uploading a video it can be uploaded directly to this server.
Line 21: Line 18:
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 20:
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 22:
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 24:
This system is already created, as well as its sentral database.

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.
== Scheduler ==
This is a system that generates a play list, from a web based user interface This platform has a stand alone database and is "controller" for the open playout system. It has a web based interface for video registration, and play list configurator.
Line 43: Line 28:

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
Access the web site, and register a video. Upload the video to backend from this site, and publish the content to the monthly scheduler for playout. you can then also access the video in various formats online for viewing purposes, as a community channel
Line 50: Line 31:

Transocding solution needs to get "what ever format" from Backend, for
trasn
coding to Broadcast, web and open standard formats.  Hopefully it
can also be network based, so you can connect new modules to
accelerate transcoding
Transcoding solution needs to get "what ever format" from Backend, for transcoding to Broadcast, web and open standard formats. Hopefully it can also be network based, so you can connect new modules to accelerate transcoding
Line 57: Line 34:

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.
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 transcoder as a module, it will add it to the system for accelerated transcoding.
Line 64: Line 37:

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.
The player is the final output of the system, totally controlled by the scheduler system, that tells what to play when. The player should also be able to pass trough live rtsp/http streams for Live broadcasting.
Line 70: Line 40:

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.
Gets play list and time from Scheduler and copies the files from backend for direct playout. If the scheduled item is a live source, the feed will be played as a normal item.
Line 77: Line 44:
Today we have all of theese modules working, the company Never.no
created
it, based on microsoft thecnology.
Frikanalen today have working implementations of all these modules, created by the company Never.no using Microsoft technolocy.
Line 80: Line 46:
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 backend is a Windows 2003 server with SAN storage and a tape robot attached. The upload system is based on FileFlow, and the system API is SOAP based and uses a MS SQL database to store meta-data.
Line 84: Line 48:
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 scheduler and the administration interface is implemented using Microsoft Silverlight and talk to the SOAP API in the backend. It presents the content of the video database and allow one to schedule content up to two weeks in advance.
Line 88: Line 50:
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 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 parallel processing.
Line 93: Line 52:
The playout system is based on a Harris video playout with a CGI
module attached.
The playout system is based on a Harris video playout with a CGI module attached. 
Line 96: Line 54:
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.
Since we have a fully operational backend services, some say we do not need to replace them... We want all users of the big Internet to be included into this «party» and that´s why we creating this project.
Line 101: Line 56:
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 thecnolog
y, it will also replace the playout unit with a
standard PC / MAC with a SDI computer card.
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 106: Line 58:
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 subsystem need to be stand alone units, for integration with the other parts. Because of this free and open formats must be used, to make sure all subsystems can work together.
Line 111: Line 61:

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 sc
eduler. 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.
The playout module is our first priority. The idéa is to listen on the commands from the scheduler, and play out the videoes at the correct time from the scheduler. 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.
Line 120: Line 65:
 * basic knowlage of VLC, or a player with similar capebilitys
 * reverse enginering existing scheduler system, for getting the playlist
 * basic knowledge of VLC, or a player with similar capabillites
 * reverse engineering existing scheduler system, for getting the play list
Line 123: Line 68:
 * general codec knowlage

its preffered with Some openGL / openCL skills is also good to know to
comunucate with the Video play out card.
 * general codec knowledge
its preferred with some OpenGL / OpenCL skills is also good to know to communicate with the Video play out card.
Line 129: Line 72:
This system is the main control system, which connects the Player with the videos, and the Database. it´s design need to be «stand alone» with the possibility to talk to all systems, even the expensive Harris Video server.
Line 130: Line 74:
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 access to the all ready existing Backend system and Schedule system, it needs to be a «clone» of the existing system. but with the possibilities to also work as a stand alone system
Line 135: Line 76:
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» scheduler for the Silverlight scheduler, where you,get the information on what to play from.
Line 139: Line 78:
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.
Then, after the scheduler can be a slave to the master scheduler, the project moves on to be a stand alone scheduler, with upload possibilities, to backend, and control of the transcoding system.
Line 150: Line 84:
 * Basic video knowlage / VLC / Transcoding  * Basic video knowledge / VLC / Transcoding
= Project three - transcoder =
To get «Whatever file type» to known formats, as .dv for the playout system, Ogg Theora for the web system, and the possibility for other formats, as MP4, X264, MPEG 2...
Line 152: Line 88:
= Project three - transcoder = There are a lot of open encoders out there, you have the FFMPEG project, which a lot is based on, you have Handbrake, and not to mention VLC.
Line 154: Line 90:
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...
This project aims to get a working transcoder to talk to the Scheduler system, and the Backend system.
Line 158: Line 92:
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.
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 specified in the scheduler system.
Line 162: Line 94:
This project aims to get a working transcoder to talk to the Scheduler
system, and the Backend system.

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.

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.
If possible, the transcoder system should be able to swap field orders, normalise the sound volume, check 4*3 VS 16*9, also multiply computers rendering farm.
Line 175: Line 98:
 * 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 play list, from a web based user interface This platform has a stand alone database and is "controller" for the open playout system. It has a web based interface for video registration, and play list configurator.

"system flow"

Access the web site, and register a video. Upload the video to backend from this site, and publish the content to the monthly scheduler for playout. you can then also access the video in various formats online for viewing purposes, as a community channel

Transcoder

Transcoding solution needs to get "what ever format" from Backend, for transcoding 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 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 scheduler system, that tells what to play when. The player should also be able to pass trough live rtsp/http streams for Live broadcasting.

"player"

Gets play list and time from Scheduler and copies the files from backend for direct playout. 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 technolocy.

The backend is a Windows 2003 server with SAN storage and a tape robot attached. The upload system is based on FileFlow, and the system API is SOAP based and uses a MS SQL database to store meta-data.

The scheduler and the administration interface is implemented using Microsoft Silverlight and talk to the SOAP API in the backend. It presents the content of the video database and allow one to schedule content up to 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 parallel processing.

The playout system is based on a Harris video playout with a CGI module attached.

Since we have a fully operational backend services, some say we do not need to replace them... We want all users of the big Internet 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.

The subsystem need to be stand alone units, for integration with the other parts. Because of this free and open formats must be used, to make sure all subsystems can work together.

Project one - playout

The playout module is our first priority. The idéa is to listen on the commands from the scheduler, and play out the videoes at the correct time from the scheduler. 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:

  • basic knowledge of VLC, or a player with similar capabillites
  • reverse engineering existing scheduler system, for getting the play list
  • Image magic
  • general codec knowledge

its preferred with some OpenGL / OpenCL skills is also good to know to communicate with the Video play out card.

Project two - scheduler

This system is the main control system, which connects the Player with the videos, and the Database. it´s design need to be «stand alone» with the possibility to talk to all systems, even the expensive Harris Video server.

This system needs access to the all ready existing Backend system and Schedule system, it needs to be a «clone» of the existing system. but with the possibilities to also work as a stand alone system

First off, today this is a «Slave» scheduler for the Silverlight scheduler, where you,get the information on what to play from.

Then, after the scheduler can be a slave to the master scheduler, the project moves on to be a stand alone scheduler, with upload possibilities, to backend, and control of the transcoding system.

Qualifications:

  • Ajax and general web programing, XML, PHP
  • Mysql programing, as a main database
  • Basic video knowledge / VLC / Transcoding

Project three - transcoder

To get «Whatever file type» to known formats, as .dv 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, which a lot is based on, you have Handbrake, and not to mention VLC.

This project aims to get a working transcoder to talk to the Scheduler system, and the Backend system.

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 specified in the scheduler system.

If possible, the transcoder system should be able to swap field orders, normalise the sound volume, check 4*3 VS 16*9, also multiply computers rendering farm.

Qualifications:

  • Codec knowledge
  • Transcoding knowledge
  • Video knowledge
  • Perl, MySQL/PostgreSQL and PHP
  • Network and TCP/UDP knowledge

grupper/video/frikanalen/studentoppgaver (last edited 2015-11-29 21:27:04 by localhost)