<div dir="ltr"><div><div>Hello Alex and Clay,<br><br></div>Pardon my jumping in here, we do something similar and have a similar use case (we chose 1MB segments for mobile, and 10MB segments for desktop).  One question I have in comparing copy/bulk-delete vs keeping the manifest around is what is the overhead of the manifest within swift for retrieval (both DLO and SLO use case)?  My understanding is that in the DLO case, the listing is kept in the container, and that in the SLO case the manifest is a file in swift itself.  In both cases an extra write/read is necessary to store/lookup the manifest, and in the case of SLO it will in the containerdb ring (often SSD), and in the case of DLO it would be in the object ring (HDD).  Is my understanding correct?<br><br></div>Thanks,<br><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:Calibri,sans-serif"><span><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(102,102,102);font-weight:700;vertical-align:baseline;white-space:pre-wrap">Michael Yoon</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap">Chief Technology Officer</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap">m.718.791.8670</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(17,85,204);vertical-align:baseline;white-space:pre-wrap"><a href="mailto:michael.yoon@mimedia.com" target="_blank">michael.yoon@mimedia.com</a></span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap">MiMedia, Inc.</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap">32 Court St. Suite 1800</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap">Brooklyn, NY 11201</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10.6667px;font-family:Arial;color:rgb(153,153,153);vertical-align:baseline;white-space:pre-wrap"><img src="https://lh5.googleusercontent.com/C1jnp0YF_jkHTQta20T0e63BFjvMWeGLOxEbSe1pREDRFvtbcFSss31PgoO4pHEunr3-3HFXh4peW6-lYd9uyca9oocsLuldH74pooVSvpSVlecyNSMm0QB1YpFAKGJ6G_MFi7c5" style="border:none" width="181px;" height="75px;"></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="text-decoration:none;font-size:10.6667px;font-family:Arial;color:rgb(0,159,158);vertical-align:baseline;white-space:pre-wrap"><a href="http://mimed.io/r/23C03YR" style="text-decoration:none" target="_blank">Sign up! First 10 GB are on us.</a></span></p></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Sep 13, 2016 at 5:18 PM, Alexandr Porunov <span dir="ltr"><<a href="mailto:alexandr.porunov@gmail.com" target="_blank">alexandr.porunov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thank you Clay!</div><div><br></div><div>I use ffmpeg with remote input and local output for first convertion. Here is a simplified algorithm: </div><div>1. Convert with h264 in the highest quality (till 4K) and save it in a transformer server.</div><div>2. Convert into lower quality locally. And get additional data (thumbnails and so on).</div><div>3. Upload all converted videos and additional data into Swift (as you suggested with sub-segments and segments).</div><div><br></div><div>Compressed videos then are available to the client throug the transmuxing servers.</div><div><br></div><div>Best regards,</div><div>Alexandr</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 13, 2016 at 8:55 PM, Clay Gerrard <span dir="ltr"><<a href="mailto:clay.gerrard@gmail.com" target="_blank">clay.gerrard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Sep 13, 2016 at 10:37 AM, Alexandr Porunov <span dir="ltr"><<a href="mailto:alexandr.porunov@gmail.com" target="_blank">alexandr.porunov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Correct me if I am wrong. Algorithm is the next:</div><div>1. Upload 1MB sub-segments (up to 500 sub-segments per segment). After they will be uploaded I will use "copy" request to create one 500MB segment. After that I will delete useless 1MB segments.</div><div>2. Upload up to 240 segments with 500MB and create a manifest for them. </div><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Is it correct? Will this algorithm be suitable for this situation?</div><div><br></div></div></blockquote><div><br></div></span><div>That sounds correct - I think the COPY/bulk-delete is optional - you could also just have the top level SLO point to the sub-segment SLO's manifest directly and leave all of the 1MB chunks stored in Swift as is - could potentially help smooth out the evenness of diskfullness overall.  I think 1MB is big enough to smooth out any connection overhead - but you could test with COPY consolidation of the backend subsegments to objects too.</div><div><br></div><div><div>Whatever works.</div></div><div><br></div><div>Regardless it'll still take awhile to download a 120GB object.  <br></div><div><br></div><div>Do you stream the uncompressed videos directly into the encoder as you upload the compressed format - or stage to disk and re-upload?  What about the playback of compressed videos - mp4 should http-pseudo stream directly to an html5 browser just fine!?</div><div><br></div><div>Cool use case!  Good luck!</div><span><font color="#888888"><div><br></div><div>-Clay</div><div><br></div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>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" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack</a><br>
<br></blockquote></div><br></div></div></div>