Invisible <voi### [at] devnull> wrote:
> >> ...they have tutorials now? ._.
> > 
> > <sigh> Do you think that everyone else just somehow managed to intuit 
> > the proper settings?

> Well yeah, presumably.

> I mean, TMPGEnc doesn't come with a manual or any tutorials either, and 
> most people manage to figure that out. Ditto for Virtual Dub...

  You know, there's this thing called "Google". Ever tried that?

-- 
                                                          - Warp

Post a reply to this message

Gail wrote:

> It may not come with it, but that doesn't stop people who have wored 
> things out to write tutorials for all the people who can't or who don't 
> want to fiddle for days to get a good result.
> If you're wondering how to do something, ask google. Chances are, 
> someone has done it before and will have written up something explainig 
> how.

I guess I just assumed that if something doesn't come with any 
instructions, it's supposed to be "obvious" enough that you don't need them.

At the time, I was only really trying out various codecs. The general 
conclusion I reached is that every codec known to man produces some 
degree of visible distortion, so it's best to store everything fully 
uncompressed, only encoding it when writing to DVD. Basically I only 
ever play video on my PC or on a DVD; I've never tried to put video onto 
the Internet before.

I decided that for lossy encoding, MPEG1 is good enough. (And has the 
advantage that absolutely everything can play it, and there's a nice, 
free, fairly usable encoder available.)

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:490ad8c2$1@news.povray.org...
> Gail wrote:
>
>> It may not come with it, but that doesn't stop people who have wored 
>> things out to write tutorials for all the people who can't or who don't 
>> want to fiddle for days to get a good result.
>> If you're wondering how to do something, ask google. Chances are, someone 
>> has done it before and will have written up something explainig how.
>
> I guess I just assumed that if something doesn't come with any 
> instructions, it's supposed to be "obvious" enough that you don't need 
> them.

No. You assume that it should be obvious.
Most other people I know (myself included) would go looking for some 
assistance (whether it be asking someone or searching online)

Post a reply to this message

Gail wrote:

>> I guess I just assumed that if something doesn't come with any 
>> instructions, it's supposed to be "obvious" enough that you don't need 
>> them.
> 
> No. You assume that it should be obvious.
> Most other people I know (myself included) would go looking for some 
> assistance (whether it be asking someone or searching online)

Well, the encoder _did_ work. It just produced very bad quality 
pictures. I assumed it was just a naff codec, and continued my 
explorations elsewhere. (At the time I'd never heard of it before, so I 
figured that was because it's not very good.)

I do recall spending 4 days trying to get a codec called "cinepak" to 
work well - and when I mentioned it online, somebody said "OMG, do you 
have *any idea* how ancient that thing is? Get rid of it!" I guess I 
assumed that DivX must be similar, so I didn't spent too many hours 
trying to fix it.

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:490adb53@news.povray.org...

> I do recall spending 4 days trying to get a codec called "cinepak" to work 
> well - and when I mentioned it online, somebody said "OMG, do you have 
> *any idea* how ancient that thing is? Get rid of it!" I guess I assumed 
> that DivX must be similar, so I didn't spent too many hours trying to fix 
> it.

You seem to often make assumptions based on insufficient information. Don't. 
Investigate, verify, confirm for yourself. The tools needed are there, it's 
not hard.
You do your reputation no good if you make an assumption that 2 min or less 
with google will show to be completely false.

Post a reply to this message

Gail wrote:
> 
> "Invisible" <voi### [at] devnull> wrote in message 
> news:490adb53@news.povray.org...
> 
>> I do recall spending 4 days trying to get a codec called "cinepak" to 
>> work well - and when I mentioned it online, somebody said "OMG, do you 
>> have *any idea* how ancient that thing is? Get rid of it!" I guess I 
>> assumed that DivX must be similar, so I didn't spent too many hours 
>> trying to fix it.
> 
> You seem to often make assumptions based on insufficient information. 
> Don't. Investigate, verify, confirm for yourself. The tools needed are 
> there, it's not hard.
> You do your reputation no good if you make an assumption that 2 min or 
> less with google will show to be completely false.

You look at your PC. You have half a dozen codecs available. Which ones 
are you going to spend most time investigating? The ones you've never 
heard of? Or the ones you've heard about that are supposed to be good? 
Where are you going to spend the most effort?

Also... You make it sound like Google is some magical Oracle that will 
instantly answer any possible question. This is not actually the case. 
Google works very well for certain questions, and drastically less well 
for certain other questions. Sometimes it can take hours of hunting to 
get a useful answer out of Google. (Though probably not for the specific 
case in question.)

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:490ae0c2$1@news.povray.org...

> You look at your PC. You have half a dozen codecs available. Which ones 
> are you going to spend most time investigating? The ones you've never 
> heard of? Or the ones you've heard about that are supposed to be good? 
> Where are you going to spend the most effort?

First I'd spend some time investigating what are considered to be good 
codecs, which ones are popular and which are seldom used, rather than 
relying on my own knowledge. If I have some I've never heard of (and if so, 
why would I have them at all), I'd do a little bit of investigating until I 
had a basic understanding of them

> Also... You make it sound like Google is some magical Oracle that will 
> instantly answer any possible question.

I never said that. I said that you should investigate, verify and confirm 
for yourself. If you search and can't find an answer, that's one thing, when 
you state something as a categorical truth and half a minute with google 
proves that it's completely false, that's quite another.

Searching's a skill that needs practice, it's not obvious first time what 
keywords are going to produce an answer. Sometimes it takes several 
searches, refining the terms each time based on what's returned and what's 
not.

fyi, I've had very few questions where I couldn't get an answer out from 
either google or a forum/newsgroup/mailing list on the particular subject. 
That's for work stuff, for stuff that I'm casually interested in, for 
game-related stuff and for information for my Masters thesis.

Post a reply to this message

>> You look at your PC. You have half a dozen codecs available. Which 
>> ones are you going to spend most time investigating? The ones you've 
>> never heard of? Or the ones you've heard about that are supposed to be 
>> good? Where are you going to spend the most effort?
> 
> First I'd spend some time investigating what are considered to be good 
> codecs, which ones are popular and which are seldom used, rather than 
> relying on my own knowledge. If I have some I've never heard of (and if 
> so, why would I have them at all), I'd do a little bit of investigating 
> until I had a basic understanding of them

Now here's the thing. Google is very good at answering "what is X?" and 
to some extent "how do I do Y?". But how on earth do you get an answer 
to something like "what's the most popular Z?" Google can't tell you 
that. Only *people* can tell you that.

>> Also... You make it sound like Google is some magical Oracle that will 
>> instantly answer any possible question.
> 
> I never said that. I said that you should investigate, verify and 
> confirm for yourself. If you search and can't find an answer, that's one 
> thing, when you state something as a categorical truth and half a minute 
> with google proves that it's completely false, that's quite another.

Well this thread started by my stating that *I* couldn't get a decent 
picture out of DivX - which *is* a categorical truth. I know. I was there.

I have never claimed that DivX isn't good; I just said that it didn't 
work for me.

Also, I can't really do a Google search every single time I utter any 
sentence in case something in that sentence is not factually accurate. 
I'd never say anything! There has to be some sane limits here.

> Searching's a skill that needs practice, it's not obvious first time 
> what keywords are going to produce an answer. Sometimes it takes several 
> searches, refining the terms each time based on what's returned and 
> what's not.
> 
> fyi, I've had very few questions where I couldn't get an answer out from 
> either google or a forum/newsgroup/mailing list on the particular 
> subject. That's for work stuff, for stuff that I'm casually interested 
> in, for game-related stuff and for information for my Masters thesis.

Clearly you are radically better at this stuff than I am.

Just the other day I was trying to figure out the relative speed of 
various CPU arithmetic operations, and I couldn't find anything useful 
with Google (as evidenced by my asking here).

It was only a few weeks back that I wanted to know how to configure an 
Exchange public folder so it can receive email. Various websites tell 
you how to do this, but they all assume you have access to the Exchange 
admin console. Is there a way of doing it without that access? I guess 
I'll never know - cos Google sure can't tell me.

There is an endless list of obscure computer problems I've had that 
Google couldn't solve for me. (Clearly nobody else had ever had the 
exact problem I had.)

So yeah, there's a pretty huge sea of questions that I couldn't get 
Google to answer. It's not an Oracle, it's just a search engine.

Post a reply to this message

Invisible wrote:
> I guess I just assumed that if something doesn't come with any 
> instructions, it's supposed to be "obvious" enough that you don't need 
> them.

I think that only applies to commercial products. Sadly, I've bought a 
few commercial products, hoping they'd have better instructions than the 
free equivalents, only to find that the author didn't even feel it was 
worth updating the printed manual to cover the last couple of versions 
of the software.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> Google works very well for certain questions, and drastically less well 
> for certain other questions. 

No. Google works well if you are looking for an answer. It works poorly 
if you're asking a question.

The difference is that google searches answers. If you don't have any 
idea what the answer looks like, you're unlikely to find it no matter 
how precisely you state the question.

Fortunately, *most* questions have the seeds of their answer already 
planted in the question.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> But how on earth do you get an answer 
> to something like "what's the most popular Z?" 

http://google.com/search?q=what+is+the+most+popular+codec

> Just the other day I was trying to figure out the relative speed of 
> various CPU arithmetic operations, and I couldn't find anything useful 
> with Google (as evidenced by my asking here).

That's the sort of thing where you need to know what the answer looks 
like in order to find it, methinks. If you don't know the term used for 
spec sheets, you're going to get too many odd hits on relative speeds of 
CPUs.

> So yeah, there's a pretty huge sea of questions that I couldn't get 
> Google to answer. It's not an Oracle, it's just a search engine.

That searches answers, not questions. Keep that in mind. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
> Now here's the thing. Google is very good at answering "what is X?" and
> to some extent "how do I do Y?". But how on earth do you get an answer
> to something like "what's the most popular Z?" Google can't tell you
> that. Only *people* can tell you that.

Google searches the WWW. Finding things *people* put there.

Post a reply to this message

On Fri, 31 Oct 2008 12:07:17 +0000, Invisible wrote:

> Now here's the thing. Google is very good at answering "what is X?" and
> to some extent "how do I do Y?". But how on earth do you get an answer
> to something like "what's the most popular Z?" Google can't tell you
> that. Only *people* can tell you that.

Try putting "popular video encoders" in the Google search box.  The links 
that come up (just on a quick overview) don't say "this is the most 
popular", but they do give some useful pointers.

> So yeah, there's a pretty huge sea of questions that I couldn't get
> Google to answer. It's not an Oracle, it's just a search engine.

Yes, and if you learn how to speak the language the search engine knows, 
it is a very powerful tool for learning stuff.

With the search terms suggested above (without the quotes), the fifth hit 
is a Wikipedia article on Video Codecs; item 3 in the TOC on that page is 
"Common used standards and codecs" and gives a good overview of each of 
the most popular codecs out there.

For example:

"MPEG-1 Part 2: Used for Video CDs, and also sometimes for online video. 
If the source video quality is good and the bitrate is high enough, VCD 
can look slightly better than VHS. To exceed VHS quality, a higher 
resolution would be necessary. However, to get a fully compliant VCD 
file, bitrates higher than 1150 kbit/s and resolutions higher than 352 x 
288 should not be used. When it comes to compatibility, VCD has the 
highest compatibility of any digital video/audio system. Very few DVD 
players do not support VCD, but they all inherently support the MPEG-1 
codec. Almost every computer in the world can also play videos using this 
codec. In terms of technical design, the most significant enhancements in 
MPEG-1 relative to H.261 were half-pel and bi-predictive motion 
compensation support. MPEG-1 supports only progressive scan video."

Now, knowing what VHS video looks like, that gives a good idea as to what 
sort of quality to expect out of it.

Jim

Post a reply to this message

On Fri, 31 Oct 2008 12:07:17 +0000, Invisible wrote:

> Just the other day I was trying to figure out the relative speed of
> various CPU arithmetic operations, and I couldn't find anything useful
> with Google (as evidenced by my asking here).

Search with "cpu speed arithmetic" - hit numbers 4&6 seem like they might 
be relevant.

Jim

Post a reply to this message

Jim Henderson wrote:
> Now, knowing what VHS video looks like, that gives a good idea as to what 
> sort of quality to expect out of it.

Yeah. Just so folks understand, MPEG1 was designed to be delivered over 
a T1 speed link, which is the same speed as a 1x CD drive. You can't 
really expect too much out of 24 voice channels or one high-quality 
uncompressed audio stream if you're trying to deliver video. :)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Sat, 01 Nov 2008 09:19:40 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Now, knowing what VHS video looks like, that gives a good idea as to
>> what sort of quality to expect out of it.
> 
> Yeah. Just so folks understand, MPEG1 was designed to be delivered over
> a T1 speed link, which is the same speed as a 1x CD drive. You can't
> really expect too much out of 24 voice channels or one high-quality
> uncompressed audio stream if you're trying to deliver video. :)

Yup. :-)

Jim

Post a reply to this message

Darren New wrote:

> Yeah. Just so folks understand, MPEG1 was designed to be delivered over 
> a T1 speed link, which is the same speed as a 1x CD drive. You can't 
> really expect too much out of 24 voice channels or one high-quality 
> uncompressed audio stream if you're trying to deliver video. :)

Really? That's interesting; I was under the impression that you can use 
MPEG1 at any arbitrary bitrate.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> Since apparently every other user on the planet doesn't have any of these 
>> problems, apparently I'm just too stupid to work it out...
>
> Or you haven't read tutorials that they have

Or used one of the many GUIs for the command-line encoders that provide a 
wide variety of configuration presets.

Post a reply to this message

scott wrote:
>>> Since apparently every other user on the planet doesn't have any of 
>>> these problems, apparently I'm just too stupid to work it out...
>>
>> Or you haven't read tutorials that they have
> 
> Or used one of the many GUIs for the command-line encoders that provide 
> a wide variety of configuration presets.

The tool I was using *had* a GUI. With 50,000 options on it. None of 
which appeared to affect image quality. (E.g., increasing the bitrate or 
the "quality" settings made little to no difference.)

Post a reply to this message

> The tool I was using *had* a GUI. With 50,000 options on it. None of which 
> appeared to affect image quality. (E.g., increasing the bitrate or the 
> "quality" settings made little to no difference.)

Try XVid4PSP, it's free and so far I have never even needed to change any 
advanced settings.  It has presets with names for each format.  If you 
choose the format as plain AVI, under video encoding you can choose options 
like "FFV1 Lossless" or "xVid HQ Ultra" or "x264 HQ Ultra" etc.  Under 
format you can also choose MP4 Mpeg1 Mpeg2 etc, it really is quite easy to 
use.

It also accepts a huge range of input formats, including VOB if the "open 
file" dialog box is anything to go by.

And of course if you feel like tinkering (I have never needed to), you can 
go and edit the details of each preset.

Post a reply to this message

scott wrote:
>> The tool I was using *had* a GUI. With 50,000 options on it. None of 
>> which appeared to affect image quality. (E.g., increasing the bitrate 
>> or the "quality" settings made little to no difference.)
> 
> Try XVid4PSP, it's free and so far I have never even needed to change 
> any advanced settings.  It has presets with names for each format.  If 
> you choose the format as plain AVI, under video encoding you can choose 
> options like "FFV1 Lossless" or "xVid HQ Ultra" or "x264 HQ Ultra" etc.  
> Under format you can also choose MP4 Mpeg1 Mpeg2 etc, it really is quite 
> easy to use.
> 
> It also accepts a huge range of input formats, including VOB if the 
> "open file" dialog box is anything to go by.
> 
> And of course if you feel like tinkering (I have never needed to), you 
> can go and edit the details of each preset.

I installed FFDshow the other day. That seems to give me several 
lossless codecs that are nice and easy to use.

According to what Gail said, the tool I used must have been the DivX 
encoder. (Or rather, the trail version of it.) I'm going to give Xvid a 
try later and see what that does...

(Of course, you never see DVDs that look blurry and messed up. 
Presumably that means they figured out how to avoid that in MPEG2. 
Unfortunately, MPEG2 is the hardest codec under the sun to find software 
for - presumably because they use it on DVDs, so everybody wants to 
charge you *money* for it...)

Post a reply to this message

> (Of course, you never see DVDs that look blurry and messed up. Presumably 
> that means they figured out how to avoid that in MPEG2. Unfortunately, 
> MPEG2 is the hardest codec under the sun to find software for - presumably 
> because they use it on DVDs, so everybody wants to charge you *money* for 
> it...)

Xvid4PSP offers MPEG2 PAL and NTSC format options, with encoding options 
like "1-pass 8mbit", "2-pass 8mbit", "CBR 9.2mbit", and "copy" which 
presumably does no reencoding if your source file is already MPEG2 
compatible.

I would expect those would give the same results as a commerical DVD.

But for uploading to YouTube, I would use a more modern codec like xVid 
(which they accept) that will give you smaller files for the same quality.

Post a reply to this message

Mueen Nawaz wrote:

> 	So I'll tell you what you were told before: MPEG1 sucks. MPEG2 is
> better. If mpeg4 is a headache for you, just do mpeg2.

MPEG2 is very hard to get hold of. It seems that because DVDs use it, 
and DVD software costs money, it is not possible to get hold of a free 
MPEG2 encoder.

Post a reply to this message

scott wrote:
>> (Of course, you never see DVDs that look blurry and messed up. 
>> Presumably that means they figured out how to avoid that in MPEG2. 
>> Unfortunately, MPEG2 is the hardest codec under the sun to find 
>> software for - presumably because they use it on DVDs, so everybody 
>> wants to charge you *money* for it...)
> 
> Xvid4PSP offers MPEG2 PAL and NTSC format options, with encoding options 
> like "1-pass 8mbit", "2-pass 8mbit", "CBR 9.2mbit", and "copy" which 
> presumably does no reencoding if your source file is already MPEG2 
> compatible.
> 
> I would expect those would give the same results as a commerical DVD.

Heh. My DVD authoring software [came free with the DVD burner] doesn't 
give me quality *quite* that good. (Although it is fairly close.)

> But for uploading to YouTube, I would use a more modern codec like xVid 
> (which they accept) that will give you smaller files for the same quality.

At the moment, just getting good quality at all - at *any* filesize - 
would be impressive.

What I can't figure out is this: There are dozens of audio codecs that 
can take a sound file and make it *at least* 5x smaller with absolutely 
_NO_ detectable loss of quality at all. (And far smaller still if you're 
willing to sacrifice a little clarity.) But it seems there are no codecs 
that can shrink video without a visible loss of quality. (Aside from a 
few lossless codecs which usually give you about ~20% smaller or so.)

I guess video is just a much harder problem...

Post a reply to this message

> What I can't figure out is this: There are dozens of audio codecs that can 
> take a sound file and make it *at least* 5x smaller with absolutely _NO_ 
> detectable loss of quality at all. (And far smaller still if you're 
> willing to sacrifice a little clarity.) But it seems there are no codecs 
> that can shrink video without a visible loss of quality. (Aside from a few 
> lossless codecs which usually give you about ~20% smaller or so.)

Huh? Even MPEG2 (as used on DVDs) can reduce the raw bitrate from 240 Mbit 
to 10 Mbit (so 24x smaller) with little detectable quality loss.  More 
recent codecs will definitely improve on this, like xVid and h264.

Post a reply to this message

scott wrote:
>> What I can't figure out is this: There are dozens of audio codecs that 
>> can take a sound file and make it *at least* 5x smaller with 
>> absolutely _NO_ detectable loss of quality at all. (And far smaller 
>> still if you're willing to sacrifice a little clarity.) But it seems 
>> there are no codecs that can shrink video without a visible loss of 
>> quality. (Aside from a few lossless codecs which usually give you 
>> about ~20% smaller or so.)
> 
> Huh? Even MPEG2 (as used on DVDs) can reduce the raw bitrate from 240 
> Mbit to 10 Mbit (so 24x smaller) with little detectable quality loss.

Now compare the MPEG2 video back-to-back with the uncompressed original. 
Are you seriously telling me there is *no* detectable loss of quality?

Sure, it's a fairly small loss, but it *is* noticable. I wonder what the 
bitrate would need to be increased to for it to be impossible to tell 
the difference...

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:490ec9db$1@news.povray.org...
> Mueen Nawaz wrote:
>
>> So I'll tell you what you were told before: MPEG1 sucks. MPEG2 is
>> better. If mpeg4 is a headache for you, just do mpeg2.
>
> MPEG2 is very hard to get hold of. It seems that because DVDs use it, and 
> DVD software costs money, it is not possible to get hold of a free MPEG2 
> encoder.

http://www.google.com/search?q=free+mpeg2+encoder

The first hit is for the site www.free-codecs.com/download/FreeEnc.htm
"FreeEnc is a free MPEG-2 encoder, which uses avcodec library to encode. 
This encoder takes  AVISynth input(.avs) and outputs MPEG2 like  QuEnc, but 
the main difference is that every parameter is tweakable, plus it comes with 
the optimized parameters of MencodeMe, which are known to produce great 
quality."

The third hit is for www.videohelp.com/tools/HC
"HC is a free MPEG2 Encoder. Input can be a d2v project or input using 
Avisynth. 2 pass VBR encoding."

Post a reply to this message

> Now compare the MPEG2 video back-to-back with the uncompressed original. 
> Are you seriously telling me there is *no* detectable loss of quality?

Depends on the content - if your video consists of data you would typically 
use PNG to encode rather than JPG, or where each frame is vastly different 
from the previous one, then of course it's not going to compress well. 
MPEG2 was designed to work well with real life captured video, and it does 
that pretty well within the 10Mbit allocated by the DVD standard.

Another example, I made a video of some planets rolling about in POV, the 
original uncompressed frames totalled 9.7 GB, after using MPEG4 the video 
came out as 28MB, that's 350x smaller!  Really, there is no noticeable 
difference in quality, I can't tell the difference by looking at a 
freeze-frame in VLC compared to the original BMP.

> Sure, it's a fairly small loss, but it *is* noticable. I wonder what the 
> bitrate would need to be increased to for it to be impossible to tell the 
> difference...

Depends on the content of course.

Post a reply to this message

scott wrote:
>> Now compare the MPEG2 video back-to-back with the uncompressed 
>> original. Are you seriously telling me there is *no* detectable loss 
>> of quality?
> 
> Depends on the content - if your video consists of data you would 
> typically use PNG to encode rather than JPG, or where each frame is 
> vastly different from the previous one, then of course it's not going to 
> compress well. MPEG2 was designed to work well with real life captured 
> video, and it does that pretty well within the 10Mbit allocated by the 
> DVD standard.

Commercial DVDs do seem to do this quite well. (For some reason, DVDs I 
encoded myself aren't quite as good - although they're still not bad 
considering the compression ratio.)

> Another example, I made a video of some planets rolling about in POV, 
> the original uncompressed frames totalled 9.7 GB, after using MPEG4 the 
> video came out as 28MB, that's 350x smaller!  Really, there is no 
> noticeable difference in quality, I can't tell the difference by looking 
> at a freeze-frame in VLC compared to the original BMP.

That's some pretty steep claims. ;-)

Post a reply to this message

> That's some pretty steep claims. ;-)

Here's the difference scaled up by a factor of 32 from one frame.  You 
cannot see the difference even when studying the two stills closely.

Post a reply to this message

Attachments:
Download 'diff.png' (254 KB)

Preview of image 'diff.png'

Invisible <voi### [at] devnull> wrote:
> Commercial DVDs do seem to do this quite well. (For some reason, DVDs I 
> encoded myself aren't quite as good - although they're still not bad 
> considering the compression ratio.)

  Creating an MPEG2 stream is far from an unambiguous process. Some programs
do a much better job than other programs ever could, no matter how much you
fine-tune their settings.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Creating an MPEG2 stream is far from an unambiguous process. Some programs
> do a much better job than other programs ever could, no matter how much you
> fine-tune their settings.

When last I looked, encoding to MPEG1 basically involves taking the DCT 
of each frame, in the style of JPEG. There's also some fun with 
different frame types. It looked to me like there's basically only one 
possible bitstream you can produce. (Well, no, you can fiddle with the 
quantinisation matrix, and if you're doing variable bitrate there are 
some possibilities.)

I'm not actually sure how MPEG2 differs from MPEG1. I know they added 
some more features, but I don't know specifically what.

Post a reply to this message

> When last I looked, encoding to MPEG1 basically involves taking the DCT of 
> each frame, in the style of JPEG. There's also some fun with different 
> frame types. It looked to me like there's basically only one possible 
> bitstream you can produce. (Well, no, you can fiddle with the 
> quantinisation matrix, and if you're doing variable bitrate there are some 
> possibilities.)

It's not surprising that mpeg2 and 4 are much more complex than this.  The 
key concept is how to describe the current frame fairly accurately with the 
minimum amount of data, given some data from previous (and in some cases 
future) frames.  Commonly motion is detected, as often blocks of pixels 
hardly change, but are shifted in space from one frame to the next.  So you 
could say that the whole frame is a copy of the previous frame, but with 
some region from 5 frames ago shifted right 23 pixels, and then with some 
additional data and pixel changes.  Obviously then there is more than one 
possible bitstream depending on how good your motion detection code is, 
which frames you reference, what tolerance you use for detecting motion, etc 
etc.  And of course at some point you need to consider the CPU power needed 
to encode the video.

Post a reply to this message

scott wrote:

> It's not surprising that mpeg2 and 4 are much more complex than this.

On the contrary, it would be surprising if MPEG2 was *not* more complex 
than this... ;-)

> The key concept is how to describe the current frame fairly accurately 
> with the minimum amount of data, given some data from previous (and in 
> some cases future) frames.  Commonly motion is detected, as often blocks 
> of pixels hardly change, but are shifted in space from one frame to the 
> next.

...so they added motion prediction then?

> Obviously then 
> there is more than one possible bitstream depending on how good your 
> motion detection code is, which frames you reference, what tolerance you 
> use for detecting motion, etc etc.

Indeed.

> And of course at some point you need 
> to consider the CPU power needed to encode the video.

I'm usually more interested in how much CPU power is required to 
*decode* the video. Let's face it, no codec on Earth is as slow as 
POV-Ray. ;-)

Post a reply to this message

Invisible wrote:
> There's also some fun with different frame types. 

That's the main place the ambiguities come from. If you don't understand 
the ways in which you can build a B-frame, you're not going to see where 
you can get good quality at low bitrates for video with things moving.

MPEG1 had motion prediction too. It's just that the CPU power needed to 
do it never got cheap before MPEG2 came out.

Back in 1991 or so, I worked with someone who encoded 6 minutes of Star 
Wars as MPEG1 for testing video on demand. They sent it out to a place 
that had a specially-built cluster of machines for doing this work, and 
it took several CPU weeks.  (This was in the same timeframe where doing 
jpeg compression needed special hardware cards in a PC, to the point 
where it was faster to ship the image to the PC with the card, compress 
it, and ship the results back, than it was to do in software.)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> There's also some fun with different frame types. 
> 
> That's the main place the ambiguities come from. If you don't understand 
> the ways in which you can build a B-frame, you're not going to see where 
> you can get good quality at low bitrates for video with things moving.
> 
> MPEG1 had motion prediction too. It's just that the CPU power needed to 
> do it never got cheap before MPEG2 came out.

I know that MPEG has several different kinds of frames, some of which 
are individual, independent frames, and some of which are related to 
previous frames. I can just never remember the exact details; every 
reference on the subject that I've ever read has made it sound insanely 
complex, when obviously it isn't.

> Back in 1991 or so, I worked with someone who encoded 6 minutes of Star 
> Wars as MPEG1 for testing video on demand. They sent it out to a place 
> that had a specially-built cluster of machines for doing this work, and 
> it took several CPU weeks.  (This was in the same timeframe where doing 
> jpeg compression needed special hardware cards in a PC, to the point 
> where it was faster to ship the image to the PC with the card, compress 
> it, and ship the results back, than it was to do in software.)

Damn. And here I was thinking an integer-arithmetic FFT would be really 
fast...

Post a reply to this message

Invisible wrote:
> I know that MPEG has several different kinds of frames, some of which 
> are individual, independent frames, and some of which are related to 
> previous frames. I can just never remember the exact details; every 
> reference on the subject that I've ever read has made it sound insanely 
> complex, when obviously it isn't.

It's pretty easy. There's three kinds of frames:

I - Independent. Basically JPEG. Used when going FF and Fast Reverse. 
About every half second.

P - Predictive. Differences based on the previous I frame. About five 
per I frame.

B - Bidirectional. Based in the previous and following frame.

Lots of cheaper mpeg encoding software doesn't do B frames, because 
they're a PITA to calculate efficiently. Natch, with faster and faster 
CPUs, this becomes less of a problem. 5 or 10 years ago, you could spend 
weeks looking for an easy-to-use compressor that would do B frames.

I think the higher numbered MPEGs added more options to the encoding of 
B frames, so that you could look at more than just one frame away, for 
example.

> Damn. And here I was thinking an integer-arithmetic FFT would be really 
> fast...

When your CPU is a 16-bit CPU on an 8-bit bus running at a dozen MHz, 
even integer FFT is slow.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > Damn. And here I was thinking an integer-arithmetic FFT would be really 
> > fast...

> When your CPU is a 16-bit CPU on an 8-bit bus running at a dozen MHz, 
> even integer FFT is slow.

  And FFT is not the only thing an MPEG encoder has to do. Far from it.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> Damn. And here I was thinking an integer-arithmetic FFT would be really 
>>> fast...
> 
>> When your CPU is a 16-bit CPU on an 8-bit bus running at a dozen MHz, 
>> even integer FFT is slow.
> 
>   And FFT is not the only thing an MPEG encoder has to do. Far from it.

Well quantinisation isn't exactly math-intensive, and the arithmetic 
encoding stage shouldn't be too hard either. (It's fiddly to code 
correctly, but it's all simple integer arithmetic.) I'm not sure what 
else is *in* the MPEG encoder transform...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New wrote:

> It's pretty easy. There's three kinds of frames:
> 
> I - Independent. Basically JPEG. Used when going FF and Fast Reverse. 
> About every half second.
> 
> P - Predictive. Differences based on the previous I frame. About five 
> per I frame.
> 
> B - Bidirectional. Based in the previous and following frame.
> 
> Lots of cheaper mpeg encoding software doesn't do B frames, because 
> they're a PITA to calculate efficiently. Natch, with faster and faster 
> CPUs, this becomes less of a problem. 5 or 10 years ago, you could spend 
> weeks looking for an easy-to-use compressor that would do B frames.
> 
> I think the higher numbered MPEGs added more options to the encoding of 
> B frames, so that you could look at more than just one frame away, for 
> example.

I'm not really comprehending the significance of the distinction between 
P frames and B frames...

>> Damn. And here I was thinking an integer-arithmetic FFT would be 
>> really fast...
> 
> When your CPU is a 16-bit CPU on an 8-bit bus running at a dozen MHz, 
> even integer FFT is slow.

True - but the Intel product line has been 32-bit over a 32-bit bus 
since, what, the Pentium at least?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> I'm not really comprehending the significance of the distinction between 
> P frames and B frames...

P frames are differences from the previous I frame.

B frames are differences from the preceding and following frames, 
whether they be I or P or B.

In other words, you can't play a B frame at all without all the data 
between one I frame and the next.

Ever try to skip forward and back in a youtube video? Those jumps 
*there* are the I frames (or whatever equivalent). P frames need the 
previous I frame (and maybe previous P frames? I don't remember) and B 
frames need all the data between two I frames.

> True - but the Intel product line has been 32-bit over a 32-bit bus 
> since, what, the Pentium at least?

Yep. How long do you think DSL and MPEG1 has been around? :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
>> The key concept is how to describe the current frame fairly accurately
>> with the minimum amount of data, given some data from previous (and in
>> some cases future) frames.  Commonly motion is detected, as often blocks
>> of pixels hardly change, but are shifted in space from one frame to the
>> next.
> 
> ...so they added motion prediction then?

Wasn't that in MPEG1 already? (honest ignorant question)

Post a reply to this message

Nicolas Alvarez wrote:
> Wasn't that in MPEG1 already? (honest ignorant question)

I think it was, yes.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> I'm not really comprehending the significance of the distinction 
>> between P frames and B frames...
> 
> P frames are differences from the previous I frame.
> 
> B frames are differences from the preceding and following frames, 
> whether they be I or P or B.
> 
> In other words, you can't play a B frame at all without all the data 
> between one I frame and the next.

I get that there are full frames and difference frames. I'm just not 
really understanding why there are two different kinds of difference 
frames...

> Ever try to skip forward and back in a youtube video? Those jumps 
> *there* are the I frames (or whatever equivalent).

Yeah, I figured that out a long time ago. ;-) Presumably otherwise you'd 
only have one I frame, right at the very start.

Post a reply to this message

>> P frames are differences from the previous I frame.
>>
>> B frames are differences from the preceding and following frames, whether 
>> they be I or P or B.
>>
>> In other words, you can't play a B frame at all without all the data 
>> between one I frame and the next.
>
> I get that there are full frames and difference frames. I'm just not 
> really understanding why there are two different kinds of difference 
> frames...

I think it's just because P frames are way simpler (both for encoding and 
decoding), so they get their own name.  It's very fixed how the behave (it's 
always the difference from the previous I frame), whereas B frames are much 
more flexible, having inputs from a number of frames ahead and behind (even 
from other B frames, which can make matters very complex).  Some players get 
confused if you use too many B frames, or use them in the "wrong" places, or 
use them at all!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Nicolas Alvarez wrote:
> > Wasn't that in MPEG1 already? (honest ignorant question)

> I think it was, yes.

  The motion detection in mpeg4 is much more complicated than in mpeg1.
Mpeg4 can track the motion of freely-shaped areas.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The motion detection in mpeg4 is much more complicated than in mpeg1.
> Mpeg4 can track the motion of freely-shaped areas.

Cool. I think MPEG1 was just 8x8 blocks. I knew they had to be doing 
*something* more complicated. :-)

Maybe here's something you know: If Xvid and DivX are MPEG4, why do you 
need a special codec to decode them? They're either outputting standard 
mpeg4 or they aren't, yes?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Invisible wrote:
>>> I'm not really comprehending the significance of the distinction 
>>> between P frames and B frames...
>>
>> P frames are differences from the previous I frame.
>>
>> B frames are differences from the preceding and following frames, 
>> whether they be I or P or B.
>>
>> In other words, you can't play a B frame at all without all the data 
>> between one I frame and the next.
> 
> I get that there are full frames and difference frames. I'm just not 
> really understanding why there are two different kinds of difference 
> frames...

One difference frame (P) is a difference from the past. They're 
"progressive" changes since the last full frame.

The other difference frame (B) is a difference from the past *and* the 
future. In other words, if you have B-frames, the decoder has to buffer 
several uncompressed frames, reading ahead in the stream past where it's 
actually playing. B frames have forward references to the content of 
frames that come later in the stream. You can't play a B-frame as soon 
as you read it. You have to keep reading to the next I-frame [1], then 
decompress the B-frames you've buffered up.

[1] Maybe it's P frames you read ahead to. It's been years since I 
looked at the details.

> Yeah, I figured that out a long time ago. ;-) Presumably otherwise you'd 
> only have one I frame, right at the very start.

Well, it also lets you tune in to the middle of a program. Remember, it 
was for "video on demand" all this got invented. Otherwise you'd just 
mail an analog tape.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Maybe here's something you know: If Xvid and DivX are MPEG4, why do you 
> need a special codec to decode them? They're either outputting standard 
> mpeg4 or they aren't, yes?

  AFAIK both codecs can play most videos made by the other. However, one of
them might be implementing something of the mpeg4 standard the other isn't.
(AFAIK neither one implemens the *full* mpeg4 standard.) There might also
be some codec-specific additions as well.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Maybe here's something you know: If Xvid and DivX are MPEG4, why do you
> need a special codec to decode them? They're either outputting standard
> mpeg4 or they aren't, yes?

I once changed the FourCC of an AVI file from one MPEG4-based codec to
another. It *mostly* worked.

Post a reply to this message