Open Stack

On Tue, Sep 13, 2016 at 10:37 AM, Alexandr Porunov <
alexandr.porunov at gmail.com> wrote:

>
> Correct me if I am wrong. Algorithm is the next:
> 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.
> 2. Upload up to 240 segments with 500MB and create a manifest for them.
>
>
Is it correct? Will this algorithm be suitable for this situation?
>
>
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.

Whatever works.

Regardless it'll still take awhile to download a 120GB object.

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!?

Cool use case!  Good luck!

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160913/b5fc7b8d/attachment.html>