וידאו עם HTML-5 מול Flash

בימים האחרונים עולה ברשת שוב הויכוח האם HTML-5 יכול "להרוג" את פלאש מבחינת וידאו.  גם גוגל וגם חברות אחרות נמצאות בתוך הקלחת הזו, אז חשבתי לתרום קצת מנסיוני בתחום הוידאו ולהסביר מס' דברים. במאמר הפעם אני לא אכנס לעניין המקודדים (Codecs)..

בעקרון יש בגדול 2 שיטות לשידור וידאו: שיטה פשוטה ושיטה מתוחכמת.

השיטה הפשוטה היא השיטה שידועה לכולם: לוקחים קובץ וידאו, זורקים אותו לתוך שרת ה-WEB (בין אם זה Apache או IIS), בדף עצמו מטמיעים תוכנת נגן כלשהי (נגן פלאש, Quicktime או Windows Media Player) וכשהמשתמש לוחץ על Play, הנגן מבקש דרך HTTP את קובץ המדיה, הוא מאחסן כמה שניות ומתחיל לפרוס את הקובץ ולנגן אותו תוך כדי שהוא אוגר עוד ועוד וידאו ומנגן אותו. בשיטה זו אתרים פשוטים רבים עובדים (רוב אתרי הפורנו לדוגמא). החסרון בשיטה זו שאם יש איטיות בתקשורת בין שרת ה-WEB לדפדפן שלך, אתה תקבל הרבה הודעות Buffering, והוידאו "יתקע" למשך מס' שניות עד שהנגן יאגור עוד תוכן ורק אז ינגן אותו. חסרון נוסף הוא שאין גמישות מבחינת הקידוד (תיכף ארחיב על כך) והחסרון המשמעותי ביותר: קשה לקבל מידע מפורט כמה זמן משהו נוגן, היכן המשתמש עצר את הוידאו וכו'. היתרון, לעומת זאת, הוא שאין צורך בשרת מיוחד כדי לנגן את הוידאו וכל שרת WEB יוכל להעביר את הוידאו לנגן.

השיטה המתוחכמת היא שיטה שבה משתמשים בשרת מדיה יעודי (כמו Quicktime Server, או Flash Media Server, או Windows Media Services וישנם עוד כמה שרתים כאלו). בשיטה זו לא משתמשים בשרת ה-Web הרגיל אלא משתמשים בשרת מיוחד ובפרוטוקול נפרד (MMS במיקרוסופט, RTSP אצל אפל, Real Network, או RTMP ב-Flash). השימוש בפרוטוקול ובשרת נותנים גמישות רבה יותר. אפשרות לשלוח Bitstream יותר גבוה או נמוך בהתאם למהירות התקשורת של הצד הצופה. אם לדוגמא התקשורת בין שרת המדיה ללקוח גבוהה, אפשר לשדר גירסה עם קידוד ביטים יותר גבוה, ואם מהירות התקשורת באמצע השידור נוחתת, אפשר לשנות מיידית את השידור לגירסה שמתאימה יותר למהירות הנוכחית. אפשר לשלב פרסומת דינמית מותאמת או כל אלמנט טכני אחר באמצע השידור (לדוגמא, החלפת תוכן הדף). אפשר לקבל סטטיסטיקות הרבה יותר מפולחות ומדויקות מי צפה במה וכמה זמן, איך היתה איכות השידור, כמה פעמים הוידאו עצר ועוד ועוד.

סטיב ג'ובס הוא "אנטי" פלאש בגלל כל מיני סיבות והוא דוחף את HTML-5 כתחליף לפלאש, אך התחליף האמיתי בכל הנוגע לוידאו מבחינתו של ג'ובס הוא Quicktime וללקוחות מעוניינים: Quicktime Server (שהמקודדים היוקרתיים שלו עולים כסף), כך שמבחינת אפל, הרווח פשוט יותר גדול כי כך אפשר לעקוף מתחרה ולהרוויח פלח שוק ורווח פיננסי כמובן, אך HTML-5 ותמיכת הוידאו שלו לא עוקפת את מה שיש לפלאש להציע. HTML-5 לא תומך ב-Stream עם מהירות ביטים משתנה, הוא לא תומך בתוכן מוגן, הוא לא תומך בפידבק בחזרה למקרין התוכן ואין בו הרבה דברים למה שפלאש מציע בתחום ניגון הוידאו (ועוד לא הזכרתי את עניין ה-HD). זו הסיבה לדוגמא שיוטיוב לא הולכים מחר לזרוק את Flash לטובת HTML-5. הם יאפשרו ניגון בפורמט HTML-5 אך עדיין ברירת המחדל תהיה פלאש וגוגל מכירים בכך ש-HTML-5 לא יהרוג את פלאש.

לסיכום: HTML-5 בהחלט יכול לעזור בניגון קבצי וידאו פשוטים משרת WEB דרך הדפדפן, אך בשלב זה ל-HTML-5 אין פתרון שמתאים לגופי שידור אינטרנט גדולים כמו Cast-up בארץ, או HULU בחו"ל. פלאש ישאר איתנו זמן רב, גם אם סטיב ג'ובס מתנגד לו.

Comments

comments

12 תגובות בנושא “וידאו עם HTML-5 מול Flash

  1. החודש פורסמה פרצת אבטחה בפלאש. אני עובד עם סביבת 64 ביט, ואדובי החליטו לא לתקן את הבעיה גרסת 64 ביט, אלא במקום להפסיק את התמיכה ב64 ביט.
    מה שיוצר מצב בו אין לי יותר פלאש (מן הסתם הסרתי את פלאש אחרי הבעיה). HTML5 במידה ובאמת יהיה בו שימוש שיועל לכולם, יחייב חברות כמו אדובי להתחרות משהו שלא היה להם עד אז, ותחרות זה דבר שטוב עם לקוחות לא ?

    • אני בהחלט מסכים איתך בנקודות שאתה מציין, ואני לא מציין בפוסט דעה בעד או נגד פלאש אלא רק את העניין של אנשים שחושבים ש-HTML-5 הוא זה שיתן פתרון פתוח של וידאו שיתאים לכולם ומדוע הדבר אינו נכון.

  2. אתה מגבה את המידע שאתה נותן בהוכחות, או סתם זורק מידע לאוויר? ניתן להשתמש ב־Streaming ב־HTML5 Video, ומוזילה למעשה משתמשים בזה בשביל לשדר את הישיבות שלהם בזמן אמת. הוידאו באתר של מוזילה הוא אמנם Ogg Theora, אבל אני לא חושב שיש מניעה משימוש בפתרונות דומים ב־WebM.

    אני לא בטוח לגבי שילוב של DRM למרות שזה בטח אפשרי עם פיענוח הקובץ בצד הלקוח, אבל מאחר ומדובר בשילוב טוב של האלמנט בתוך הדף, אתה יכול לעשות שימוש ביכולות אחרות של הסביבה שאין לך בפלאש, כגון שילוב של כתוביות על קובץ הוידאו. ביוטיוב למשל יש כתוביות, אבל אין שום סיכוי שתצליח להשתמש בהן תחת לינוקס, כי פלאש עצמו לא יודע להציג מלל עברי עדיין.

    • השיטה שמוזילה משדרת את הוידאו היא בשיטה שכתבתי למעלה "השיטה הפשוטה". אין לך אפשרות לשנות את איכות הקידוד בזמן אמת, לדוגמא, בשיטה הזו. אגב, השיטה שהם משתמשים היתה קיימת עוד מ-נטסקייפ 3 כמדומני (בשנת 2000 ניסיתי כמה דברים כאלו עם מצלמת Webcam פשוטה) ואותה "שיטה פשוטה" אפשרית בהחלט עם HTML-5.

      לגבי DRM: אתה תצטרך רכיב יעודי בצורת תוסף. באורנג' לדוגמא משתמשים או ב-ActiveX לאקספלורר או ב-XPI לפיירפוקס. אולי יצליחו לפתח DRM שירוץ בשיטה של JS על דפדפנים עם HTML-5, אבל עדיין חסרים מספר מרכיבים כמו שתיארתי ב"שיטה המתוחכמת".

        • אני מכיר Icecast ואני מכיר גם עוד שיטות לשדר ממצלמה ב-Live בלי Plugins וזו השיטה הפשוטה שהזכרתי. מה ש-Icecast עושה, זה פשוט לבנות קובץ שמשתנה כל הזמן (שידור חי או שידור מוכן מראש של קבצים) ואת זה הוא מזרים, אבל הוא לא יכול לדעת אם מהירות התקשורת שלך ירדה או עלתה ולהציע לך איכות גרועה יותר / טובה יותר בהתאם למהירות התקשורת שלך בשניות אלו.

          • icecast אמנם עובד בפרוטוקול http, אבל אני לא חושב שזה מונע ממנו לשנות את תוכן הקובץ תוך כדי שידור כדי להתאים אותו לצפיה אצל משתמשים מאותגרי רוחב פס. אם הוא היה מתפקד בתור שרת http רגיל, אפשר היה לשים את הקובץ על שרת אפאצ'י רגיל ולסגור עניין.

          • אני חושש שאנחנו מדברים על 2 דברים שונים:
            התקשורת עצמה עם icecast היא "חד כיוונית". אם התקשורת שלך איטית, הוא יפספס כמה פריימים ואז ברגע שיזרום אליו פריים שלם נוסף, הוא יציג אותו (תלוי בקידוד, אם הוא יודע לתמוך ב- I-frame אז תקבל מעבר חלק לפריים שהוא הצליח לתפוס. אם לא, תקבל תמונה גרועה שתשתפר ככל שיהיו יותר פריימים). הוא לא ידע להבחין אם התקשורת שלך חזרה למהירות הרגילה או עוד יותר ירדה, מה שפרוטוקולים כמו RTSP, RTMP, MMS ואחרים נותנים. בנוסף, אני דיברתי ברמת האינדיבידואל ולא ברמה הכללית. בנוסף, הוא צריך לדעת לקודד LIVE בכמה רמות של ביטים וכמדומני ש-Icecast לא תומך בכלל.

          • תומר, לצערי אתה טועה. הנה מתוך הדוקומנטציה של icecast: "ach icecast server can house multiple broadcasts (or mountpoints) each containing a separate stream of content. A 'mountpoint' is a unique name on your server identifying a particular stream – it looks like a filename, such as '/stream.ogg'. A listener can only listen to a single mountpoint at a time. This means you can have a single icecast server contain either multiple broadcasts with different content, or possibly the same broadcast but with streams of different bitrates or qualities. In this case each broadcast or stream is a separate mountpoint." (כאן: http://www.icecast.org/docs/icecast-2.3.1/icecast2_basicsetup.html)

  3. למה אי אפשר לדמות עם ג'אוהסקריפט את אותה פעולה שעושים פלאש וחבריו?
    ניתן לשלוח, במקום קובץ גדול בודד (אפילו אם הוא נוצר תוך כדי השידור), סדרה של קבצים, כשקצב הדגימה בכל אחד בלתי תלוי באחרים, אלא רק במהירות האישורים בשרת. צריך קצת לשים דבק בין כל הדברים, אבל זה אפשרי טכנית.
    כמו כל דבר ב html5: פלאש נותן כלים רבים בהרבה ובשלים מאוד. html5 נותן את הבסיס – אבל את הבסיס הזה ניתן לקחת לכל מיני כיוונים. לכשיהיו מספיק ספריות פיתוח שיעשו מגוון מספיק גדול של פעולות, באותה פשטות שכיום עושים אותן עם פלאש (ואולי אף יותר מכך) – אז נוכל לשפוט לאיזה כיוון הדברים הולכים.

    • הבעיה שעם HTML-5 אין לך גישה ישירה לדברים כמו למדוד את מהירות התעבורה ובתמיכת הוידאו אין לך משוב חוזר. אולי מישהו יבנה דבר כזה, אינני יודע, אך צריך דבר כזה בשביל איכות וידאו מעולה כמו ב-HULU לדוגמא, שלא לדבר על DRM שיהיה קשה לבנות אותו עם JS בשעה שכל דרישה ראשונית של יצרן תוכן הוא שה-DRM יהיה סגור לחלוטין.

      • אני לא כ"כ מבין. את מדידת המהירות בכל מקרה עושים בצד השרת, ולא בצד הלקוח – אז מה זה משנה? בצד שרת תשים איזה שרת שאתה רוצה, בכל אחד ניתן לפתח בקלות שרת שיעשה את העבודה.
        דרך נוספת – שם הקובץ הוא בעצם timestamp של זמן הבקשה. כך יכול השרת לעקוב אחרי הזמן שלוקח לכל בקשה לעבור, וגם לעקוב אחרי הבקשות.
        שורה תחתונה – זה דורש פיתוח, ולפעמים של דברים לא כ"כ טריויאליים. בפלאש – הכל מוכן, לטוב ולרע. כוונתי היא שאתה לא צריך להמציא את הגלגל מחד, אך אתה כבול לדרך עבודה מאוד מסוימת. קוד פתוח בתחום הזה יכול להועיל הרבה מאוד. מתי הקוד הפתוח ישיג את הפלאש אם בכלל? זאת השאלה, ולא כיצד לפתח וליישם דברים כאלו ואחרים. מה שבטוח – לכשיהיה פיתרון פתוח יציב: חזק מחד, וגמיש מאידך, הוא ישאיר מהר מאוד הת הברק מאחוריו…
        לגבי DRM – לאט לאט לומדים איך לחיות גם בלעדיו…

סגור לתגובות.