Isn't it an inherent problem with phones that if they are left on charge forever that their battery will explode? I've had test devices that I left connected for months together and inevitably the battery has exploded on every single one of them.
Perhaps, it can be hooked up to a smart plug and charged up whenever battery goes down below a certain percentage and shut it off when it's full.
yeah it probably doesn't matter in practice. you may run into some audio sync issues.
but the ~1 second precision that you see is by accident where the source file happens to have a keyframe every 1 second. that may not be the case always. :)
i understand that this is the fastest way to extract frames, but it is limited by key frame availability in the original file (i.e.) you can only start the output from a keyframe.
in this case, it is important to be aware that the times you specify may not be extracted exactly. it will be off by a few frames based on keyframe availability. the only way to extract exact frames is to re-encode. :)
it reminds me of a time when Larry Page (in a deposition) referred to the code repository at Google as: "I mean, there's some code-based repository thingy".
Slightly off topic, but a hack that i have found to read recipe websites on my phone is to use the "Print Recipe" link that most websites provide. It gets rid of most of the annoying ads, autoplaying videos and unzoomable text (or text tapping on which takes you to some random link because the page resized and you accidentally tapped on an ad).
The "Print Recipe" page usually contains just the recipe in a format which is easy to read without any clutter.
hmm, while this is cool i am not sure if it is a full-fledged replacement for the Google Finance "portfolios" feature. That lets you add the number of stocks you own for each symbol and shows you an aggregate gain/loss per day, etc. That was the main reason i was using google finance.
I have now transitioned to my own Google Sheet with the "=GOOGLEFINANCE()" function for getting the stock data. Works pretty well.
As far as i know, most of the outsourcing companies have a contract with the employee that will make the employee pay a huge fine if he quits them after moving to the US. I'm not sure about the legality of this, but a lot of companies enforce this somehow.
(source: i'm indian and i have a lot of friends who moved here on a H1B through the 'outsourcing' companies).
I am just curious. Wouldn't it be more easier to do this with specific devices than using the phones?
Each passenger can be given a smart card along with the boarding pass (or embedded in the boarding pass). The sensors could merely check for the smart card at certain points and determine how long it took for the passenger to clear security, etc. The airline can then collect the smart card back just before boarding when they scan the boarding pass. Seems like a simple solution that would work without much privacy concerns.
in most countries i've been to (UK, Canada, India) 2G data came in handy for things like navigation. note that 2g is part of your plan and it does not cost anything extra.
nevertheless, they also have an option to upgrade to 3G data for a fee ($10 or so).
FWIW, T-Mobile in the US already has the exact same offering [1]. Their plan has free texts and 2g data in 120+ countries. Calls cost 20 cents per minute.
Looks pretty good. I've been using http://www.airdates.tv/ for this stuff. One suggestion would be to add more service providers like Google Play Movies and Vudu.
the particular example that you want seems to use eplayer. it seems like it's a livestream and uses some proprietary protocol and is not as simple as fetching data from a URL and playing it back. So it's unlikely that you'll be able to watch this particular site for chromecast unless they (either crictime or eplayer) decide to publish an app that implements their proprietary protocol for chromecast.
No, chromecast cannot play flash videos. But you can extract the URL of the videos from common swf based players like JWPlayer using a tool like youtube-dl [1] and then use that URL to playback the content in chromecast. This will probably make a good chrome extension.
yes, it does support the mkv container. WebM and MKV files are usually parsed with the same parser. So pretty much any player that can play WebM can play MKV given the encapsulated codec is supported.
disclosure: i work on the Chrome team but have nothing to do with chromecast.
i see some generic posts about how ffmpeg is written in C and Assembly and will not be re-written in C++, but nothing about Rust.