Nice entry demo in client side scripting using ASX and Silverlight.
http://blogs.msdn.com/silverlight_sdk/archive/2007/05/31/using-playlists-in-silverlight.aspx
Wednesday, May 28, 2008
I was wrong, and now I'm so ashamed
I was wrong.
XAML Media Element has it's state property. It is MediaElement.CurrentState.
I really don't know how I missed it for so many times before.
Ahh...
XAML Media Element has it's state property. It is MediaElement.CurrentState.
I really don't know how I missed it for so many times before.
Ahh...
Wednesday, May 21, 2008
AviSynth
Recently people asked me for opinion on Avi Synth tool, and after reevaluation, it is really good. Excellent in some ways.
More about Avi Synth on this pages here.
But one thing is missing in AviSynth, and that is better Windows Media support.
I'm thinking of doing some open source - thank you community thing, I will write WM Source plugin for AVS system. You will be able to open any WM URL and use it as AVS source for editing, transforming etc.
Maybe even WM writer to file, network port or push to WM Server.
If someone is interested, I will speed it up.
More about Avi Synth on this pages here.
But one thing is missing in AviSynth, and that is better Windows Media support.
I'm thinking of doing some open source - thank you community thing, I will write WM Source plugin for AVS system. You will be able to open any WM URL and use it as AVS source for editing, transforming etc.
Maybe even WM writer to file, network port or push to WM Server.
If someone is interested, I will speed it up.
Monday, May 12, 2008
WMS 3.0 Prototype
It worked, it worked like a charm.
We can seek unseekable ASF files now, meaning we can position inside WMS live archives before they are closed and indexed.
Minimal delay, with WMS bridge and his Fast Start technologies (although we can create our own now) we can bring low latency pause, and position to time.
Now it is possible to seek and play any ASF file, indexed or not. With minimal overhead in configuration and applications.
No extra cache's, no transcoding, no other container formats, just minimal logic on top of client, minimal, few lines of code. Maybe not even that if I succed integrating this system inside WMS Datasource plugin.
We can seek unseekable ASF files now, meaning we can position inside WMS live archives before they are closed and indexed.
Minimal delay, with WMS bridge and his Fast Start technologies (although we can create our own now) we can bring low latency pause, and position to time.
Now it is possible to seek and play any ASF file, indexed or not. With minimal overhead in configuration and applications.
No extra cache's, no transcoding, no other container formats, just minimal logic on top of client, minimal, few lines of code. Maybe not even that if I succed integrating this system inside WMS Datasource plugin.
Sunday, May 11, 2008
WMS PVR 3.0
Product life starts at version 3.0, as old MS legend says.
I think I cracked the idea about Server Side PVR system based on Windows Media platform to overcome problems with ASF late indexing.
New and important moment of this idea is making client side completely generic, or at least as generic as possible.
Newest idea is using completely generic client - silverlight generic with just a thin layer of logic, enabling it to pause live stream coming from Windows Media Services.
So, in this idea, when you press pause button, media element must switch from main Server Publishing point to custom server pub point and remember correct time stamp.
When client presses play, his media element / player now connects to custom server, but still windows media format port, just it is not WMS port, but custom server (thin layer app, nothing special.)
What are the benefits? Generic silverlight client is possible - from linux to any platform, including nokia phones series 40 & 60 (already signed between companies.)
What are the compromises?
You don't have fast start, some start lag will be introduced, and you don't have advert power of windows media services.
Although it is possible to make workaround to even this problem, creating and reprograming new publishing point for every client with specific time tag. This newly created publishing point would internally connect to custom server, and use it as any other windows media stream from http source. So we would have adverts and fast start.
What are the risks of such soulution?
Well, it would be extremely complex to provide perfect pause, but using some smart psihology, we could revert few secconds before the user paused, and he would not miss anything, with just a little overhead.
For more info, just email me.
I think I cracked the idea about Server Side PVR system based on Windows Media platform to overcome problems with ASF late indexing.
New and important moment of this idea is making client side completely generic, or at least as generic as possible.
Newest idea is using completely generic client - silverlight generic with just a thin layer of logic, enabling it to pause live stream coming from Windows Media Services.
So, in this idea, when you press pause button, media element must switch from main Server Publishing point to custom server pub point and remember correct time stamp.
When client presses play, his media element / player now connects to custom server, but still windows media format port, just it is not WMS port, but custom server (thin layer app, nothing special.)
What are the benefits? Generic silverlight client is possible - from linux to any platform, including nokia phones series 40 & 60 (already signed between companies.)
What are the compromises?
You don't have fast start, some start lag will be introduced, and you don't have advert power of windows media services.
Although it is possible to make workaround to even this problem, creating and reprograming new publishing point for every client with specific time tag. This newly created publishing point would internally connect to custom server, and use it as any other windows media stream from http source. So we would have adverts and fast start.
What are the risks of such soulution?
Well, it would be extremely complex to provide perfect pause, but using some smart psihology, we could revert few secconds before the user paused, and he would not miss anything, with just a little overhead.
For more info, just email me.
Good Programming FAQ
This guy is really good. I've based so many prototypes on his samples as starting points.
Had to share.
Alessandro Angeli's Programming FAQ
Had to share.
Alessandro Angeli's Programming FAQ
Friday, May 9, 2008
Why I hate MediaElement - True testimony
It is very simple.
Little bastard is behaving on it's own. Error descriptions provide no help, or even put you on very bad trail.
The thing is, you can't ask MediaElement for it's State!!! He actively refuses to tell about his state.
Sometimes I just want to punish somebody in WPF team.
This is basic functionality.
No excuses.
Fix it.
P.S.
The problem is not new. In MediaPlayer, similar problem exists. Although there is State property, it causes problems every some time, which is really not something you want to have in 24x7 applications we do.
And especially I dislike bug in rendering that just happen like black screen, with everything normally working, just there is black screen. Virtually undetectable.
Fix it!
Little bastard is behaving on it's own. Error descriptions provide no help, or even put you on very bad trail.
The thing is, you can't ask MediaElement for it's State!!! He actively refuses to tell about his state.
Sometimes I just want to punish somebody in WPF team.
This is basic functionality.
No excuses.
Fix it.
P.S.
The problem is not new. In MediaPlayer, similar problem exists. Although there is State property, it causes problems every some time, which is really not something you want to have in 24x7 applications we do.
And especially I dislike bug in rendering that just happen like black screen, with everything normally working, just there is black screen. Virtually undetectable.
Fix it!
Seeking Media Element with 24h + Archives
What's the catch??
You maybe think that it is trivial, but it's not. Well yes it is, but there is a mislead in MSDN documentation on MediaElement Position property which states correct format:
"HH:MM:SS" when in fact it necessary to work with
"DD.HH:MM:SS" with 24h+ archives.
Of course the problem is worse because the error it gives away are complete nonsense, like Object don't support that method etc. and it worked for the same file with the same object just a minute ago, or at least before you tried to position before "23:59:59".
So instead of using "83:24:10" use "3.11:24:10" format.
You maybe think that it is trivial, but it's not. Well yes it is, but there is a mislead in MSDN documentation on MediaElement Position property which states correct format:
"HH:MM:SS" when in fact it necessary to work with
"DD.HH:MM:SS" with 24h+ archives.
Of course the problem is worse because the error it gives away are complete nonsense, like Object don't support that method etc. and it worked for the same file with the same object just a minute ago, or at least before you tried to position before "23:59:59".
So instead of using "83:24:10" use "3.11:24:10" format.
Subscribe to:
Posts (Atom)