Retiring MP4 Video output



In regards to this announcement:

Am I understanding this correctly, that the REST API will no longer include MP4 URLs in extended entities, leaving m3u8 URLs as the only option?

Wouldn’t this effectively make HTML5 playback impossible for Windows/Linux users? If so, it appears my only option would be to provide a link back to (via the url or exanded_url properties of the entity).

Am I missing something here?



Appears to be a huge pain on Android, not tried iOS yet.

VideoView supports m3u8 format but there doesn’t seem to be any default intents that support that MIME type if you try to pass it to an external app (and this is on Marshmallow or N, let alone earlier versions)


When I paste the .m3u8 URL in my browser, it doesn’t recognize it as a playable file. The .mp4 URL plays just fine. This is Firefox 46.0. Do I need to register an external player for the new .m3u8 URLs?


@Kimik00 Firefox does not natively support HLS playback. You can use an external player such as or use Safari for playback.


It seems that only actual videos currently support variable rate playback. Will GIF videos not also support .m3u8?


@iPlop like you said, for the time being GIFs do not use m3u8 and variable rate. This notice is regarding the actual videos and not GIFs. The behavior of GIFs will remain the same. If in the future we decide to provide variable rate playback for GIFs as well, we will make further announcements.


Oh, so we can still have videos in MP4 format if we strip the audio and upload them as animated GIF? Hmm, maybe I’ll have to look into that :confused:


@Kimik00 Yes, technically it should be possible to get static MP4s that way, but keep in mind that there are tighter restrictions on the allowed file size, resolution and duration on GIFs than regular videos. Also keep in mind the quality loss you might induce by converting videos to GIFs.


I’m trying to understand how this change will work technically, and exactly what the impact will be…

So does this effectively mean the end of embedding Twitter videos on a 3rd party site due to the limited browser compatibility? It would mean that the variants metadata in video tweets would only be useful for iOS and Android apps?

How is going to support HLS on the likes of firefox and chrome without the use of a plugin like flash?

Or are there still going to be something like mp4 streams that will continue to be available only via that retains the broad compatibility (or am I missing some technical solution here)? It appears at the moment that mp4’s are still being used on

Will tweet embeds and timeline embeds continue to support playing video like the main Twitter site?




Thank you for the great questions. We understand there may be some considerations to make with this change and appreciate your time to dig in thoroughly. Here is an overview of the different methods we offer to display media as well as some additional thoughts and answers.

Video on mobile
Both iOS and Android are able to play back HLS video natively. For display within native mobile apps, you might also consider using Twitter Kit, part of our Fabric mobile development tools, to easily render Tweets with video.

Video on web
For display on web, our embedded Tweets, embedded timelines and embedded video tools are the easiest way to display Tweets with video. You can grab an embed code from a Tweet on or use the Tweet URL to integrate it programmatically with the oEmbed API endpoint.

A video in a Tweet can also be easily integrated as a player. You can take advantage of the JavaScript factory function to render a clean, full-bleed video in your page. HLS playback is supported in all embedded products.

Example use of the JavaScript factory function

  '695669511052103680', // The ID of the Tweet containing the video
  document.getElementById('container'), // DOM node of insertion point 
    hideStatus: true

A screenshot of the player that results

Using direct links to HLS
If you are developing a product with a more custom display that cannot be solved with the above options, you should explore 3rd party solutions that play HLS for the browsers you’d like to support. As @cbal mentioned, a great example is DailyMotion’s hls.js open source project.

We hope this is informative and helpful, but please let us know if you have any further questions.

Some direct responses
@johnbarratt - This change does not affect embedding video, Tweets, or timelines on third party sites. We are dedicated to and continually improve our syndication products. All products including currently support HLS for video playback and will work as expected in browsers like Firefox and Chrome.

@bugtrotter - Playback in our embedded products will work on Windows and Linux. If the products above do not fit into your use case and you are using the link in extended_entities, then you should take advantage of a third party player. hls.js may be of interest to you.

@Kimik00 - Firefox is not supporting native playback for HLS. To play HLS video on your site, check out our embedded products or the hls.js project. If you just want HLS to play in Firefox when going to the URL, there are some plugins like mangui/firefox-hls, mentioned in the same thread linked above.

@richardhyland - Definitely check out Twitter Kit as mentioned above, this is the easiest way to get Twitter video in your app.


Thanks for the detailed followup Jon. A few queries on this :

  • The ‘hideStatus’ option isn’t documented in the factory API URL you mentioned, so just wanted to check it is just missing from the current documentation, and it is in fact a fully supported option?

  • Is there a version of this for the html embed using the ‘data-’ value, eg ‘data-hide-status’ or the likes?

  • I have tested out this embed, but it currently loads an insecure image twice (the same one) when loaded on a secure URL (https). This results in loss of padlock in the address bar on the embedding page, and warnings in the console :

    Mixed Content: The page at ‘https://SITE/PATH.html’ was loaded over HTTPS, but requested an insecure image ‘’. This content should also be served over HTTPS. build.min.js:116

(I’d include the exact html I’ve used, but I can’t seem to work out how to embed HTML here and have it display, though it is trivial so you should be able to easily reproduce)

  • FYI, widget.js is loaded over https by using src="//"




Good eye, John :slight_smile: I brought up the same question about ‘hideStatus’ and we’re working to get that in the documentation. It was just added recently for use with ‘createVideo’ and was not published.

I’ll inquire about your other questions regarding data- values and secure URLs.


Thanks Jon, one more thing that we could really use for ‘tweet wall’ like situations is an autoplay option as well for these videos. Tweets autoplay with sound off in your main timeline now on, but there seems to be no way to replicate that with the embedded videos. Or is there another hidden option already that does this? (‘autoPlay’,‘autoStart’ don’t seem to work :frowning: ).




The HLS plays fine on Android - but not in desktop Chrome or Firefox.

If I use the DailyMotion JS, it works on desktop, but not mobile.

If I use the my users have to download 102KB of JS - assuming Twitter isn’t blocked in their location. And I’m not sure how that will work for multiple videos.

Is there a better way of doing things?


Two questions:

  1. Am I right in thinking that, once this change happens, there will be no way to get the URL of the actual video file via the API? For example, if I wanted to use the API to download copies of videos I’ve tweeted, it sounds like it will be very difficult / impossible if I can only access the HLS stream… or have I missed something?

  2. Is the MPEG-Dash URL remaining? (I’m not 100% sure what that’s used for, but I was just curious if it’s changing.)


Does this affect Twitter player cards which link to mp4 videos and do those also need HLS formatted video links?


I’m currently having a problem with the embedded timeline videos. None of the Twitter videos are playing. The message I receive is “This browser does not support video playback” for videos that previously played. This change, Retiring MP4 Video Output, which seems to already have happened, is affecting every video in my companies Twitter Timeline. We’re using IE11 / Win 7 platform and using Chrome as the standard is not an option. There are several hundred thousand employees, each with a computer and it takes significant time to make a browser change. When I review the videos source code, I see the .M3U8 file. I’m not sure how to resolve this issue. Any feedback to help would be greatly appreciated.




@cbal I’m sorry but I’m not sure if I understand well. I’m currently uploading mp4 videos to twitter with TwitterKit.
When you say MP4 URL will be removed, it means when you tweet a URL or even if the video is created within an app and then uploaded to twitter in MP4 format?
I’m sorry but I don’t really understand if MP4 will not be supported at all or not…

Thanks for your help.

(Edited to remove username mentions - don’t do that unless responding specifically to someone, since not everyone has the same skills or time to reply)


@ChallengeBoom You’ll still be able to upload MP4 videos to Twitter. Well, they haven’t said you won’t be able to, but the API docs don’t mention which formats are OK. And the docs for uploading via Twitter apps and website say:

We currently support MP4 and MOV video formats on mobile apps.

On the web, we support the MP4 video format with H264 format with AAC audio. You can upload videos up to 512MB, however you will be prompted to edit videos to 30 seconds or less in length.

What they’re saying is that if you request the data about a Tweet from the API, there is currently a URL for a video in MP4 format. That URL will be disappearing from 1st August 2016. So to access a video (no matter what format the original uploaded video was) you should use the .m3u8 URL for a streaming version.

If you “tweet a URL” to an MP4 video that won’t change - it’s just a link to a video, not a video attached to the tweet and uploaded to Twitter.


@philgyford Thanks a lot for your help. Really appreciate it!
I understand much better now, thanks a lot for taking the time to clear my doubts! :slight_smile: