Log in

View Full Version : Google Video unveiled (or how to do everything with free tools)


bond
29th January 2006, 16:26
just had a look at what kind of files are offered at google video
i only checked out the free samples, so i have no idea what you get when you pay (propably the same at higher bitrates?)

google video actually lets you download three kinds of videotypes:
1) "windows/mac"

when you choose this you can download a .gvp file, which itself points to a plain .avi file
the avi file contains a mpeg-4 asp stream, encoded with libavcodec (2 b-frames, no qpel, no gmc, h.263 quant), and an mp3 audio stream produced with lame
the avi files (also sometimes spead with the .gvi extension) have a strange "goog" chunk at the beginning, which borks the m$ dshow avi splitter (works with virtualdub and haali media splitter tough)

2) "video ipod"

when you choose this you can download a .mp4 file
the .mp4 contains an avc stream encoded with x264 with the following settings:
cabac=0 ref=1 deblock=1:0:0 analyse=0x1:0x10 me=dia subme=1 brdo=0 mixed_ref=0 me_range=16 chroma_me=0 trellis=0 8x8dct=0 cqm=0 chroma_qp_offset=0 slices=1 bframes=0 keyint=60 keyint_min=25 scenecut=40 pass=2 bitrate=500 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=22 qpmax=51 qpstep=2 cplxblur=20.0 qblur=0.5 vbv_maxrate=700 vbv_bufsize=350 ip_ratio=1.40 Baseline@1.3 320x240 target bitrate seems to always be 500kbps
there is also an aac audio stream produced with faac
the mp4 muxer used was mp4box

3) "sony psp"

when you choose this you can download a .mp4 file
the .mp4 contains an avc stream encoded with x264 with the following settings:
cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0x111 me=hex subme=5 brdo=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 chroma_qp_offset=0 slices=1 bframes=0 keyint=250 keyint_min=25 scenecut=40 pass=2 bitrate=500 ratetol=1.0 rceq='blurCplx^(1-qComp)' qcomp=0.60 qpmin=10 qpmax=51 qpstep=2 cplxblur=20.0 qblur=0.5 ip_ratio=1.40 Main@5.1 320x240target bitrate seems to always be 500kbps
there is also an aac audio stream produced with faac
the mp4 muxer used was mp4box
afterwards the proprieatary atoms, braindead sony requires for the crappy psp, have been added to the mp4 with an unidentifyable tool

all in all google seems to love using L/GPL software :D

also google seems to want the ipod files to have less quality than the psp ones (or the files have been encoded by different departments where one hand doesnt know what the other one is doing) :D

sterlina
30th January 2006, 01:30
:thanks: Bond


I think that's normal Google uses free software, because they have to cut-off all expenses... and because free software is often better than commercial one :rolleyes:

anyway I'm feeling somewhat displeased that Google doesn't tell anywere in their site which program do they used... :( do you (all) think that it is possible to ask?


: ster :

Sirber
30th January 2006, 03:58
I think it's strange iPod profile use me=dia subme=1...

damrod
30th January 2006, 04:22
for the psp...i suggere atomchanger ...it's the only tool i know to patch a correct mp4 file to work on the psp (firmware 2.5 for me...i can read mpeg4/avc :-))

i encode my mp4/psp with x264 and faac so i think they do the same...

i wonder if they provide the thumbnail file with the video?? the hmt (in fact a jpeg) wich will be display in the psp file browser...

the resize 320*240 is standard for psp...not very practical for non 4/3 source (you will have a sort of zoom...) but nonetheless it's a good quality provided by google i think (if you play the video avc/500k encoded in 2/3 passes with high quality mode you have a good result on a 17p computer screen..ok the res is small...but even in fullscreen it's good)

*.mp4 guy
30th January 2006, 09:48
Those settings are a little odd. Why wouldn't they be using multi-hex and rdo-6 ME. I don't see how It could have anything to do with encoding time since X264 is multi-threaded and their encoding at 320*240.

bond
30th January 2006, 11:34
Those settings are a little odd. Why wouldn't they be using multi-hex and rdo-6 ME. I don't see how It could have anything to do with encoding time since X264 is multi-threaded and their encoding at 320*240.they use only one thread

foxyshadis
31st January 2006, 07:21
For win/mac, what is the res and bitrate?

*.mp4 guy
1st February 2006, 13:15
they use only one thread
I realize that, I just meant that for a company like google encoding speed of a multithreaded program can't be a real issue unless they don't know what they are doing.

Elias
2nd February 2006, 13:47
Hmmm... any link to download these Google Video tools?

bond
7th February 2006, 17:07
How is the aac encoded? It looks to be vbr 48khz.libfaac

BlindWanderer
17th February 2006, 19:34
If i were guessing, i'd say there were using VLC, since the at one point submitted a patch so VLC could play FLV.

Oh and if you want an avi or mpeg instead of FLV...
a greasemonkey script i found.
No it doesn't show any secrets, just access element included in the page that are visible in browsers that don't support javascript (like OB1 (http://www.OffByOne.com)).

// ==UserScript==
// @name Google Video AVI/MPEG Downloader
// @namespace http://www.joshkinberg.com/
// @description Provides download links for video files hosted by Google Video in its source format (avi/mpeg/etc..)
// @include http://video.google.*/*
// ==/UserScript==

// This is just a little modification from Joshua Kinberg script to donwload videos in FLV

// Get macdownloadlink URL

var downloadLink = document.getElementById('macdownloadlink');

// add banner with download link

var my_banner = document.createElement("div");
my_banner.innerHTML = '<div style="float:right; width: 130px; border: 2px solid #CCCCCC; margin-bottom: 10px; font-size: small; background-color: #0000FF; color: #FFFFFF;">' +
'<p style="margin: 5px;text-align:center;">' +
'<a href="' + downloadLink + '" style="color:#FFFFFF; font-weight:bold; font-size:10px;">Download Video</a>' +
'</p></div>';
document.getElementById('pvprogtitle').insertBefore(my_banner, document.getElementById('pvprogtitle').firstChild);

Razorholt
19th July 2006, 15:37
Bond,

What tool(s) did you use to find out about their settings?

Thanks,
- Dan

foxyshadis
19th July 2006, 16:54
Everything encoded with x264 (or libx264) includes an option string in the file's header. You can open any file with a hex editor (or text editor) to check it out. Neat, huh?

Razorholt
20th July 2006, 01:58
Very! Thanks foxyshadis

uray
15th August 2006, 15:54
does google until now still use x264 rev 380?

does anyone knows why google doesn't provide x264 encoded video for windows with higher encoding spec, like RDO, level 2 trellis, > 1 ref frame, 8x8dct, multihex subme... IMHO they should since it will increase quality or reduce data size...

check
16th August 2006, 02:19
CPU time required would be my guess. They host a *lot* of videos on there, using settings that much higher would significantly increase their CPU requirements.

adoniscik
5th September 2006, 15:36
Is it possible to avoid recompression upon uploading?

KoD
11th September 2006, 19:36
Aren't L/GPL licenses too restrictive to be used by Google ? After all, Google does charge for some services... And even if they wouldn't charge, since they use it in an application they would have to make the source code for that application available or something like that ? Not to mention ther is no word nothing on their website of what they are using for encoding.

Geek Squad
11th September 2006, 21:42
I thought Google used Divx 4 codec?

And their target bitrate is 800 kbps. An employee from Google even said that (I talked with him).

Windows Mac resolution 640 by 320 and target bitrate of 800 kbps, although it varies based on source material.

--
http://www.gvhighlights.blogspot.com

Sulik
12th September 2006, 03:30
No matter what, the final delivery is Flash. Who cares what Google uses internally to store the videos (might as well be uncompressed if they have the disk space & bandwidth)

Geek Squad
18th September 2006, 00:06
The final delivery is not only flash, its also Divx 4 .avi, and two versions of MPEG-4...

temporance
20th September 2006, 10:23
The licensing side of this could be interesting. Google would have to comply with x264's GPL license, which should be easy if they do not distribute binaries outside of the company.

On patents: Google should be paying MPEG-LA, Via and whoever else claims patents on MPEG-4 and H.264 formats. The x264 encoder may unintentionally violate other patents too. If I owned patents on H.264 encoding, I would check the x264 source for violations and if I found them, I would set my lawyers onto Google.

As to the interaction between patents and GPL - it's probably not an issue for Google so long as they do not distribute binaries. They can pay royalties to MPEG-LA etc. without conflicting with GPL.

IANAL

GodofaGap
20th September 2006, 10:38
GPL is not a license that determines how a product can and cannot be used. It only sets the terms for redistribution of source code and binaries. Nothing more.

Or to quote the GPL license:

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.

KoD
20th September 2006, 12:33
Actually, I believe GPL is more of a trap than it looks like. Otherwise it wouldn't be called GPL, LGPL or anything else but it would be simply public domain.

I still remember something about "if your program uses a GPL library, and its use is significant", as if significant is actually a quantifiable term... I'm not very knowledgable about these things though, but my inner senses tell me it sounds like a trap.

GodofaGap
21st September 2006, 15:50
It is a trap for source code: once GPL it cannot be any other thing but GPL. But again GPL does not have *any* restrictions on the *usage* of the binaries.

joseph5
2nd December 2006, 19:03
Ipod Video and PSP are in the same option.

bond
2nd December 2006, 19:39
Ipod Video and PSP are in the same option.seems they realised that mp4 = mp4 ;)