[objectively:smart]

Well, we may never know that, at least not in the foreseeable future, because getting rid of motion blur in already recorded movies would be… somewhat complicated to say the least, but we can at least artificially increase the number of frames per second. Okay, but hold on – if the missing frames are not present in the source material, where would they come from? From the aforementioned interpolation, of course!

Now, let's set up a video player to perform the real-time interpolation for you. I'll be using mpv in this tutorial as that's objectively the best video player for OS X out there (stop arguing, you're just being ridiculous with your VLC) but it might be possible to accomplish similar results with other players. But it probably isn't, ha!

We'll need to get some additional tools first – namely VapourSynth to filter the video just before mpv plays it for you and MVTools to provide the best motion interpolation filters for VapourSynth. Since we need mpv to support VapourSynth, we can't use Coalgirls' pre-built binary – we'll have to go back to the square one and compile our own binary from source. Open Terminal.app and if you don't use the Homebrew package manager already, please go sit in the corner and feel an appropriate level of embarassment. When you're back, install Homebrew with the following command:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Add the mpv repository:

brew tap mpv-player/mpv

And install VapourSynth and MVTools1:

brew install vapoursynth brew install --HEAD mvtools

Now compile mpv with the VapourSynth support and create symlink to the /Applications directory:

brew install mpv --with-vapoursynth brew linkapps mpv

Set up autoload of the MVTools library:

cd /usr/local/Cellar/vapoursynth/26/lib/vapoursynth ln -s /usr/local/Cellar/mvtools/HEAD/lib/libmvtools.dylib .

And create VapourSynth configuration script in your ~/.mpv directory (create the directory with mkdir ~/.mpv if it doesn't exist). I called mine mvtools.vpy and it looks like this:

import vapoursynth as vs core = vs.get_core() clip = video_in if not (clip.width > 1920 or clip.height > 1080 or container_fps > 59): clip = core.std.AssumeFPS(clip, fpsnum = int(container_fps * 1e8), fpsden = int(1e8)) sup = core.mv.Super(clip, pel=2, hpad=0, vpad=0) bvec = core.mv.Analyse(sup, blksize=16, isb=True, chroma=True, search=3, searchparam=1) fvec = core.mv.Analyse(sup, blksize=16, isb=False, chroma=True, search=3, searchparam=1) clip = core.mv.BlockFPS(clip, sup, bvec, fvec, num=60000, den=1001, mode=3, thscd2=12) clip.set_output()

The indentation is important because… reasons. Now edit your mpv configuration file, it should reside in the ~/.config/mpv/ directory under the mpv.conf name. Make it look like this:

vo=opengl-hq vf=format=yuv420p,vapoursynth=~/.mpv/mvtools.vpy

If you've placed the MVTools script to another location, you might want to reflect that change in the configuration file as well. Just a hint. Well, at this point you should be good to go, really – that is, unless I forgot some step along the way (let me know in the comments if that's the case). Feel free to set up mpv as your default video player as well – actually forget that, chances are it's your video player to go for a long time, right?

I'll leave with a few quick notes that I gathered during my first two days of usage:

yes, you can use it with Popcorn-Time, but you might want to add the idle=yes and keep-open=always options into your mpv configuration file;

no, it's not one hundred percent stable, you may expect issues in particular whenever a different source file is loaded within the same mkv container;

yes, you can use it to play YouTube video files as well, just brew install youtube-dl and brew reinstall ffmpeg --with-openssl; also consider adding ytdl-format=299+bestaudio/137+bestaudio/298+bestaudio/22/135+bestaudio/18/best to your mpv config file;

no, I did not report the aforementioned bug, please don't hit me reported, pull request not accepted as of yet;

yes, you could even be able to use it with Crunchyroll and other services, if you installed youtube-dl with the --with-rtmpdump option; and finally

no, you won't be able to watch any video with measly 24 FPS after this anymore, it would just feel weird.

How is that possible, do you ask? Well, let me tell you that our beloved friend IBOutlet has a little, not very well known brother-in-law that's called IBOutletCollection. And what exactly does IBOutletCollection do? Well, precisely what it sounds like, it's a collection of outlets. In the code, it can be defined like this:

@property (strong, nonatomic) IBOutletCollection(UITextField) NSArray *textFields;

Mind the required strong keyword, that's a rather big and at first glance unexpected change when compared to all of our IBOutlet property lines.

After you define your IBOutletCollection in code, you can fill the NSArray it's represented with in Interface Builder, much like you would do with regular outlets. So far it's all good and dandy, so where's the catch?

Well, truth to be told, there are two, but they're both solved by using the same solution. First problem is that because you now have your views (in my case, text fields – remember, we're creating a form) in an array, how do you actually know which text field are you working with when enumerating the collection? Furthermore, do you even know the order of the collection? The sad truth is that you don't, the order of elements in outlet collection is not guaranteed and despite the fact that right now in current version of iOS, the order is quite predictable, we still have to keep the unpredictability in mind and work our way around it to ensure there won't be any unexpected issues with our code in the future. So how do we solve this?

Well, the obvious solution is assigning all of our views a tag, but while that solution truly is obvious, it's also very short-handed: using magic numbers is rarely a good idea and limiting ourselves to integer identifiers is only marginally better than shooting ourselves in the foot. Furthermore, these artificial numbers probably won't correspond to identifiers used in our data source and even if they do, what if they happen to change in the future? Are we going to assign new tags to our views? Write a class that converts identifiers in our data to the tags we came up with when designing the form?

No, I have a better solution for you and it's one I already used in my previous article: it's adding a property to existing class, in my case UITextField.

For my needs, a string identifier was the best solution, therefore my UITextField category header file gained this line of code (warning, you may want to choose a smarter variable name than I did):

@property (nonatomic, assign) NSString *id;

And its implementation file gained following line of code:

@dynamic id;

After doing that (don't forget to import the DProperty pod – if you're unsure how to do that, feel free to consult my previous article on this topic), you're able to set the value of the id variable directly from the Identity Tab in Interface Builder:

Finally, you can enumerate through your text fields (or any other views, for that matter) like this and set their text values once you obtain/parse/get the required data:

for (UITextField *textField in [self textFields]) { [textField setText:[self objectDetails][[textField id]]]; }

You might be able to spot the error if your property list is a relatively short file but mine just reached eighteen thousand lines with the latest spreadsheet from our customer and the last thing in the world you want to do is to go through the entirety of it manually. Fortunately, you don't really have to.

If you fire up Terminal.app, navigate to the folder with your property list file and run the plutil command followed by your property list filename, you get a much more precise error message:

» plutil TrialData.plist TrialData.plist: Found non-key inside <dict> at line 15392

Well, now there's nothing stopping you from creating awesome/terrifying methods such as this one. Except of your conscience, of course.

- (void)filterData { [self setFilteredData:[[[[self trialData] linq_where:^BOOL(id trial) { return [[self selectedYears] containsObject:[trial objectForKey:@"Year"]]; }] linq_where:^BOOL(id trial) { NSString *source = [trial objectForKey:@"Source"]; return ([[self selectedSources] containsObject:SOURCE_ANY] || ([[self selectedSources] containsObject:SOURCE_SPZO] && [source isEqualToString:@"SPZO"]) || ([[self selectedSources] containsObject:SOURCE_UNIVERSITY] && [source isEqualToString:@"University Trials"]) || ([[self selectedSources] containsObject:SOURCE_TD] && [source isEqualToString:@"TD Trials"])); }] linq_where:^BOOL(id trial) { NSString *company = [trial objectForKey:@"Company"]; return ([[self selectedCompanies] containsObject:COMPANY_ANY] || ([[self selectedCompanies] containsObject:COMPANY_OURS] && [company isEqualToString:@"Our"]) || ([[self selectedCompanies] containsObject:COMPANY_COMPETITION] && ![company isEqualToString:@"Our"])); }]]; }

First things first, you're going to need the DProperty library1 and the UITextField extension from previous blog post, so if you haven't done so already, now would be the perfect time to read it and implement these two things. When you're finished doing that, let's enhance the view controller containing all the sneaky little text fieldses in two simple ways: first, you want the view controller to conform to the UITextFieldDelegate protocol, so you edit the header file like this:

@interface MVNewAccountTableViewController : UITableViewController <UITextFieldDelegate>

Second addition happens in the implementation file where you simply add the following method:

#pragma mark UITextField delegate methods - (BOOL)textFieldShouldReturn:(UITextField *)textField { UITextField *nextField = [textField nextField]; if (nextField) { [nextField becomeFirstResponder]; } else { [textField resignFirstResponder]; } return NO; }

Now kids, are you ready for some magic?

Open your storyboard file (or xib file, grandpa) in Interface Builder and set the view controller you just edited as the delegate of all instances of UITextField that are going to have a tab index by holding down the right mouse button and dragging, just like this:

Here comes the last step, this time drag a line from each UITextField that is going to be part of the sequence to the next UITextField in line and define natural and logical order of the text fields:

And… that's about it, actually! The most elegant solution to the problem that many iOS developers face!

pod 'DProperty', '~> 0.0'

After that, there's nothing stopping you from creating a category with a similar interface…

@interface UITextField (Extension) @property (nonatomic, assign) IBOutlet UITextField *nextField; @end

… and similar implementation:

#import "MVUITextField.h" @implementation UITextField (Extension) @dynamic nextField; @end

Mind the use of the @dynamic keyword as opposed to the more-often used @sythesise one as @synthesise is just straight up not allowed in a category implementation section.

Well, the app I mentioned before is called Psychoid (please don't hit me, I don't particularly like the name either, but the customer is always right) and it's aimed at the students of the Department of Psychology at the Palacky University in Olomouc. The app itself provides students with up-to-date news from university, current timetable for their respective year, calendar showing all the relevant events and finally instructions how to get into every classroom. Yes, just instructions. The university didn't want us to put a map in there, so you're free to insert a snarky remark about psychology students not being able to read a simple map here: _______________. Done? Wonderful!

I coded most of the app myself, I only needed some help from my boss with the timetable part of the app. Due to this being a pretty small and simple project, I used only one external library (Tapku's unofficial iOS7 fork) to help me implement the calendar. Looking back, I probably could've used AFNetworking to simplify the network code, but oh well!

Finally, you can find Psychoid on the App Store and Google Play and the main screen looks like this. The Android version was not done by us as we don't code for inferior systems. If you excuse me now, I'll go grab my fireproof suit.