[gst-devel] youtube on gstreamer

Mon May 11 14:40:11 CEST 2009

Ebin,

On Mon, May 11, 2009 at 4:42 AM, ebin jose <ebinjosetel at gmail.com> wrote:
> Hi Sean,
>
> Thanks for a quick reply.
> I am not sure if I made myself clear.
>
> Our mediaplayer doesn't have a web browser.

You shouldn't need a web browser in either case - it's entirely
possible to write a SWF player that is not a browser plugin. It's even
been done before - Gnash. Decouple the idea of Flash/SWF from web
browser. The two are only coincidentally mixed together due to the
popularity of the Flash browser plugins.

> So the proposed application (like a standalone application), should actually
> access "youtube.com" website and get the media urls (I am still not sure how
> to get it) and gstreamer should then play it back. This is the whole idea.

Yes. Based on my limited understanding of Youtube's published
programmer APIs, they enable you to do the following:

1. Let the user search the website and get a list of video URLs as a result.
2. Browse videos with YouTube Channels.
3. Enter comments on videos.
4. Authenticate a user and upload content, such as new videos.

My understanding is that, if you were to obtain the YouTube Player SWF
and initialize it with the parameters to play a video, this does not
violate YouTube's TOS. I don't believe this is content scraping as
defined by Julien. Furthermore, you can get legally licensed
implementations of the requisite codecs from Fluendo or maybe even the
"upstream" owners of each format, whoever they are. This would be the
robust, legally correct way to go. If you are planning a commercial
product, you should contact an official YouTube representative (i.e.,
not me!) to verify my claims -- IANAL.

>
> In such a case, I will be playing back SWF or FLV ? sorry I am confused.

This is a question *you* must ask. The answer is: you are technically
able to use either solution. The way YouTube is designed right now,
you have a choice to make.

If you go the SWF route, you have the additional challenge of
licensing and/or implementing not only the media codecs, but a SWF
player. You don't need a browser for that (!) and this is a much safer
route legally. However, be prepared to pay quite a lot in license fees
to get the proper licenses on these patent-encumbered media formats.

If you go the FLV route, you're already violating the YouTube TOS
(well, almost certainly anyway), so you might as well not license your
codecs, either :) If you're going rogue you might as well go
completely rogue, you know? So in this case you pay $0, you already
have working implementations of the formats in gst-plugins-* and
gst-ffmpeg, and not to mention it's very easy to scrape the FLV URL.

Now, if your next question is "how do I scrape the FLV from a
video_id?" -- I respond simply with the word Google, as that's not
only off-topic but facilitating a legally questionable pursuit.

>
> I haven't really read the youtube TOS. Do you think this idea is against the
> TOS ?

If you are doing anything more than a very small-scale (i.e. just you)
hobby project, I think you should read the *entire* YouTube TOS, or at
least have your lawyer read it, and become 100% sure that you and your
coworkers (if any) are explicitly aware of any design decisions you
make in the way of integrating with YouTube.

Best,

Sean

>
> Thanks,
> Ebin.
>
>
> On Mon, May 11, 2009 at 12:39 PM, Sean McNamara <smcnam at gmail.com> wrote:
>>
>> On Mon, May 11, 2009 at 2:35 AM, ebin jose <ebinjosetel at gmail.com> wrote:
>> > Hi All,
>> >
>> > Has anybody worked on playing back youtube videos on gstreamer ?
>>
>> Playing Youtube SWF files from your own website, etc. is probably fine
>> (many sites embed Youtube SWFs), and really the only high road. If you
>> can get Gstreamer to do that, have at it, but I'm not sure which
>> codecs you'd need to have installed to do that, if indeed it's
>> possible at all. Your next best bet to play the SWFs would be Gnash
>> (which uses Gstreamer internally a lot).
>>
>> However, there have been reports[1] that Youtube goes after (and tries
>> to shut down) people who directly download and stream their FLV or MP4
>> files. It's fairly easy to introspect the results of an HTTP GET
>> youtube.com/watch?id=foo and build a URL that will get you an FLV
>> (which plays in gstreamer with the correct codecs), but that may
>> violate Youtube's terms of service.
>>
>> "Can do" versus "Should do" -- it's your call, the same with the ugly
>> plugins.
>>
>> [1]:
>> http://www.techcrunch.com/2009/02/13/youtube-kills-our-video-download-tool/
>>
>> >
>> > I am new to youtube apis also.
>> >
>> > We have a portable media player (arm based) with wifi connectivity. We
>> > are planning to add an application which can playback youtube
>> > contents.
>> >
>> > Background:
>> > - Our player is running linux on an ARM based platform.
>> > - mediaplayer uses gstreamer as playback engine.
>> > - the complete code (apart from gstreamer) is in C.
>> >
>> > I have the following questions:
>> > 1) I am planning to use youtube DATA APIs (java ones) to retrieve the
>> > urls from different categories of videos in youtube;
>>
>> I briefly investigated the data APIs myself, and I couldn't see how to
>> get URLs to actual video datastreams (the FLV or MP4 files). If it
>> isn't in Youtube's declared API, then it probably isn't something they
>> want you to do.
>>
>> >
>> > I belive once I have the media url, I can just give it to gstreamer and
>> > it
>> > will play it back.
>>
>> As stated above, if you're getting an .FLV or .MP4 file, it will
>> "work" in Gstreamer given the proper codecs (which are known to work
>> with the correct combination of gst-plugins-good|bad|ugly) but you
>> need to watch out for a potential TOS violation. If you're getting an
>> SWF file, then I would presume that Youtube is happy, as that's
>> basically encapsulation of their ad content and so forth, which is
>> exactly what they want.
>>
>> > I believe this is a right way of doing it. Please comment if this
>> > belief is wrong ?
>> >
>> >
>> > Thanks in advance.
>> > Ebin.
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> > production scanning environment may not be a perfect world - but thanks
>> > to
>> > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> > i700
>> > Series Scanner you'll get full speed at 300 dpi even with all image
>> > processing features enabled. http://p.sf.net/sfu/kodak-com
>> > _______________________________________________
>> > gstreamer-devel mailing list
>> > gstreamer-devel at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
>> i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK
> i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>