پیشنهاد
amirhoseinbidar opened this issue · comments
میشه فایل ها رو به صورت بایت ذخیره کرد از اونجا که کلا ۴ کارکتر استفاده میشه میشه ۳ بیت اختصاص داد که ۲ بیت برای کارکتر ها و بیت آخر هم برای نشون دادن اتمام فایل استفاده بشه به صورت عادی ترمینال فضای خیلی زیادی نمیگره پس میشه فرض کرد که یه فریم حداکثر ۳۰۰ پیکسل در ۳۰۰ پیکسل بشه
در نتیچه با این فرمت مد نظر ما هر فریم حدودا ۳۲ کیلو بایت میشه که در مقایسه با فرمت تکست که برای هر کارکتر ۴ بایت(یا حتی یک بایت توی فرمت اسکی) جا میگیره خیلی کمتر محسوب میشه
هرچند راهکار هایی میشه داد که بازم حجمش کم بشه ولی فکر کنم کافیه
و به نظرم برای نشون دادن هم اگر یک بافر باشه که مثلا ۱۰۰ فریم اول رو ذخیره بکنه و یه ثرد جدا به عنوان پر کننده بافر لحاظ بشه به احتمال زیاد دیگه مشکل عقب و جلو افتادن صدا و نصویر پیش نمیاد
حتی میشه طول بافر رو با توجه به طول ویدیو تغییر داد فقط ممکنه زمان لود یه مقدار بیشتر طول بکشه که مهم نیست
من سعی کردم این برنامه رو با سی پلاس پیاده کنم ولی با لابیرری اپن سی وی یه مشکل خیلی بد خوردم که بیخیال شدم
سلام.
الان که این پیام رو مینویسم، قابلیت خروجی رنگی به برنامه داره اضافه میشه و مشکلاتش برطرف میشه. بعد از اتمام این بخش، روی کمتر کردن حجم خروجی کار میکنم.
الان نمیشه نظر دقیقی درباره حجم خروجی و سرعت اجرایی بعد از مهاجرت به فریم‌های باینری‌شده داد. یکی از مشکلات اون، مدت زمان وقفه بین هر فریم هست که معلوم نیست ایا میشه با همون سرعت لازم، فریم‌های باینری رو نمایش داد یا که نه. ولی حتما روی این کار میکنم
من یه سری تغییرات دادم که سرعت برنامه به مقدار زیادی خوب شد و دیگه به زبان گو نیازی نیست میشه نمایش برنامه رو با پایتون هم ادامه داد الان مشکل فقط سرعت ترمینال هست که دیگه از دست ما خارج هست که یه ترمینال چقدر سرعت دار تا جایی که من تست کردم رو ترمینال
xterm , ubuntu terminal, terminator
سرعت مناسبی داشت و توی ترمینال اول بهتر از همه بود چون سرعت بالا و کوچیک بودن هر کارکتر باعت میشدکیفیت فریم ها مناسب باشه
کدام
روی فورک خودم تو برنچ
dev
گزاشتم و اینکه یه فکری هم برای پردازش فریم ها دارم که اگه سرعت مناسبی داشته باشه اصلا لازم نیست فریم هارو به فایل تبدیل کرد همون طور که هستن میشه نمایششون داد مسلما مشکل حجم فایل حل میشه