<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">You can use your swift-proxy to do that automatically. <div><br></div><div>Remo </div><div><br><div><div>On Aug 11, 2014, at 15:06, Brent Troge <<a href="mailto:brenttroge2016@gmail.com">brenttroge2016@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">My CMS folks will not buy into adding more steps to their ingest process. Meaning they will not accept having to create the file segments and corresponding manifest. I will do more reading, hopefully there is some middleware that can make this whole process transparent.<br>
<br>Thanks for your response!<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 12:56 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">inline<br>
<div class=""><br>
On Aug 11, 2014, at 10:38 AM, Brent Troge <<a href="mailto:brenttroge2016@gmail.com">brenttroge2016@gmail.com</a>> wrote:<br>
<br>
><br>
> By default the maximum object size is 5G. Outside of increased replication times, would there be any impacts if I increase that value to 10G? The reason is I have to store upto 10G media files. Using the large file manifest just isnt going to work given Smooth Streaming or Adboe HDS delivery.<br>
><br>
<br>
</div>I'd like to understand more about why a large object manifest (especially the static large objects) won't work.<br>
<br>
But, to answer your question, increasing the max object size can affect the balance of drive fullness. Your drive fullness is directly related to the ratio of the max object size to the size of the drives. Swift places approximately equal numbers of objects on each drive (normalized to the drive weight). This works fine with with large numbers of objects because the hashing splays the object across all drives evenly. So, if you increase the max object size, everything will still work. But you'll need to keep a more careful eye on your capacity planning.<br>
<div class=""><br>
<br>
<br>
> For Apple HLS delivery the media files are stored with a .ts extension. Would that cause any conflicts with tombstone files? Would Swfit mistakenly mark these media files as candiates for deletion? What would happen to a HLS .ts file once it needs to be marked as a tombstone file?<br>
<br>
</div>The logical object name (eg "AUTH_foo/bar_container/some/object/name/here/that/is/long.ts") isn't part of the name used on the local media storage (ie the file on the hard drive). There is zero issue with using a ".ts" suffix for your object names.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--John<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div>
!DSPAM:1,53e9152f87271968467479!
_______________________________________________<br>Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br><br><br>!DSPAM:1,53e9152f87271968467479!<br></blockquote></div><br></div></body></html>