আমি সত্যিই বিশ্রামের স্ট্রিমিং সম্পর্কিত সামগ্রীগুলি পরিচালনা করতে পরিচালনা করি নি - মনে হয় ফলাফলগুলি বেশিরভাগই অন্য কোনও পরিষেবায় স্ট্রিমিং দেওয়ার বিষয়ে (যা কোনও খারাপ সমাধান নয়)। সুতরাং আমি নিজেই এটি মোকাবেলায় যথাসাধ্য চেষ্টা করব - নোট করুন যে স্ট্রিমিং আমার ডোমেন নয়, তবে আমি আমার 2 সেন্ট যোগ করার চেষ্টা করব।
স্ট্রিমিংয়ের দিক থেকে, আমি মনে করি যে আমাদের সমস্যাটি দুটি স্বতন্ত্র অংশে আলাদা করতে হবে:
- মিডিয়া রিসোর্সে অ্যাক্সেস (মেটা ডেটা)
- মাঝারি / স্ট্রিম নিজেই অ্যাক্সেস (বাইনারি ডেটা)
1.) মিডিয়া সংস্থানগুলিতে অ্যাক্সেস
এটি বেশ সোজা and এবং এটি একটি পরিষ্কার এবং বিশুদ্ধ উপায়ে পরিচালনা করা যেতে পারে। উদাহরণ হিসাবে বলা যাক যে আমাদের একটি এক্সএমএল-ভিত্তিক এপিআই থাকবে যা আমাদের স্ট্রিমগুলির একটি তালিকা অ্যাক্সেস করার অনুমতি দেয়:
GET /media/
<?xml version="1.0" encoding="UTF-8" ?>
<media-list uri="/media">
<media uri="/media/1" />
<media uri="/media/2" />
...
</media-list>
... এবং স্বতন্ত্র স্ট্রিমগুলিতে:
GET /media/1
<?xml version="1.0" encoding="UTF-8" ?>
<media uri="/media/1">
<id>1</id>
<title>Some video</title>
<stream>rtsp://example.com/media/1.3gp</stream>
</media>
২) মাঝারি / স্ট্রিমের অ্যাক্সেস নিজেই
এটি আরও সমস্যাযুক্ত বিট। আপনি ইতিমধ্যে আপনার প্রশ্নের একটি বিকল্প চিহ্নিত করেছেন এবং তা হ'ল একটি RESTful API এর মাধ্যমে স্বতন্ত্রভাবে ফ্রেমে অ্যাক্সেসের অনুমতি দেওয়া। যদিও এটি কার্যকর হতে পারে, আমি আপনার সাথে একমত যে এটি একটি কার্যকর বিকল্প নয়।
আমি মনে করি যে এর মধ্যে একটি পছন্দ করা উচিত:
- বিশেষ স্ট্রিমিং প্রোটোকল (যেমন আরটিএসপি) এর মাধ্যমে একটি উত্সর্গীকৃত পরিষেবাতে স্ট্রিমিং সরবরাহ করা
- HTTP- তে উপলব্ধ বিকল্পগুলি ব্যবহার করে
আমি বিশ্বাস করি প্রাক্তনটি আরও দক্ষ পছন্দ হতে পারে যদিও এর জন্য একটি ডেডিকেটেড স্ট্রিমিং পরিষেবা (এবং / অথবা হার্ডওয়্যার) প্রয়োজন requires এটি RESTful হিসাবে বিবেচনা করা হয় এর প্রান্তে কিছুটা হতে পারে তবে নোট করুন যে আমাদের এপিআই সমস্ত দিক থেকে বিশুদ্ধ এবং যদিও উত্সর্গীকৃত স্ট্রিমিং পরিষেবাটি অভিন্ন ইন্টারফেসের সাথে সম্মতি দেয় না (GET / POST / PUT / DELETE), আমাদের API আছে। আমাদের API আমাদের GET / POST / PUT / DELETE এর মাধ্যমে সংস্থানসমূহ এবং তাদের মেটা ডেটার উপর যথাযথ নিয়ন্ত্রণের অনুমতি দেয় এবং আমরা স্ট্রিমিং পরিষেবাটিতে লিঙ্ক সরবরাহ করি (এভাবে REST এর সংযোগের দিকটি মেনে চলি)।
পরবর্তী বিকল্প - এইচটিটিপি এর মাধ্যমে স্ট্রিমিং - উপরের মতো দক্ষ নাও হতে পারে তবে এটি অবশ্যই সম্ভব। প্রযুক্তিগতভাবে, এটি HTTP- র মাধ্যমে কোনও বাইনারি সামগ্রীতে অ্যাক্সেসের অনুমতি দেওয়ার চেয়ে আলাদা নয়। এক্ষেত্রে আমাদের এপিআই এইচটিটিপি-র মাধ্যমে অ্যাক্সেসযোগ্য বাইনারি সংস্থার একটি লিঙ্ক সরবরাহ করবে এবং সংস্থানটির আকার সম্পর্কেও আমাদের পরামর্শ দেবে:
GET /media/1
<?xml version="1.0" encoding="UTF-8" ?>
<media uri="/media/1">
<id>1</id>
<title>Some video</title>
<bytes>1048576</bytes>
<stream>/media/1.3gp</stream>
</media>
ক্লায়েন্টটি HTTP ব্যবহার করে রিসোর্সটি অ্যাক্সেস করতে পারে GET /media/1.3gp। ক্লায়েন্টের পুরো সংস্থানটি ডাউনলোড করার জন্য একটি বিকল্প হ'ল - এইচটিটিপি প্রগতিশীল ডাউনলোড । ক্লিনারের পক্ষে এইচটিটিপি রেঞ্জ শিরোনাম ব্যবহার করে সংস্থাগুলিতে রিসোর্স অ্যাক্সেস করার জন্য একটি ক্লিনার বিকল্প হবে । 1MB বড় ফাইলের দ্বিতীয় 256KB অংশ আনার জন্য ক্লায়েন্টের অনুরোধটি এর পরে দেখতে হবে:
GET /media/1.3gp
...
Range: bytes=131072-262143
...
একটি সার্ভার যা রেঞ্জগুলিকে সমর্থন করে তারপরে কন্টেন্ট-রেঞ্জের শিরোনামের সাথে প্রতিক্রিয়া জানাবে এবং তারপরে সংস্থানটির আংশিক প্রতিনিধিত্ব করবে:
HTTP/1.1 206 Partial content
...
Content-Range: bytes 131072-262143/1048576
Content-Length: 1048576
...
মনে রাখবেন যে আমাদের এপিআই ইতিমধ্যে ক্লায়েন্টকে ফাইলের সঠিক আকার বাইটস (1 এমবি) বলেছিল। এমন ক্ষেত্রে যেখানে ক্লায়েন্টটি সংস্থানটির আকার জানবে না, আকার HEAD /media/1.3gpনির্ধারণের জন্য প্রথমে কল করা উচিত , অন্যথায় এটি সার্ভারের প্রতিক্রিয়াটিকে ঝুঁকির মধ্যে ফেলেছে 416 Requested Range Not Satisfiable।