Forum Replies Created

Page 22 of 80
  • Chris Blair

    March 4, 2010 at 1:38 am in reply to: Best compression for WEB

    Harold Ek: Is there any danger in making decisions based on the visual quality that way without actually uploading and viewing them on the web?

    From our experience you need to upload them to a web server and test them in all the major browsers to see how they’ll play and look. The video will look different on virtually every desktop flash player and media player (that can play flv files).

    It will also look different on an LCD monitor than it does on an older CRT one.

    Different flash players can also have some impact on how videos look and perform…with commercially available players that have years of real-world use and coding improvements often working better than custom made browsers (unless the web designer has a lot of experience building flash players for websites). But this would typically impact things like load/startup times and frame rate and not the overall visual appearance.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 4, 2010 at 1:22 am in reply to: Best compression for WEB

    Craig Seeman: If I hired an expert professional to do a job I wouldn’t then tell them that their methods are wrong. Your job as a professional is advise the client on what needs to be done to meet their needs. Clients certainly know their needs.

    Well obviously we don’t tell them their methods are wrong, we explain all the benefits to using H264, including the ability to do nothing more than link to the H264 and their Flash player will play them. There’s still a ton of resistance from web designers. They’re comfortable with flv’s and often have an “if it’s not broke it doesn’t need fixing” mentality.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 3, 2010 at 4:41 am in reply to: Best compression for WEB

    Craig Seeman: This is why I say, getting back to the original poster, go to H.264 now and at least you won’t get hit with major re-encoding. Of course handsets aren’t using the same files as desktop/laptop inherently so that may have to happen too at some point but at least the former will be ready to go.

    Oh I agree with you…but if his web people have it in their head that flv files are the way to go….we’ve just found it’s often a tough battle to try to convince web designers and administrators that H264 is the better long-term choice. There’s a lot of resistance to it in this part of the country.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 3, 2010 at 2:35 am in reply to: WMV encoding

    If you have access to a Windows system you could try this freebie:

    https://www.tucows.com/preview/521321?q=Freeware+Video+Convert

    You HAVE to use the presets to get it to work but I use it at home on a 5 year old, underpowered laptop and it’s very fast and does a great job encoding to a huge array of formats including WMV.

    Or…theres this affordable Mac converter you can try and buy ($35) if it works.

    https://www.ifunia.com/video-converter-mac.html

    I’ve never used the Mac one but have a friend with a Mac that uses it at home and it does the job for him. Although loading and encoding uncompressed files might be relatively slow depending on the power of your computer.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 3, 2010 at 1:11 am in reply to: Best compression for WEB

    I certainly wasn’t championing Ogg…just pointing out what direction Firefox has decided to go with video in regards to HTML5.

    And certainly with Google and YouTube “diving” into HTML5 it will have an impact, but many big corporations we work with have only recently begun to embrace video as an important part of their online presence, and most don’t have the resources to keep their sites properly updated, much less rework them to take advantage of HTML5’s features.

    Google and YouTube are online companies…so it certainly makes sense for them to be on the leading edge. But many big U.S. corporations don’t think that way…and certainly small to medium sized ones we work with don’t.

    We work with one 8 billion dollar a year corporation (with a dozen well-known brands) that started using video extensively on their sites in late 2008 and early 2009. But then…late in 2009, the company eliminated their web development division, eliminated all creative professionals involved with their websites (16 different brands in all plus another dozen employee only sites) and moved all design, administration etc. to a third party company in India. It literally takes them 4-6 months to get a compressed, ready to load video up onto a site they’re so backlogged with work. Yes…4 to 6 months to get a video posted to their website. And they’re not unique. We hear over and over from Marketing Directors, Communications Directors and Advertising VPs that their number one problem is keeping their website updated and making sure it works properly for clients.

    It’s the first place corporations cut in marketing when the economy is slow like it has been. So while I’m sure companies whose business is built on the web will jump in… nobody we work with has ever mentioned HTML5. Same goes for friends and colleagues of mine who work in Atlanta, Nashville Indy and other good sized U.S. cities. HTML5 isn’t even on their radar. And when it comes to video…even when these companies have web admins on staff, their knowledge of web video is almost always their weakest skill.

    So the point is that it’s going to take time, likely several years for it to become widely adopted.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 2, 2010 at 11:25 pm in reply to: Best compression for WEB

    Lordy…I don’t what you have against me…but all I’m trying to do is provide a little perspective. We work with web designers all the time and the ones we work with are NOT eager to dive into HTML 5. And I’ve read the the “dive into HTML 5” draft you speak of. It’s very technical for the most part but in it he discusses the lack of agreement on standards and the stumbling blocks it presents…namely licensing issues with H264. Plus the lack of server side support that’s likely to take some time to overcome.

    I’m just trying to point out that it’s going to be several years before there’s widespread adoption of it and Flash will be relevant for years to come.

    If you’d like this forum to become a monologue…fine…but I thought the purpose of this site was to be a community where people share information to get perspective and be able to make informed decisions.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 2, 2010 at 9:21 pm in reply to: Best compression for WEB

    Yes, the “when” is inevitable…but there are quite a few stumbling blocks to wide HTML5 implementation anytime soon. Not the least of which is a lack of full support in Internet Explorer, with no current video support in IE8.

    Plus there isn’t an agreement on a video standard (Firefox supports Ogg natively, the others support H264), and a wide lack of HTML5 support on web server software.

    The group that works on HTML 5 alongside W3C — WHATWG, states in its FAQ section that HTML 5 is expected to reach what they call a “candidate release” stage in 2012, and W3C recommendation status in 2022 or later!

    https://www.whatwg.org/

    That doesn’t mean you can’t start implementing it, but web designers we work with are NOT eager to rewrite their sites just yet, or take the time for partial implementation.

    Here’s a quote from Jan. 26th from Mark Pilgrim of Google, who works with the WHATWG and writes their blog:

    Does all that work yet? Hell no. We don’t even have a standard video codec yet! Google Chrome is the only browser that has shipped an implementation of web sockets (although it’s part of WebKit, so presumably Apple could ship it in a future version of Safari if they choose). And the entire device API is still in its infancy. Nobody has even started implementing a prototype of that piece yet, and the whole idea might be scrapped by my next episode. But that’s life on the bleeding edge.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 2, 2010 at 4:00 pm in reply to: Best compression for WEB

    Understand…but I took his comment about:

    The people handling the website say we should encode the files as flv in order to have them widely available.

    …as an indication that his website people must’ve been using a Flash Player since that’s the only thing that would play an flv file.

    Guess he needs to clarify to get a handle on which answers are valid.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 2, 2010 at 2:08 pm in reply to: Best compression for WEB

    Craig Seeman: As long was your webpage builder knows what they’re doing they can use H.264 .mp4 any number of ways depending on the web player plugin they’re targeting.

    That’s the problem, many web designers don’t understand video. At many corporations the IT department handles web administration…not web designers. Designers re-purpose Flash Players they built 3,4, 5 years ago and simply change the physical appearance for new clients. Many are also using older versions of Adobe Flash software to build their players. All of this adds up to deficient performance with H264 files.

    Probably 8 out of 10 requests we get from web designers is for flv files because they all claim (or believe) they work better than H264/mp4 files. Spend 15 minutes on the JW Player or Flow Player forums and you’ll see even those well designed, proven players can experience all kinds of problems…usually due to javascript coding errors, but occasionally due to player programming issues.

    But each of those players are constantly updated to fix problems and improve performance and they’ve improved immensely since H264 was first supported in Flash back in 2007. So the player and the coding can make a big difference in playback performance.

    Just as an aside, On2 uses the JW Player for all the video samples on it’s website (which are flv), so even large companies realize the benefit of using a well written commercial player over building it yourself. We’ve had web designers complain about our Carbon Coder generated H264 files (often using Carbon Coder presets)…only for us to place them on a sample webpage using JW Player and they work perfectly from our slow web FTP. But the designers REFUSE to test JW Player or any other commercial player (in place of their player) because they KNOW it will expose problems in their own custom designed players, which is what they’re charging their client to build.

    We’ve also had corporate clients pay through the nose for video delivery using companies like Playstream and others, many of whom don’t even accept H264 files!

    https://www.playstream.com/support/started/files.aspx

    In fact, we’ve dealt directly with at least 3 large video streaming companies that don’t accept H264 (Playstream is just one example). When we asked why, the response on every occasion has been that they don’t work well with their players. When pressed further…the answer always comes back that the players were written several years ago and either don’t support H264, or perform poorly with it. I’m not sure about the “don’t support” answer as I thought the browser side flash plug-in determined whether it could play H264, but these companies either think a custom designed player can’t play H264, or they’ve tested H264 files with their player and had numerous playback and performance problems with them, despite the files using markedly smaller file sizes and data rates than the same video encoded as an flv file.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

  • Chris Blair

    March 2, 2010 at 2:40 am in reply to: Best compression for WEB

    A lot of web designers also custom design their flash players and many of them build bulky code that doesn’t handle mp4/H264 files very well. We constantly get requests from web developers to provide .flv files instead of mp4 for this reason. Poorly coded flash players can do all sorts of weird things when fed H264 files….things like taking forever to load, stuttering constantly on playback even though download speed stays well ahead of playback, sync problems and sometimes refusing to play at all to name a few.

    Never mind that there are half a dozen commercial flash players out there that are proven and handle H264 files extremely well (JW Player and Flow Player come to mind).

    Most of them also offer options to customize the look as well as control virtually everything about them via simple javascript, which is called separate from the Flash player. But many web designers refuse to use them, instead insisting on writing their own control code within the player itself. Which invites problems because there’s so much stuff written into the player itself.

    There’s certainly nothing wrong with hand-coding, but when there are tools out there that cost next to nothing (JW Player and Flow Player are about $50 to license per website) and work great with all Flash compatible file types, it’s just silly to insist on building them from scratch when the results limit the file types you can use.

    The only reason I’ve ever found they do it is because they can bill for it. But we stopped trying to convince them to take H264 and just give them flv files. That said, flv files can look darn good when encoded properly….especially if you have an encoder that can do 2-pass encoding like Flix Pro, which is affordable and produces compact, nice looking flv’s.

    Chris Blair
    Magnetic Image, Inc.
    Evansville, IN
    http://www.videomi.com

Page 22 of 80

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy