There are some questions that really affect which direction you should go. Where is the content coming from? Is it all locally produced? Is it produced live-to-tape, or is there a lot of postproduction?
You may be interested in A $300 video server tivo-based hack, which is kinda cool.
Anyway - For in and out, you could consider ASI-based transport. An advantage of using DVB-ASI out from your server is that you can easily transition to digital transmission when the time comes. The physical characteristics are similar to SDI, ie a 270mbs signal, but you're dealing with MPEG2 transport streams. You could have multiple program streams if you want. The idea here is that you can use external encoder/decoder boxes that go between audio/video (analog or SDI) and ASI (compressed domain). All you need to do is splice the files at I-frames and stream them out to the device. Hardware's pretty cheap - have had good experience with the cards from DVEO/Computer Modules. Cheap and stable, and they come with linux drivers. You'll need to write some code to make it all work, though. And external encoders/decoders aren't the cheapest thing, but they should be cheaper than most video servers
There are also ASI/MPEG stream splicers to look at - from companies like Leitch/Harris, Thales, and EVS. But you've noted they're a bit expensive.
SDI-based playout is going to be rather expensive no matter how you go. Offloading this work to an external decoder is pretty cost effective. You can also use IP as a transport instead of ASI, to an external decoder, but ASI is a bit simpler and more reliable.
In college, I wrote an automated air playout system on a mac - had a mysql db for asset management and scheduling. This was synced every so often to the website db. Had a pretty simple set of perl scripts (which included calling applescript from the command line via osascript) that handled playing to air. (used quicktime player, actually, with great success). Created blocks of clips using SMIL, which you should check out. Was able to key bugs/logos/time/temp info, too.
Between scheduled programs we cut to an Apple Keynote presentation, started and stopped by the same scripts [using applescript]. The actual presentation was auto-generated during the programming by another perl script, from another database. (Including events from a central campus events database, updated weather forecast, program schedule db for coming up next/later, advertisements/PSAs [another db with this info], and video interstitials)...
Now that was a fun project. But quite a mess at the same time.
Actually, the ESPN phone has worked much better for me than MLB.tv. It's a very different product. As a closed system, they control all aspects of the video playback (DRM, if any, is minor). Video was consistently high quality, played smoothly, and the content was good - highlights, news updates, and the like.
The MLB.tv crap was just that. ESPN Mobile, I'll probably miss it a little - it was nice to get the news updates and scores. And the regular web access was particularly nice. I'm not a huge sports fan, and to be honest, I'd love an ABC news or CNN version of this phone. But the truth is there's not enough market for any of these. The media companies should be developing apps for phones on the main cell networks. But these networks must open up their ecosystem a bit and make it easy for their customers to add applications to their phones. Pay for data, sure. But to disable transfer of files from the phone using bluetooth, requiring expensive air charges? (Yes, Verizon, I'm looking at you), that's crazy.
I use it occasionally to often. It's nice - quality is quite decent. They really need to get the word out better, and get better carriage, not enough cable systems offer it, I believe. Nice with the gameplan stuff, too. It's convenient, but the truth is, I like my HDTV better:)
Good cable management products are a good first step. I like Panduit's.
Label each side of any cable with a "wire run number" and document these religiously. If you have someone else doing the work for you, check out ranges of wire numbers to them.
We use numbers with a two-letter series and then 4 digits.
For your initial install, put AA0001 at position 1, and work upwards. While obviously, this won't be the case for everything, for larger bundles, its easier to deal with.
Finally, label the patch points clearly. ADC makes great designations strips with plastic windows.
I'm a fan of InterMapper, powerful but not overly complicated, and easily extensible. It also runs on MacOSX, Windows, Linux, Solaris, and FreeBSD. It was originally developed at Dartmouth College to support their network, and has been marketed commercially since 1996.
Incompatibility with iPod: sure, it makes little sense to give compatibility to the 37 people who bought a Toshiba Gigabeat, and the 45 additional who got an Archos player, and not to the 50 million iPod users out there. BUT I think it doesn't really matter, I think the "watch-long-videos-on-the-go-on-a-tiny-screen" market is small anyway. People who really want to watch video on trains and planes have laptops or portable DVD players.
Well, the video iPod has video-out, so you can watch it on your TV, at least. It appears the Gigabeat doesn't offer this, but at least the Archos does. This would at least partially (if you had an Archos) make up for the "unable-to-burn-to-DVD" problem, as it's still relatively simple to watch this content on your TV.
The devices in the list below have been tested with the Unbox Video Player. If your device is Plays for Sure compliant it may work, but we cannot guarantee performance on untested devices.
One likely incentive for that migration will be reduced storage costs
Yeah, but storage costs for office documents are so low in the grand scheme of things anyways. Storage is cheap. (Especially for us - we deal with extremely large quantities of HD video each day - our perspective may be affected by this)
Judging from past conversions, you'd better keep the original version close at hand, because when the conversion doesn't look right, you're going to have people wanting the original. So now you're dealing with 25% more storage - the original files as a safety copy, and the new 'improved' conversions. Hmmm.
The advantage I see in the article is basically that this is lighter than a regular antenna. While that's useful, is that it? Rapid deployment would still require an airship; wouldn't it make sense to outfit the airship with the appropriate antenna already (as an optional package)?
All true. Wish I could mod you up, but clearly I've posted. Doh. Thanks for the info.
Anyways, while there is indeed no 1080p60 content now (well, none distributed), I think HDTV production may settle at some point in the next few years. So if tv show release were available on DVD in 1080p60, it could be useful.
But mostly, was just curious. Was surprised to not see this specified anywhere.
Actually - it appears they do the same thing Google's researchers talk about already:
What happens if no audio code is present in the sample home?
Nielsen's patented Nielsen Media Monitor Sites (MMS) collect and store a constant stream of
unique audio signatures for each broadcast, cable, and satellite signal received, covering all 210
TV markets. This includes all client PBS stations and client cable origination channels.
If any station's NAVE encoder is inadvertently interrupted, the A/P Meter installed in Nielsen
sample homes uses the same patented technology to collect and store passive signatures for all
non-encoded programming viewed. These signatures are downloaded each night to Nielsen's
operations center. To identify viewing, the passive signatures collected from the A/P meter in the
home are matched against the signatures collected by the MMS. This process occurs during the
normal overnight data collection.
The passive signature-matching engine in the A/P Meter system is intended as a fail-safe back-up
system, to be used when codes are not present in the signal.
In order to perform its function, the audio-database
server must have access to a database of broadcast
audio data. However, the actual audio stream does
not need to be stored. Instead, only the compressed
representation (32-bit descriptor) is stored. This
allows as much as a year of broadcast fingerprints
to be stored in less than 1 GB of memory.
It sounds like they are effectively building a database to compare the recordings to. (even if these are not the actual material but hashes based on it)
I have a philips 32" conventional CRT HDTV that I love. Not quite "Large-Format" - but direct view CRT is the best image by far out of all the technologies I've seen.
According to people in the know from both Canon and Toshiba during NAB2006, these are not coming any time soon. 2008 at the earliest is what they said. (That said, the demo of this tech earlier this year was simply amazing.
Unless you're doing this a lot, you probably can find a facility that will have the appropriate scan converters. The easiest way is probably going to be DVI->HD-SDI->Capture Card. There are lots of places that have this (expensive) equipment. You're going to need very fast disks - uncompressed HD is huge.
*Nowhere* does the MPEG LA guarantee that if you license from them that you will get _all_ patents related to the standard. In fact, you can be sure there are big disclaimers in their contracts that it's not necessarily true. The MPEG LA can't avoid more than anyone else the risk of submarine patents.
AT&T pulled a similar one a while ago with the MPEG4 video standard.
How true. And these issues are having a serious chilling effect in the Broadcast equipment world.
Slashdot Mirror
Year N+1 bug?
There are some questions that really affect which direction you should go. Where is the content coming from? Is it all locally produced? Is it produced live-to-tape, or is there a lot of postproduction?
You may be interested in A $300 video server tivo-based hack, which is kinda cool.
Anyway - For in and out, you could consider ASI-based transport. An advantage of using DVB-ASI out from your server is that you can easily transition to digital transmission when the time comes. The physical characteristics are similar to SDI, ie a 270mbs signal, but you're dealing with MPEG2 transport streams. You could have multiple program streams if you want. The idea here is that you can use external encoder/decoder boxes that go between audio/video (analog or SDI) and ASI (compressed domain). All you need to do is splice the files at I-frames and stream them out to the device. Hardware's pretty cheap - have had good experience with the cards from DVEO/Computer Modules. Cheap and stable, and they come with linux drivers. You'll need to write some code to make it all work, though. And external encoders/decoders aren't the cheapest thing, but they should be cheaper than most video servers
There are also ASI/MPEG stream splicers to look at - from companies like Leitch/Harris, Thales, and EVS. But you've noted they're a bit expensive.
SDI-based playout is going to be rather expensive no matter how you go. Offloading this work to an external decoder is pretty cost effective. You can also use IP as a transport instead of ASI, to an external decoder, but ASI is a bit simpler and more reliable.
In college, I wrote an automated air playout system on a mac - had a mysql db for asset management and scheduling. This was synced every so often to the website db. Had a pretty simple set of perl scripts (which included calling applescript from the command line via osascript) that handled playing to air. (used quicktime player, actually, with great success). Created blocks of clips using SMIL, which you should check out. Was able to key bugs/logos/time/temp info, too.
Between scheduled programs we cut to an Apple Keynote presentation, started and stopped by the same scripts [using applescript]. The actual presentation was auto-generated during the programming by another perl script, from another database. (Including events from a central campus events database, updated weather forecast, program schedule db for coming up next/later, advertisements/PSAs [another db with this info], and video interstitials)...
Now that was a fun project. But quite a mess at the same time.
Actually, the ESPN phone has worked much better for me than MLB.tv. It's a very different product. As a closed system, they control all aspects of the video playback (DRM, if any, is minor). Video was consistently high quality, played smoothly, and the content was good - highlights, news updates, and the like.
The MLB.tv crap was just that. ESPN Mobile, I'll probably miss it a little - it was nice to get the news updates and scores. And the regular web access was particularly nice. I'm not a huge sports fan, and to be honest, I'd love an ABC news or CNN version of this phone. But the truth is there's not enough market for any of these. The media companies should be developing apps for phones on the main cell networks. But these networks must open up their ecosystem a bit and make it easy for their customers to add applications to their phones. Pay for data, sure. But to disable transfer of files from the phone using bluetooth, requiring expensive air charges? (Yes, Verizon, I'm looking at you), that's crazy.
I use it occasionally to often. It's nice - quality is quite decent. They really need to get the word out better, and get better carriage, not enough cable systems offer it, I believe. Nice with the gameplan stuff, too. It's convenient, but the truth is, I like my HDTV better :)
Good cable management products are a good first step. I like Panduit's.
Label each side of any cable with a "wire run number" and document these religiously. If you have someone else doing the work for you, check out ranges of wire numbers to them.
We use numbers with a two-letter series and then 4 digits.
For your initial install, put AA0001 at position 1, and work upwards. While obviously, this won't be the case for everything, for larger bundles, its easier to deal with.
Finally, label the patch points clearly. ADC makes great designations strips with plastic windows.
I'm a fan of InterMapper, powerful but not overly complicated, and easily extensible. It also runs on MacOSX, Windows, Linux, Solaris, and FreeBSD. It was originally developed at Dartmouth College to support their network, and has been marketed commercially since 1996.
So now it's Plays for Sure, maybe?
Judging from past conversions, you'd better keep the original version close at hand, because when the conversion doesn't look right, you're going to have people wanting the original. So now you're dealing with 25% more storage - the original files as a safety copy, and the new 'improved' conversions. Hmmm.
Yeah, and there's the whole "using a stopwatch to time transfers from the computer to the card" thing..
I was under the impression he used Keynote. (Reference)
Exactly.
The advantage I see in the article is basically that this is lighter than a regular antenna. While that's useful, is that it? Rapid deployment would still require an airship; wouldn't it make sense to outfit the airship with the appropriate antenna already (as an optional package)?
All true. Wish I could mod you up, but clearly I've posted. Doh. Thanks for the info.
Anyways, while there is indeed no 1080p60 content now (well, none distributed), I think HDTV production may settle at some point in the next few years. So if tv show release were available on DVD in 1080p60, it could be useful.
But mostly, was just curious. Was surprised to not see this specified anywhere.
Anyone know if that is 1080p/60 or just 1080p/24? Didn't see this specified on Samsung's website or in the user manual.
From what I can tell, you've nailed what they're doing.
Or just add encoders so rotating the sphere can be used as a navigation tool..
Actually - it appears they do the same thing Google's researchers talk about already: Reference
I have a philips 32" conventional CRT HDTV that I love. Not quite "Large-Format" - but direct view CRT is the best image by far out of all the technologies I've seen.
According to people in the know from both Canon and Toshiba during NAB2006, these are not coming any time soon. 2008 at the earliest is what they said. (That said, the demo of this tech earlier this year was simply amazing.
It's ternary - dots, dashes, and spaces.
I wonder if "layer two" has something to do with the plaintext "typos" (ie iqlusion).
With palimpset as a key to K1, that might point to something that's been written on multiple times, with the previous writing still poking through.
Probably not, but it's interesting how that could possible refer back...
Unless you're doing this a lot, you probably can find a facility that will have the appropriate scan converters. The easiest way is probably going to be DVI->HD-SDI->Capture Card. There are lots of places that have this (expensive) equipment. You're going to need very fast disks - uncompressed HD is huge.