Total keyframes?

[anonymous_whatever]

So, as work flow now I've got:

import DV >

deinterlace using QTGMC
change resolution to 640x480
convert to square pixels
crop DV black space
h.264 long GOP

>

edit

>

export xVid

[anonymous_whatever]

Is there any utility or method out there to find out how many keyframes are in a given sample video?

May I ask what is a sense to know a number of K-frames?

I didn't say anything about K-frames...

[DmitryV]

Is there any utility or method out there to find out how many keyframes are in a given sample video?

Khm, are you kidding me?

[DmitryV]

Sorry, probably that's a misunderstanding. I meant K-Frames as keyframes

[anonymous_whatever]

oh ok lol. well after taking DV and compressing to h.264 intraframe, i wanted to ensure that every frame is in fact defined as keyframe, to confirm it.

[jagabo]

import DV >

deinterlace using QTGMC
change resolution to 640x480
convert to square pixels
crop DV black space
h.264 long GOP

>

edit

>

export xVid

This is seriously misguided when you can get a 3 TB drive for about US$150 and it will hold 230 hours of DV AVI.

Import DV
Edit
Save as DV

Only frames that have been changed will be re-encoded. Others will pass through unchanged. This is what DV is for.

QTGMC(), or Yadif(), or IVTC(), etc.
AnyOtherFiltering()
Save as whatever you want

So most of your video goes through only one additional lossy compression.

Be aware that many devices won't play 50 or 59.94 fps Xvid AVI.

If you MUST convert to h.264 first use short GOPs. 15 frame GOPS will get you 90 percent the compression of 250 frame GOPs, will be much easier to edit (seek), and won't require 10 seconds of video be reencoded just because one frame frame was changed, only 1/2 second. (Assuming a smart editor is used.)

[DmitryV]

Ok, you can check it with stream eye
http://www.elecard.com/en/products/professional/analysis/streameye-studio.html



Red collumns are usually I frames. As software is a professional it is costly, but for your purposes trial is more then enough.

[anonymous_whatever]

import DV >

deinterlace using QTGMC
change resolution to 640x480
convert to square pixels
crop DV black space
h.264 long GOP

>

edit

>

export xVid

This is seriously misguided when you can get a 3 TB drive for about US$150 and it will hold 230 hours of DV AVI.

Import DV
Edit
Save as DV

Only frames that have been changed will be re-encoded. Others will pass through unchanged. This is what DV is for.

QTGMC(), or Yadif(), or IVTC(), etc.
AnyOtherFiltering()
Save as whatever you want

So most of your video goes through only one additional lossy compression.

Be aware that many devices won't play 50 or 59.94 fps Xvid AVI.

If you MUST convert to h.264 first use short GOPs. 15 frame GOPS will get you 90 percent the compression of 250 frame GOPs, will be much easier to edit (seek), and won't require 10 seconds of video be reencoded just because one frame frame was changed, only 1/2 second. (Assuming a smart editor is used.)

ok, i got it. ok, i have a couple points/questions here:

short GOP h.264 seems to be the way to go for an intermediate codec. i'm expecting significantly smaller sizes than DV, so i'm obviously expecting a good amount of quality loss.

now, if you were to compare h.264 short GOP to h.264 intraframe only, why would short GOP be better? could you not get h.264 intraframe to a point where you can decrease file size to about the same level as short GOP h.264?

so, i guess it comes to: can you not get significant compression from h.264 intraframe compression when compared to the original DV video? i don't mind worse quality.

second,

i, compressed dv to x.264 with --keyint 1 (making every frame a keyframe) that resulted in a file that's about 20mb. then, took the resulting file and compressed as xVid. it ended up being -larger-, at about 22mb. how is this possible?

[poisondeathray]

now, if you were to compare h.264 short GOP to h.264 intraframe only, why would short GOP be better? could you not get h.264 intraframe to a point where you can decrease file size to about the same level as short GOP h.264?

Impossible

so, i guess it comes to: can you not get significant compression from h.264 intraframe compression when compared to the original DV video? i don't mind worse quality.

That's what I've been saying. Impossible to get good compression for intra

On average you 'll get easily get 50% reduction of size using long GOP over I-frame with similar quality. In that low bitrate range (you said 20% of the size), you 'll gain much much more. The lower the bitrate range that is acceptable to you , the more compression you will get from using long GOP, more b-frames. The trade offs and potential problems were mentioned earlier in this thread and your other thread

If you look at the streameye picture, look at the height of the bars. Notice how high the red ones are. If you filled the entire screen full of red bars - that's what you are doing with intra. x264 b-frames are very high in quality, much better than MPEG2 or xvid.

i, compressed dv to x.264 with --keyint 1 (making every frame a keyframe) that resulted in a file that's about 20mb. then, took the resulting file and compressed as xVid. it ended up being -larger-, at about 22mb. how is this possible?

But you didn't specify any other settings ? What rate control?

Are you using CRF? bitrate ? etc...

If you are using CRF based method, it will deliver bitrate appropriate to complexity. More detailed frames get higher bitrate, lower get lower. If you use ABR, then sometimes you will overallocate in areas, underallocate in others . If it was a blank wall it might only be 1MB. If it was an action scene it might be 100MB. If it was bitrate specificed, then filesize = bitrate x running time.

[anonymous_whatever]

i used default settings both both codecs... arghhhh

ok, i played with bitrate settings here. i got two similarly sized files using 800kbps.

question: if i set bitrate to the same number (800) for 2 different codecs, why would the file sizes not be exactly identical? they're very close, but I would expect them to be identical. is specifying a bitrate not a perfect method?

[jagabo]

i, compressed dv to x.264 with --keyint 1 (making every frame a keyframe) that resulted in a file that's about 20mb. then, took the resulting file and compressed as xVid. it ended up being -larger-, at about 22mb. how is this possible?

file size = bitrate * running time

Encoders never manage to meet the requested bitrate exactly.

[anonymous_whatever]

i, compressed dv to x.264 with --keyint 1 (making every frame a keyframe) that resulted in a file that's about 20mb. then, took the resulting file and compressed as xVid. it ended up being -larger-, at about 22mb. how is this possible?

file size = bitrate * running time

Encoders never manage to meet the requested bitrate exactly.

gotcha thanks