I am using Microsoft.Directx.AudioVideo.Playback.dll for my video player and everything went very well...
But now I have videos with a double audio track and I can't find how to change the audio track or how to put subtitles...
Could you help me please, I know that somehow it has to be done, but I don't know how!
Thank you so much for everything
The design of this API is not taking into account that media files might have multiple audio tracks. You will need to use a different API offering better track and subtitle flexibility, such as high level WPF MediaElement or some wrapper over low level media APIs like DirectShow or Media Foundation (respectively DirectShow.NET library, and less so MediaFoundation.NET).
If you expect similar ease of use equal to Microsoft.DirectX.AudioVideoPlayback API, you would probably want to use .NET APIs and controls like WPF MediaElement, XAML MediaPlayerElement, staying within their limitations and types of media they offer support for.
Use of low level media APIs (which in turn are all expecting consumption from C++ and not .NET) with wrappers is offering better flexibility but is also notoriously associated with need to dive deep into very small details of media playback.
Related
I am trying to make an existing website accessible but I'm struggling with a banner that has a video background streamed from vimeo. I found an identical issue in this SO thread Making a video element with no sound accessible. The poster stated that axe Tools failed the video as it had no captions - the same situation I face.
The accepted answer does not solve that issue though. Setting a parent element to aria-hidden has no impact on axeTools. I need to make the site accessible but also to pass an audit. Does anyone know a way to do this? It seems to me that WCAG is not well thought out here as it seems to have no video equivalent to alt="" or aria-role="presentation" as it does for images when a video is purely decorative and conveys no meaningful information.
Ignore axe or any other automated testing tool for the moment because they often have errors in their reporting. Axe-like tools are not the standard for measuring accessibility. WCAG is. Using a human and the Web Content Accessibility Guidelines is your sure source to know if you are conformant or not.
In this case, you have two guidelines that apply.
1.2.1 Audio-only and Video-only (Prerecorded)
2.2.2 Pause, Stop, Hide
For the first, it says:
Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
So two key points here are:
You can either have an alternative for time-based media (which is often a transcript, and in this case you could have a transcript that describes what is going on in the video) or you can have an audio track that describes the same thing.
You only need this alternative if the video has meaning. The guideline says the alternative must provide "equivalent information". So what's the purpose or meaning of the video? Does it provide information or is it decorative? If the video were removed, would critical information be lost? If it's purely decorative and doesn't provide anything, then the "equivalent information" would essentially be "nothing". The video could be hidden from assistive technology. But you'd want to talk to your designers about the purpose or meaning of the video.
The second guideline, 2.2.2, says if there's moving content (usually an animation but a video counts as moving information), then the user needs a way to stop it. That's normally done with a pause button on the video but it could be done with lots of other ways.
In summary, you need to decide the purpose of the video and whether it conveys information, and if so, decide what an "equivalent" experience would be, and also provide a way to pause the video.
I want to do my final year project on augmented reality geo-localization,
Please tell me, from where to start ?
what technology to learn ?
what are recruitments to development this kind of application ?
If you want to perform Geo-Localisation and use GPS, I wouldn't recommend using Unity. It's arbitrary coordinate system can be a bit confusing and difficult to make an app using GPS that's reliable enough.
For Augmented Reality, you can't use anything like Oculus Rift or Google Cardboard, because those are Virtual Reality headsets and have no way of allowing the user to see the real world. Augmented Reality peripherals are things like Microsoft Hololens or Google Glass, neither of which are commercially available but there are cheap knock offs that are. AR can also of course be used on any mobile device, since they all have a camera built-in and chips powerful enough to process all the tracking data.
As for making an actual app, the best thing you can do is have a go. Analyse your market, see where the gaps are. If you want to make an app for a specific OS that isn't cross-platform, I would recommend learning some Objbective-C (for iOS) or Java (for Android), if you don't know any already.
For cross-platform, I would say something like Xamarin would be useful for making an app on both the major OSes, it was recently made free by Microsoft and you can essentially make one app in C# that works across all devices.
For the Augmented Reality itself, there are frameworks out there that can be used for your purposes. Things like Kudan, Vuforia, Wikitude, etc. Some of them offer free versions of their software. You can use these to deal with all the tracking and projection side of things so you don't have to go about creating your own AR engine.
The best thing to do is probably to sit down for a few minutes, or hours, and think about what you're going to do. Figure out what you want the end result to look like, then work backwards and think about the best way to achieve that goal. Eventually you will arrive at the language and engine you want to use to make your life as easy as possible and then you can get started learning from tutorials online and getting your app out into the world.
you can check my tutorial about geo-based augmented reality solution on Android: https://www.netguru.co/blog/augmented-reality-mobile-android
I have presented there the basics and how to start with simple implementation.
Well a good starting point would be to ask yourself few questions:
What type of devices, you plan to work on(oculus rift, google cardboard, Microsoft Hololens, web etc)?
Augmented Reality is achievable in both Web-Context and Application-context. Which route do you want to go for?
Depending on these questions, if you choose to do a normal application based on a device, then depending on the device(Oculus Rift, Google Cardboard, Microsoft Hololens), you would need to grab their specific developer kits and learn how to develop apps using the documentation. For Oculus rift and Microsoft Hololens, you would need the respective Headsets inorder to make an app in that, but If it comes to google cardboard, all you need is you mobile phone with a good processing power.
There is another way to work on augmented reality applications, that is by doing a Web Application using some amazing javascript libraries like Awe.js, Three.js and JSARToolkit.
You can google about them and find out more.
One of the more accessible ways to learn Augmented reality is Project Tango.
Devices are around $500 last I checked and you can use a free version of Unity + Project Tango's free plugin:
https://developers.google.com/project-tango/
Which ever hardware you pick I'd recommend checking out Unity3D as it seems to be the platform of choice for AR/VR at the moment. There are other options... this just provides the most flexibility based on all of the platforms it supports.
Side note: I have no affiliation with Project Tango and am in fact working on another platform... but it isn't as accessible at the moment.
I am reading articles about Proximity on Windows Phone. I have the following ideea. I have an app that can exchange small messages between two phones through encoded audio. Can I use proximity and replace NFC support with my app that transfer messages using sound. I need only an advice if the NFC usage in proximity can be replaced with any other functionality that can intentionally send certain messages. I want to know if it;s a good ideea to pursue my concept.
Thanks
Unfortunately for you, Windows Phone OS is not a LEGO constructor where you can replace core system services with your own implementation.
At least not with any documented API.
And if you'll use some undocumented APIs, forget about the windows store.
You can probably do that if you're representing an OEM company that builds windows phone devices.
If you're an individual, what you're trying to do might be possible with Android OS. Search for something like "android building custom ROM".
P.S. I think it's a great idea to pursue your concept.
I really miss the simplicity of IR ports in devices.
Very likely, your acoustic pairing could do the job just as good, while requiring no extra hardware.
The recent article of steve jobs link
made me think about the future of flash. I'm learning actionscript 3.0 in my studies but is it the right decision still to go for it? I was pretty sure that I will be able to build application in as3 for iphones/ipads in the near future. It seems to me, while I would stay with flash, the market will be polarized by apple and adobe and you will always work double for both clientele, or just lose half of them.
Which decision would you take as a designer, if you were still at university and you intend to become a freelancer?
This question has been around a lot of times. For my opinion on flash's future please look at this answer: Should I Abandon Adobe Flash for HTML5 and <canvas>?
If you are a designer, you will probably actually feel good working with Adobe's Creative Suite, including Flash CS3/CS4/CS5. CS5 will be able to export HTML5 in the near future: http://www.9to5mac.com/Flash-html5-canvas-35409730 . You shouldn't be too worried. OTOH you should consider, that whatever CS5 exports is likely to perform poorer in HTML5, than on flash player.
From my perspective as a developer, I think there is no harm in learning any language, altough ActionScript 3 is relatively boring and easy to grasp. However this makes it a good language to learn programming, including many best practices. The most important things you learn as a programmer transcend languages. The more languages you try to really fully understand and exploit, the better you become by understanding the approaches they promote.
My personal advice to web developers is to have a look at Haxe. It is a much more powerful, elegant and expressive language than ActionScript and it allows you to target many platforms. Enough to build a whole web app on 'classic' platforms with only one language. Haxe's C++ backend allows building native iPhone apps using an SDL based port of the flash player API, although currently it's not very clear whether Apple's policy will allow distribution. Nonetheless it is an open source language with an enthusiastic community, that moves really fast and adapts to changes rapidly (e.g. unlike ActionScript Haxe can leverage flash player 10's alchemy opcodes for fast memory access) making you as a developer independant.
edit: I have personally dropped any plans of targetting the platform until Apple is willing to ease its very restictive policies, since I find this kind of behaviour intollerable. Nonetheless, I think Objective-C is a great and inspiring language, so you may actually wanna have a look at it.
I think that reports of the death of flash have been greatly exaggerated. Flash has always been "the bad guy" - self-proclaimed experts have always loudly declared that Flash sucks and is on its way out, but oddly enough I've never had any trouble finding lots of Flash work. There are things that you can do quickly and easily in Flash that are either much harder or flat-out impossible without it. It's an amazing tool and it's going to be in use at least in some capacity for the foreseeable future.
That said, even if Flash on the web goes the way of the dodo in two years (which won't happen) it's still a valuable tool. It's a wonderful way to learn Object Oriented Programming, and its uses go far beyond shiny websites. You can use something like Flash Builder in Eclipse to get accustomed to working in a code-oriented IDE, you can build AIR apps to deploy across platforms, you will soon be able to publish saleable apps to every major phone including the iPhone, etc. I've been having a lot of fun with it lately getting it to work with Arduino - it's just a hobby project but I'm trying to build a little helicopter that I can control from an AIR app. I'd be curious to see someone do that in HTML5. ;)
Flash is amazingly powerful - your abilities are in many respects limited only by your imagination and willingness to figure out how to make it work. It's really bizarre to read all of this stuff about how (some) browsers can now play (certain types of) video one their own, ergo Flash is Dead. How unimaginative. :)
This is a tough call. Flash is a fairly dominant technology at this point when it comes to media-intensive web sites. Flash is also very popular for delivering mini-games. I do think that Flash video, which is currently also dominant, will gradually be replaced by HTML5 technologies. I'm not so sure that Flash can be replaced easily when it comes to those media-intensive sites. There is a large number of very talented people comfortable with Flash that might be reluctant to adopt other technologies. I would probably hedge my bets and get comfortable with Javascript and other HTML5 technologies.
Apple vs. Adobe controversy reveals two opposite views of mobile computing.
Apple wants that its developers make the best of its devices by excluding middleware. The aim is to deliver the best possible user experience.
Adobe wants that its developers publish their work on as many platforms as possible. The aim is to reach the widest audience.
Nobody knows which view will win in the future. The mobile war is just beginning...
I think it depends on how far into the future you want to look, and what you think is most important. Flash on the desktop will not die for a long time, if ever. If that is good enough, keep going with where you're going. If not using flash on iPhone/iPad is a deal breaker, you only really have two choices - Objective-C or HTML5.
HTML5 is definitely gaining momentum, but it can't be used directly in all browsers yet, and likely for a while. However, in the mobile space, there is pretty excellent support in the major smart phones.
There isn't a single platform/technology/language that can hit everything. If I were going to bet money on the future, though, I would say HTML5 is going to win for the most reach across platforms. And given it is on the rise, I would bet that in the next few years, there will be a lot of demand for good developers in this area, but don't expect the path to be fully paved for you. You'll have to get your hands a little dirty. If you're looking for a decent editor, I use Netbeans, but I also do Java development, so that makes sense for me. Search around, though, and you'll probably find a decent set of tools that work well for you. It is a very active space.
As far as I'm concerned, Actionscript is a pretty good language to learn OOP. Javascript is a bit shit. Eitherway, I would expect you'd learn a certain set of (frontend/2d graphics) skills which will come in handy regardless of the vehicle you'll eventually use to deploy your work.
Personally, I like the flexscript language used by Flash, it's more structured and object oriented than Javascript. Also it has real inheritance, not the prototype based crap, and compiles to bytecode. For the artist, Flash is easier to use in many ways due to the available tools.
I do hope for better integration into browsers. The current flash plugin is clunky and causes crashes for many users, also the plugin system makes it integrate badly into the flow of pages.
With HTML5, I think the browser plugin idiom is dying in general. Everything from video playback to fancy vector animations can be done with just HTML + Javascript. Even a standard for 3D graphics in webpages is on the way (O3D).
Also I wonder how Adobe will cope with the current explosion of platforms/operating sytems/browsers, especially in the mobile realm. At the moment, the Flash support for systems except for Windows on PC isn't much good.
Just as projects like SVGWeb brings SVG capabilities to browsers that don't have native SVG, I would expect that if/when HTML5 gains traction against Flash there will be conversion capabilities from existing Flash to browsers without Flash. In fact, Adobe already has a conversion from Flash to iPhone using Flash Professional CS5. IMHO, there's too much Flash content in the wild for this not to happen eventually, and there are too many people for which Actionscript is their primary (or only) language for some conversion not to happen.
Career-wise, the clear long-term trend is away from Flash, and I agree with Tom that hedging your bets is wise. However, HTML5 is still fairly new, and you might do yourself a disservice to ignore Flash at this point. With conversion technologies, a Flash skillset will likely be usable for at least several years.
We're about to build a Blackberry application but would love some input on whether to implement using J2ME (MIDlet based) or Blackberry native (UIApplication).
I understand some of the tradeoffs. J2ME will be more flexible if we want to port the app to other devices. RIM has better support for Blackberry native.
The place I'm still lacking information, though, is on the UI side. We want to build an app that has a great user experience, and one that looks like other apps BB users are accustomed to. Can we do this if we go the J2ME route?
Apologies for the somewhat subjective and less technical nature of the question.
I've tried it both ways - building a pure MIDP app to run on BlackBerry and non-BLackBerry platforms and building a separate BlackBerry app (often using much of the same business-logic and networking code as the MIDP app). Definitely go the BlackBerry native route.
It's all about the BB UI classes. They'll give you the ability to (among other things) respond to the different type of menu events (trackball and menu key), respond to BB specific key codes, if you're interested in the Storm take advantage of the orientation sensor and touch support. Plus they're a much richer set of UI elements to work with. You can build up a lot (but not all) of what they do in pure MIDP, but end up customizing so much of it for each platform that you won't save anything in the end. Starting with the BB UI and customizing saves a lot of time and effort.
Even in gaming applications, or for applications where you're custom drawing all your components, you have better access to the BlackBerry graphics APIs and get better performance going the BlackBerry native app route. And you still have better detail about input events.
Finally there are some nice lifecycle things you can do with BlackBerry native apps, like pushing to the background, or auto-running on system startup that you can't do with MIDlets, which may be of interest depending on your application.
Also think about market - if you're planning on supporting BlackBerry right away, and then maybe other MIDP platforms down the road, it's usually a better plan to execute the best you can on your initial platform. There probably won't be much of a reason to port to MIDP later if you don't succeed on BlackBerry first.
BlackBerry is a very difficult platform to program for. I went the native route and found it to be very poorly documented and overall just a miserable design to work with. I did feel it to be necessary because you will lose the ability for certain features (scroll wheel?) if you go the J2ME route. It's a tradeoff and you'll have to choose the one that fits better for your specific need.
I have been working with J2ME since 2002 when the Nextel/Motorola phones were in the forefront of J2ME functionality. I deal primarily with non-gaming applications. Today with J2ME evolving and more phones conforming to the JSRs my application continues to port smoothly. This year I finally got around to moving it to a Blackberry device. Two days later my application is fully functional on a Blackberry. The application is purely generic J2ME and uses many of the JSRs (location, bluetooth, xml, etc ). A strong UI design helps. I extended some of my UI classes to support the QWERTY/SureType keypads. I have used a variety of native applications found on Blackberry devices (not games) and I have yet to justify any reason to venture off to the RIM API to see what I would benefit. The arguments expressed above by other fellow programmers further prove that there is very little to gain unless you are purely devoted to a Blackberry device platform.
Without knowing the scope of your application, meaning which devices you will target, another thing that you will need to take into consideration is the ever expanding differences in input for each BlackBerry model. Some devices, like the Curve and the Bold, are standard QWERTY pads where other devices, like the PEARL, have SureType pads. And then there's the Storm which supports both depending on the orientation of the screen. Also, the SureType pad needs to be used as a standard number pad if the user has it set that way. The native APIs have support for all of this where you won't have that luxury with standard MIDP.
Another tip when designing your user experience, I would get my hands on a few different BlackBerry models and try out some of the apps that come standard as there are a lot of shortcuts that users become accustomed to using that you might not even realize exist. For instance, the SPACE bar pages down. This is huge for reading docs, however I have a third party RSS feed reader that does not have this functionality and I always attempt to use it first before remembering that it doesn't exist in this app. That kind of small detail can make a huge difference to BlackBerry users.
There is a way in between: You could use J2ME-Polish and code natively in J2ME. Polish will add the look and feel of a native BlackBerry app to some extent. That has the advantage of porting your app to other J2ME phones and not be limited to BlackBerry.
I agree with Anthony, I'd go with the BlackBerry specific APIs for BlackBerry apps. J2ME is just not portable, and BlackBerry has a lot better support for their proprietary APIs.
From my experience: stick with the native BlackBerry UiApplication. It is the best for BlackBerry and provides the best user experience for BlackBerry users. You can't copy that with J2ME easily.
J2ME is simple to develop. And, BlackBerry API has many feature also you can use restricted class with simple signing. BlackBerry sells their sign certificate and it is cheap. 20$. You can use this certificate to sign and use all restricted class. In J2ME, sometimes you must use more than one certificate, even you can not use all phone capabilities. So, my suggestion is, use BlackBerry native API and some J2ME Wrapper Codes. So that, you can code easly as J2ME and can use all capabilities of BlackBerry native API.