Building a Video Streaming Backend For iOS using HTTP Live Streaming

Recently for a project I was working on, I needed to set up a video streaming backend for an iOS app. After digging around and seeing what the potential solutions for this were, I decided to use Amazon AWS as the backend. Next, in terms of the format that I should use, it seemed that http live streaming was the best option. Since it took a bit of time to organize and layout how this system worked, I figured it would be nice to write what I found.


Steps to Building your own Streaming Backend 

  1. Save an original video file to disk that you want to stream. This will be typically be some quicktime format, mp4, etc.
  2. Log onto your Amazon AWS account (or make one) (http://aws.amazon.com/) and create 3 s3 buckets. One will be for the original video files, one is for a thumbnail preview of each video, and one will be for the actual streaming video files.
  3. Either through code or the amazon web interface, upload that file to the s3 bucket made to store all video files.
  4. Now, to convert these videos to a streaming format, we will need to do several things. First, I think it is probably a good idea to go over how http streaming actually works. so:
    1. HTTP Live Streaming
      1. Basically an extension of audio (mp3) streaming
      2. File format is M3U8.
      3. This looks something like:

        #EXT-X-VERSION:3 #EXTM3U #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:1 # Old-style integer duration; avoid for newer clients. #EXTINF:10, http://media.example.com/segment0.ts # New-style floating-point duration; use for modern clients. #EXTINF:10.0, http://media.example.com/segment1.ts #EXTINF:9.5, http://media.example.com/segment2.ts #EXT-X-ENDLIST


      4. Essentially, it is a list of a ton of smaller .ts files. Apple recommends these to be about 10 seconds of video each. So, we need to convert our large video file into a ton of small .ts file clips, and then generate a M3U8 file that describes all the clips we need to make up our original video and therefore let the video actually stream.
  5. So, one bucket will hole these .m38u files (and all the corresponding .ts files) and then that file url is directly playable by various UI elements of iOS.
  6. To convert from .mov files or any original format to playable .m38u file, you will need to use the Amazon Elastic Transcoder.
    1. Open up the Elastic Transcoder on Amazon AWS console.
    2. Create a new Pipeline and hook up input and output buckets
    3. Create a new Transcoding Job.
      1. Input key:  filename of your desire
      2. output key prefix: folder you want your output in i.e. ‘myStreamingVids/’
      3. I used a system preset of HLS 2m
      4. Use a segment duration of 10
      5. output key: whatever you want
      6. Set master playlist name to final video url stream name
      7. set playlist format to be hlsv3
      8. set ouputs in master playlist to be your output key.
      9. Create job. 
    4. This will kickoff and run this job.
  7. Use Amazon AWS Lambda
    1. Set up notifications to be called whenever a new video is uploaded to s3 input videos bucket. (I have it called on all new uploads)
    2. This calls your Lambda function. (its a .js file)
    3. My JS file extracts file info and then creates an Elastic Transcoder Job and adds it to my pipeline.

2013.

Unlike 2011 and 2012, 2013 was less of a year of new things. This past year was a year of focus and learning. By now, I have settled into college life, and have already lived and worked in the Bay area for two summers. I am no longer a teenager, and have entered my twenties. Overall, I spent more time working and thinking, and became more deeply involved in what I did in my everyday life – whether it be relationships and friendships, software engineering, or schoolwork.  

I spent less time on social sites, and instead spent more time reading. I took more of an initiative to keep my things organized and my room clean. The past few years were focused on breadth – more people, more topics, more adventures, etc. This year I still had those interests, but instead had more of a focus on depth – really learning about my friends, taking time to learn computer science and what it takes to be a good software engineer, reading up on music, coffee, etc. Instead of wasting a ton of time on Facebook , constantly refreshing the page to see if any friends posted a new picture or if I have a new notification, I would spend time looking up bands I liked, or reading more technical websites on computer science and programming. I found myself wanting to spend more time with a smaller group of friends, rather than spend my time at larger parties or events with lots of people I only barely knew.

It was a good year. I was able to spend a summer at Apple in California working on iOS as an intern. It looks like I even (hopefully) got a patent out of it. I drank a lot of coffee and talked to a lot of cool people.

2014 will be interesting. I will be entering my final years of college, and be turning 21. I am excited.

This past summer.

This past summer I was able to spend a summer in Silicon Valley working at Apple.  I was a software engineering intern, working on iOS. I also lived in downtown San Francisco with some of my best friends from the University of Michigan. I learned a ton of things and would by far call this summer one of the most important times of my life. Here are a few thoughts.

Apple.

When I found out I had an offer for a company I had been obsessed with since I was about 13, I honestly didn’t know what to feel besides an incredible amount of  excitement to start working. It would be impossible to write out and explain everything that I learned from Apple. Apple isn’t simply a company that people go to because they want to just make some money and do whatever they got a degree for.  People end up at Apple because they love what they do, have strong opinions, and want to build incredible products that impact millions and millions of people. Everyone you meet at Apple is there for a reason.

Beyond just caring about their work, people at Apple seem to do something incredible: they combine what they truly care about with whatever they do for Apple  producing authentic, incredible products. Whether the interest was  parasailing, reenacting Shakespeare, or owning a winery,  everyone brought these sometimes bizarre, quirky interests to work and produced some really incredible things. The best work of your life comes by combining all of your interests, not replacing your passions and interests with some job that pays the bills.

Additionally, Apple maintains their culture by embracing a brilliant mixture of psychedelia/surfing/engineering/music/art/zen/liberal arts. In addition to discussing how to optimize the performance of a UITableView, my manager and I would discuss what music we both liked, where to take good road trips, and what lenses I should buy for my camera.

Silicon Valley Internships. 

Although I am  biased, I would say that interning at a company in silicon valley is one of the best experiences you can have in college, and will truly change your life. You will meet people who are very similar to you from across the world, and have a few months to hang out with them and have the adventures of your life. Much of the “growing up” I have done in college has been during my summer internships, and not so much during my school years.  Internships are a perfect intersection of the exploration and learning of college with the freedom and work of the real world.

Other Things I Learned. 

I have smart friends.

Mission Dolores Park is a way of life on weekends.

IMG_5545

Summer bonfires on the coast are fantastic.

IMG_5912

San Francisco is not cheap.

San Francisco is much more amazing if you explore the neighborhoods and become well acquainted with them.

Tim Cook loves oreo froyo. (There is a very stalkerish photo I have somewhere on my instagram if you really are that curious.)

Taqueria Cancun will forever make Chipotle taste bland.

Road trips are fun (especially in nice cars)

IMG_6375f2466ed601ff11e3b2e322000a1f9a5c_7

Chris is impossible to wake up on weekends.

Sam hates chalk.

Storyboards/Nibs vs. Doing Everything With Code in iOS

When you start working on a new app, one major decision that needs to be made is whether you want to do all of the interface work graphically (through xibs/storyboards) or programatically. Each method has pros and cons. Hopefully this post will help you make the best choice for your project!

Why Storyboards are Actually Really Cool…

With my experience, I have found that the best time to use interface tools to build your app is when you are quickly prototyping something by yourself. If you are at a hackathon, or playing around with a new app idea, doing all the interface work in storyboards is actually quite ideal. You can very quickly iterate and pump out a half decent functioning app in very little time. Additionally, if you are just beginning iOS, it is incredibly helpful to have the ability to visualize how code is linked up to a functioning interface. Even though I usually don’t use interface builder in projects now, it greatly helped my understanding of iOS development by allowing me to visually link snippets of code to the graphics I would see on the screen. This is really cool, and makes concepts that can be hard to comprehend very intuitive. 

Why Storyboards Aren’t Always that Great…

So, even though Interface Builder and Storyboards are a really cool technology and are fantastic when learning and prototyping things on iOS, as you begin dealing with source control and collaborating with other developers, you will rapidly run into issues. For example, lets say I am on a team of developers, and by accident two developers fix the same bug or add or overwrite something on the same view using storyboards. This will cause a merge conflict (assuming you are doing source control with git). Now, since the actual interface “code” generated by Interface Builder is non-readable xml, it can be nearly impossibly to fix even the smallest merge conflict in a massive storyboard file. This could lead to massive amounts of work being lost or corrupted. This is a very bad thing. 

Next, since storyboards are essentially a level of abstraction on Cocoa, it can be much harder to do customization of UI. For example, if I wanted to recreate the now popular interface flow of sliding the main view controller to the right to access the side menu view controller, I would have to get a reference to the two view controllers and navigation controller stack.  If I built the app doing everything programmatically, this would be fairly straightforward and also be pretty clean code. With Storyboards however, just to get a reference to a single view controller I would have to do something like this:

MyViewController *controller = (MyViewController*)[mainStoryboard
instantiateViewControllerWithIdentifier: @”<Controller ID>”];

This is kind of gross and unnecessarily long code. Also, with this additional abstraction, it could be much harder to track down small bugs and other flaws. 

Finally, if you are working on a very large project over the course of a few months, if you have everything involving the interface in one place organized by the name of the view it is way easier to track down what happens where, and know where to add or remove code. If you have parts of interface “code” in a storyboard and part of what is driving the interface living in a .m file, it can become very confusing as to what actually controls what. 

 

 

 

A few thoughts after my second year at Michigan

Last week I finished my sophomore year at the University of Michigan for computer science. I had a ton of great experiences throughout the year and here are a few things that stood out.

1.) Computer Science and Software Engineering != Knowing to code. This new trend of “learning to code in 10 days” needs to stop. It is simply not the same as learning to build high quality software, and learning how to understand and interpret complex systems and problems. While yes, I knew how to code last year, I was nowhere near the ability to solve complex problems as I am now after taking more computer science courses and spending time learning how to approach larger, complex problems.

2.) Find friends that push your limits. (in different areas) Find a friend that is a genius at (or at least passionate about)  math, programming, art, english, etc. By having friends who are experts in fields different from your area of expertise, your conversations will be a blend of what you are good at and what they are good at. This will naturally lead to ideas that are cross discipline, both making you more creative and open minded.

3.)Explore. By far, some of my best times this year were those not on campus. I was lucky enough to take several trips with Michigan students. First, I was able to go to UPenn for a huge student hackathon. Being on a huge bus full of 50ish computer science majors and exploring the city of Philadelphia was a ton of fun – and lead to some great ideas. It was also fun building an iPhone app with friends for two days with little sleep. Next, I was able to go to San Francisco a few times – once for interviews, once for a conference – with fellow students. It was such a powerful feeling to have 20-30+ students travel 2000 miles and take over a city for a week. During the second trip, Michigan students also assisted at the conference making a huge impression on all of the recruiters, developers, and other people at the conference. They were amazed so many passionate students would use their spring break to come to a tech conference and hackathons to build products (or show off previously built projects)

4.) Never become comfortable with your current skills or abilities. It is critical that you never become too comfortable with your current level of abilities or knowledge. Constantly push yourself to either know something even better, or learn something new.

JSButton: A simple way to pass blocks to buttons and trigger them with a UIControlEvent

My friend Josh Sklar (a senior at Michigan, and soon to be full time iOS dev at Detroit Labs) wrote a very cool subclass of UIButton that allows you to pass a block to a button and have it executed with a given UIControlEvent.

For example, instead of creating a ton of selectors, you can now simply do:

JSButton *buttonOne = [[JSButton alloc]initWithFrame:CGRectMake((self.view.frame.size.width - kButtonWidth)/2, kLabelHeight, kButtonWidth, kButtonHeight)];
    [buttonOne setTitle:@"Buton One" forState:UIControlStateNormal];

    [buttonOne performBlock:^(id sender) {
        JSButton *btn = (JSButton*)sender;
        NSLog(@"Some trivial code for touching up inside on %@", btn.titleLabel.text);
    } forEvents:UIControlEventTouchUpInside];

    [self.view addSubview:buttonOne];

Here is a link to the repo: https://bitbucket.org/jrmsklar/jsbutton

Developing for iOS by yourself vs. on a team.

When developing for iOS on a team of several other iOS devs, the way you approach and architect the overall project should be different from the way you would personally build an app. Neither approach is “better code” but each method simply allows for time to be saved in each situation. 

When developing an app on your own, it may be beneficial to use storyboards and .xib files in your project. The reason you want to avoid using these graphical files in a team setting is mostly version control. Since these graphical files automatically create large XML files that then compile into interface code, merge conflicts often occur when several people touch the same interface files. When you are working by yourself, since you will likely be the only person working on the file at one given point in time, merge conflicts should not occur. Additionally, writing all code for the interface may give more flexibility and allows for more customization of interface elements. 

When creating the overall flow of the app and figuring out a good code organization pattern, be sure to make code as modular as possible in a team setting. Although this is always a good practice even when working on your own private project, it is essential when on a team. Over this past summer, while working at Path, I quickly learned the benefit of modular code. One of the other iOS engineers on the team and I were working on the same view, and we needed the ability to easily delegate tasks on the feature we were working on. Since we were not using Interface Builder, and making sure to use modular code, he worked on one aspect of the feature as a subview, while I built the rest of it. Since we were not sure how exactly we wanted to implement the UI, by creating a View Controller that looked for the same properties on a subview, we could easily test and swap out different implementations. This saved us a massive amount of time and allowed us to effectively accomplish tasks. 

 

Storing and Saving Data in iOS

So, this will be a fairly short post, but I frequently get asked about storing data in iOS.

Essentially, when it comes to storing data  in iOS you have several options:

  1. NSUserDefaults. If the amount of information you want to save isn’t terribly large, and consists of NSData, NSString, NSNumber, NSDate, NSArray, or NSDictionary, you can easily store it in NSUserDefaults. NSUserDefaults can be read/written to in much the same way you would work with a NSDictionary. For example:                                                
    NSString *test = [NSString alloc]init];
    [test stringByAppendingString:@"test!"];
    //creates string object
    
    NSUserDefaults *myDefaults = [NSUserDefaults standardUserDefaults];
    [myDefaults setObject:test forKey:@"string"];
    [myDefaults synchronize];
    
    //and this data can be accessed by:
    NSString *newTest = [NSString alloc]initWithString:[myDefaults objectForKey:@"string"]];                               
  2. If you REALLY insist on writing to a local text file of some sort, do not put it in your application bundle. The bundle is read only, and you will spend an absurd amount of time debugging this.
  3. You could use sqlite. Code can get a bit tedious and ugly, but it still works fine.
  4. Core Data. http://www.raywenderlich.com/934/core-data-on-ios-5-tutorial-getting-started

That is all!

Most people have no idea how much time it takes to build a great app.

The Main Street Analyst

“How long does it take to build a mobile app?” While the question isn’t as timeless as “How many licks does it take to get to the center of a Tootsie Pop?” (spoiler alert: 3481), it is one that’s very dear to our community of mobile app developers. And now we’ve got an answer. 18 weeks.

In collaboration with research firm AYTM, we surveyed 100 mobile designers to discover how long they expected it would take to build core front- and backend components of an Android or iOS app.  We averaged the responses and then teamed with the designers at Visual.ly to visualize the time required to develop each component of an MVP-quality native app.

For fun, we put app development time in context. Who knew you could drill three 3000-foot oil wells in the time it takes to launch the first version of your “drill for oil”…

View original post 75 more words

Some thoughts on “Entrepreneurship”

I love entrepreneurship, but the term is losing its meaning and is becoming a word to defend a group of lazy, arrogant people who are too “intelligent” to work and instead go to meetups and talk about each other. This must stop.

The reason I fell in love in with entrepreneurship was the core idea of following something that personally excites you and transforming it into something that can help other people. You work incredibly hard building something because you really enjoy making actual things.

Unfortunately, it is extremely easy to use adjectives and meet with other people who like these same ideals, but do absolutely nothing towards actually making things.

To build great products you need a few things:
1.) A drive to learn, and be willing to give up everything else to spend hours learning marketing, finance, programming, or design.

2.)Be able to see through bloat. You will have many, many people approach you with their ideas, opinions, etc. It is critical you do not waste your time with people who are ignorant, and just like talking about big ideas and do nothing. Find people that are willing to work their ass off, and really understand the industry. For example, one thing that NEEDS to end is this new trend of completely inexperienced business students or non-programmers starting startups that help people learn to code or learn to run a startup. This creates bloat, and is a complete waste of time. If the person running this startup for startups has never actually run a company or written a line of code themselves, what makes them qualified to be a teacher? They are not qualified. Now, if they hire people to teach at this new code or startup school that have experience, this is very valuable and a great move.

3.) Learn from mentors. I have learned pretty much everything I know from experienced developers, business leaders, etc. School is incredibly valuable, but getting solid mentors gives you real world experience. For me, I was lucky enough to get a job at Detroit Labs right out of high school for the summer. I cannot even begin to explain how much I learned just by sitting in a room with the four cofounders and seeing how they ran the company. Additionally, being a Kleiner Perkins fellow this summer was incredible. Being able to talk informally with some of the top VC’s was so valuable.

4.) Be willing to work. Really freaking hard. Don’t trick yourself into thinking sending emails is hard work. Actually work. One very valuable thing going to a very competitive school has instilled in me is learning to work hard, and more intelligently . School makes you to be evaluated by someone other than yourself. This can expose critical flaws. School is not the only way to get this type of feedback, but it is a very great means to do so.