locked
Mp4 files are not playing smoothly RRS feed

  • Question

  • Hi

    I have a 3-months trial subscription and I am planning to use azure media services to host my video content. For testing ,  Here's what I am doing

    1) From long tail video site, I downloaded an MP4 video url which is playing very well on longtail site. 

    Here's the player link where you can see how well its playing in browser using that player. 

    http://www.longtailvideo.com/jw-player/wizard/

    The video url from where I downloaded video is 

    ttp://content.bitsontherun.com/videos/3XnJSIm4-kNspJqnJ.mp4

    2) After download, I rename this video and upload it to media services using Portal's upload function. Then I encoded it to HTML5 video and then I published it. After publishing , I got this url

    https://quanqamedia.blob.core.windows.net/asset-b58375e6-15d2-46f4-b40f-8163d6d27797/longtail.mp4?st=2013-02-27T12%3A00%3A45Z&se=2015-02-27T12%3A00%3A45Z&sr=c&si=d84c6326-9cdf-43dc-9d4c-20ca02893719&sig=YbpxZdLsMiLakLc22GbJqDqpk4i7Hen7AQIRZy5xvQg%3D

    But when I use this url for some player or open it in chrome directly, it plays very slow and strangely. 

    Can anybody guide me in right direction ? What I am doing wrong here ?

    Thanks


    Neeraj Khosla

    Wednesday, February 27, 2013 12:14 PM

Answers

  • Your input MP4 is SD resolution (640x272) encoded at a low bitrate of 400 kbps. The presets currently made available via the portal are tuned towards HD/720p content at higher quality bitrates (few Mbps). Your input video is being scaled to 720p and and encoded at a higher bitrate, hence the size difference.

    We are working on updating the portal to allow you to choose other encode settings, more suitable to your scenario.

    • Proposed as answer by CaptainJackSparrow Tuesday, March 5, 2013 4:32 AM
    • Marked as answer by Mingfei Tuesday, March 5, 2013 9:29 PM
    Tuesday, March 5, 2013 4:32 AM

All replies

  • Neeraj,

    I am seeing similar behavior on my end for that URL.  It downloads 25% and then freezes. 

    What region  is your account quangamedia in?  Are you able to download the MP4 file to your local machine and play it back successfully?  We should rule out first that this specific file is corrupt for some reason.  If you download the file and find that it is corrupt, please log a support incident using the support tab at the top of this page so we can follow up on this immediately.

    Have you already attempted to do a second encode to see if you are able to reproduce the issue? 

    Wednesday, February 27, 2013 3:43 PM
  • Actually Neeraj,

    I finally got Fiddler to download your file. It is very big.

    Fiddler took 6:35 minutes (time to last byte) to download the MP4 completely, and shows that it is 28 MB.

    The original one on the longtail video site (3XnJSIm4-kNspJqnJ.mp4) is only 2.6 MB by comparison and it routes through the jwpcdn.com (which appears to be a CDN cache) which responds in 0.538 seconds on my end (time to last byte). 

    The Preset settings used in the Portal for this particular job are probably too high for your requirements. I would recommend using a lower bitrate preset in code instead of the default portal presets.
    See the list of available presets with their defined bitrates here : http://msdn.microsoft.com/en-us/library/jj129582.aspx#H264Encoding 

    I would recommend one of the multi-bitrate MP4 sets for SD and cellular if you want lower end bitrates. See the details on H264 Adaptive Bitrate MP4 Set SD 16x9 for iOS Cellular Only (which encodes to SD video CBR encoded at 5 bitrates ranging from 1900 kbps to 400 kbps using H.264 Main Profile)  or  if you need single bitrate only try H264 Broadband SD 16x9 which has a bitrate at 2.2 Mbps (which may be too high still for your needs)

    Wednesday, February 27, 2013 3:59 PM
  • HI Neeaj,

    May I know which version of Chrome you are using? If you are using either Chrome 23 or Chrome 24, please try the following and see whether it works:

    You may fix your problem by:

    There is an option in chrome://flags called "Disable hardware-accelerated video decode" enable it.

    https://productforums.google.com/forum/?fromgroups=#!searchin/chrome/mp4/chrome/ilqhiTTZcaY/hkPGA3GK6BIJ

     

    There will be a fix for this.  http://code.google.com/p/chromium/issues/detail?id=163219&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20OS%20Area%20Feature%20Status%20Owner%20Summary

    And if you have Chrome 26, this is fixed in developer version of the browser.

    And this is a bug filed three weeks ago: http://src.chromium.org/viewvc/chrome?view=rev&revision=178906


    Wednesday, February 27, 2013 7:17 PM
  • Hi John

    Thanks for your reply and I really appreciate your time spent in this. 

    I don't think the size should matter, because videos are normally of high size. Whatever the size is, it must be played fine and 28 MB, I don't think is a big size. Even if its encoded at a high preset, it must play smooth. Please correct me if I am wrong here.

    My other question is, Is it necessary to re-encode the video if its already in MP4. I can use FFMPEG to convert my video to MP4. Actually, I am working on something which uses a web based flash recorder to record live stream on wowza server, and then I want to host those files on azure media. Also, Is it possible to convert FLV files to MP4 directly using any encoder available in media services?

    Is there some kind of web based recorder available, which can record directly to media services? If yes, then I can totally skip wowza server and place my files directly to media services ? Presently, I am using red5recorder to record my videos. 

    Thanks

     


    Neeraj Khosla

    Thursday, February 28, 2013 7:53 AM
  • Neeraj,

    The download size was an issue for me with that MP4 when comparing it to the one on longtailvideo.  It does not progressively download fast enough to keep up with playback for me, so it freezes in my video player.  Not sure if that is the same issue that you are seeing above or not.

    To answer your second question - if your file is already encoded as MP4 with H.264/AAC, you don't have to do anything to deliver it as progressive download back to HTML 5 players.  It will just work.  You can just drop it in blob storage and it will work (if you want to enable seeking, you need to set your storage account flags to the right version - there is another thread in this forum on HTML5 playback issues).

    If you want to deliver adaptive streaming formats though (like Smooth or HLS) you still need to encode your files to multiple bitrates.  You can then take advantage of the Dynamic Packaging feature documented here : http://msdn.microsoft.com/en-us/library/jj889436.aspx

    FLV support - no, we don't support FLV as a source file format at this time. See full list of supported codecs and containers here - http://msdn.microsoft.com/en-us/library/hh973634.aspx

    Web based recorder - are you talking about Live here? What are you recording, screen or camera feeds?  We don't support live yet. That is coming later this year.

    Friday, March 1, 2013 10:25 PM
  • Can I jump into this?

    I was fooling around with Azure today and doing MingFei's videos. I went and manually uploaded several files. The MP4 was only 2.6MB but when I converted it to HTML 5 the file grew to 28MB. I don't know what cause that. Should it be this way? HTML should be smaller than MP4, right? Here's snapshot:





    Sunday, March 3, 2013 3:00 AM
  • Your input MP4 is SD resolution (640x272) encoded at a low bitrate of 400 kbps. The presets currently made available via the portal are tuned towards HD/720p content at higher quality bitrates (few Mbps). Your input video is being scaled to 720p and and encoded at a higher bitrate, hence the size difference.

    We are working on updating the portal to allow you to choose other encode settings, more suitable to your scenario.

    • Proposed as answer by CaptainJackSparrow Tuesday, March 5, 2013 4:32 AM
    • Marked as answer by Mingfei Tuesday, March 5, 2013 9:29 PM
    Tuesday, March 5, 2013 4:32 AM