Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th June 2009, 08:46   #21  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
If, for technical reasons, we still need to force IDR frames every once in a while despite open-GOPs being perfectly fine keyframes, the value should be really large.
Quote:
only 1 IDR is needed in a stream.
If add these up, then the vanue DS is speaking of, could be set eqqual to the number of frames in the input-stream ? If you then make first frame of the output-stream an IDR, you wont get another one (if not needed/requested).
G_M_C is offline   Reply With Quote
Old 25th June 2009, 13:52   #22  |  Link
Trahald
Wewkiee
 
Trahald's Avatar
 
Join Date: Feb 2002
Location: kashyyyk
Posts: 2,269
Quote:
Originally Posted by G_M_C View Post
If add these up, then the vanue DS is speaking of, could be set eqqual to the number of frames in the input-stream ? If you then make first frame of the output-stream an IDR, you wont get another one (if not needed/requested).
That would still fall under 'lying' to the scene-cut routine.
__________________
...yeah...but...why on earth would I compare apples with apples?
Trahald is offline   Reply With Quote
Old 25th June 2009, 13:55   #23  |  Link
Trahald
Wewkiee
 
Trahald's Avatar
 
Join Date: Feb 2002
Location: kashyyyk
Posts: 2,269
Quote:
Originally Posted by Selur View Post
how about two two parameters 'max IDR interval' and 'may key frame interval' ? (I need IDR frames to cut lossles, don't I?)
A lot of sample streams i got when making h264info were cut at open gop. all that happens is first few b-frames (any that pts < the pts of the i-frame) are discarded during playback. same as what happens when seeking in an open gop stream. and yeah... just need a smart enough cutter. or maybe dumb enough, ie most probably just look for i frames , not necessarily IDRs.
__________________
...yeah...but...why on earth would I compare apples with apples?
Trahald is offline   Reply With Quote
Old 25th June 2009, 14:06   #24  |  Link
Trahald
Wewkiee
 
Trahald's Avatar
 
Join Date: Feb 2002
Location: kashyyyk
Posts: 2,269
@DS
I understand the changes you request for code-sake and I'll try to make them. Only that it probably will have to start with 'git reset --hard' except for maybe the SEI part. since i wrote it in a way that required me to understand the least about frame type decisioning. so might be a while. I really didnt make it with a commit in mind. just that noone else has bothered so i made something that worked (result wise if not code wise) mostly for myself although I dont mind sharing.

Would you explain why x264 even cares at all about max keyframe interval in scene cut decisions. AFAIK that is unique to x264. Im willing to code it (time permitting) without agreeing w/it but it would help if i could wrap my head around the idea behind it.
__________________
...yeah...but...why on earth would I compare apples with apples?
Trahald is offline   Reply With Quote
Old 25th June 2009, 14:07   #25  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Dark Shikari View Post
Well, you probably can cut at a recovery point, the cutting software just has to be smarter.
So we will have "recovery points" in between IDR frames, that are not IDR frames themselves ???

Can you explain a bit: How does that work? I mean, if we start decoding at a Non-IDR frame, we will require references from previous frames, don't we?

Okay, as far as I understand, a recovery point says "output will be good again in x frames, if you start decoding here". There may be "scrambled" output until frame x is reached.

But how does the encoder know? Does it keep track of all macro-blocks and write a recovery point after each macro-block has been "refreshed" at least once? Or what?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 25th June 2009 at 14:11.
LoRd_MuldeR is offline   Reply With Quote
Old 25th June 2009, 17:23   #26  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by Trahald View Post
@DS
I understand the changes you request for code-sake and I'll try to make them. Only that it probably will have to start with 'git reset --hard' except for maybe the SEI part. since i wrote it in a way that required me to understand the least about frame type decisioning. so might be a while. I really didnt make it with a commit in mind. just that noone else has bothered so i made something that worked (result wise if not code wise) mostly for myself although I dont mind sharing.
I don't think it's that hard at all; what you've done is almost right. All you have to do is consider recovery points to be keyframes, and you're done. You don't need to understand frametype decision at all; you only need to not change it.
Quote:
Originally Posted by Trahald View Post
Would you explain why x264 even cares at all about max keyframe interval in scene cut decisions. AFAIK that is unique to x264. Im willing to code it (time permitting) without agreeing w/it but it would help if i could wrap my head around the idea behind it.
Because if x264 is near the end of the GOP, x264 is more willing to place extra I-frames than if it had just placed one two frames ago.
Quote:
Originally Posted by LoRd_MuldeR View Post
So we will have "recovery points" in between IDR frames, that are not IDR frames themselves ???

Can you explain a bit: How does that work? I mean, if we start decoding at a Non-IDR frame, we will require references from previous frames, don't we?

Okay, as far as I understand, a recovery point says "output will be good again in x frames, if you start decoding here". There may be "scrambled" output until frame x is reached.

But how does the encoder know? Does it keep track of all macro-blocks and write a recovery point after each macro-block has been "refreshed" at least once? Or what?
That's called periodic intra refresh, and this patch isn't related to that.
Dark Shikari is offline   Reply With Quote
Old 25th June 2009, 17:24   #27  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Quote:
But how does the encoder know? Does it keep track of all macro-blocks and write a recovery point after each macro-block has been "refreshed" at least once? Or what?
The encoder can enforce it by preventing frames temporally after the I to reference frames temporally before the I. Don't forget that even if a frame is in the reference buffer (aka DPB), you are allowed not to use it (they'll be flushed out of the DPB in good time, ie, when you'll have encoded enough new reference frames)
__________________
Manao is offline   Reply With Quote
Old 25th June 2009, 17:48   #28  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Manao View Post
The encoder can enforce it by preventing frames temporally after the I to reference frames temporally before the I.
Hmm, I see. But what is the benefit of placing a "recovery" Non-IDR I-Frame instead of a "true" IDR-Frame, if we don't reference the frames before that I-Frame anyway?

Quote:
Originally Posted by Dark Shikari View Post
That's called periodic intra refresh, and this patch isn't related to that.
Does x264 support/use periodic intra refresh yet?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 25th June 2009 at 17:54.
LoRd_MuldeR is offline   Reply With Quote
Old 25th June 2009, 18:00   #29  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by LoRd_MuldeR View Post
Does x264 support/use periodic intra refresh yet?
No; it's really only useful for extremely-low-delay situations where your VBV is too small to allow periodic I-frames.
Dark Shikari is offline   Reply With Quote
Old 25th June 2009, 18:07   #30  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Quote:
Hmm, I see. But what is the benefit of placing a "recovery" Non-IDR I-Frame instead of a "true" IDR-Frame, if we don't reference the frames before that I-Frame anyway?
You can still open the gop, while an IDR forces to close the gop.
__________________
Manao is offline   Reply With Quote
Old 25th June 2009, 18:17   #31  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by Manao View Post
You can still open the gop, while an IDR forces to close the gop.
Sorry, what exactly does that mean then?

I though using references from the previous GOP (that is: before the last I-Frame) inside the current GOP is the definition of an "open" GOP

If we now decide to not use references from before the I-Frame (to get a valid "recovery point"), wouldn't that result in "closed" GOP's ???
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 25th June 2009 at 18:33.
LoRd_MuldeR is offline   Reply With Quote
Old 25th June 2009, 18:34   #32  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
In temporal order :
Code:
closed gop : PbbbPbbbPI
open   gop : PbbbPbbbbI
In coding order :
Code:
closed gop : PPbbbPbbbI
open   gop : PPbbbIbbbb
Note how, in coding order (ie, in the bitstream), the b frames temporally before the I frame are actually after the I frame. That's why the gop is called open. If you start decoding at the I, you won't be able to decode the b (you'll have to skip them), but it's no big deal because they are temporally before the I. IDR prevents you to use bframes in the open gop fashion because it flushes the reference buffer (thus, were you to use an IDR in an open gop situation, the bframes wouldn't not be able to reference the preceding P : they wouldn't be bframes anymore).
__________________
Manao is offline   Reply With Quote
Old 25th June 2009, 18:42   #33  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Ah, I see
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 28th June 2009, 12:17   #34  |  Link
juGGaKNot
Registered User
 
juGGaKNot's Avatar
 
Join Date: Feb 2008
Posts: 733
Trahald can you explain in n00b terms how does this help/affect the quality of fades and where is it usefull ( high resolutions only ? )

thnx.

Quote:
Originally Posted by Trahald View Post
This patch really is only useful if you have small gops (ie bluray) . my tests were at min keyint of 12. This patch is not for your production encodes as it is experimental. Do not create any binaries with this patch that may be in automatic upgrading scripts to protect the innocent.
Hmm a link about gops/gops-keyint relation ?

Last edited by juGGaKNot; 28th June 2009 at 12:24.
juGGaKNot is offline   Reply With Quote
Old 28th June 2009, 13:55   #35  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
As Trahald already said, this patch is useful mostly when you use a low max keyint interval. The reason for its usefulness is that, without the patch, x264 considers that key frames are IDR, which are special picture types that prevents the previous picture type to be a B frame. So, even if x264 would have wanted to use a B frame, if the following frame must be a key frame because of max keyint, without the patch the B will be transformed into a P frame, which isn't as good.

Furthermore, open gops will help reduce the problem of intra "pumping" at low bitrates and small gops.

Finally, a gop, in the mpeg2 terminology, is a group of picture starting on an intra frame, and stopping just before the next one. For mpeg2, all intra frames are entry points in the video, so settings the gop period set the entry points period. For h264, not all intra frames are sync points, but somehow the gop remained aliased to the idea of sync point (and not intra frames). So a gop can be seen as starting on an entry point (be it a IDR or a plain I frame) and stopping just before the next one.

With that definition, max-keyint sets the maximum gop size, and min keyint sets the minimum gop size.
__________________
Manao is offline   Reply With Quote
Old 28th June 2009, 14:20   #36  |  Link
juGGaKNot
Registered User
 
juGGaKNot's Avatar
 
Join Date: Feb 2008
Posts: 733
Quote:
Originally Posted by Manao View Post
As Trahald already said, this patch is useful mostly when you use a low max keyint interval.
Yes, thnx, most of this i have read ( not in such depth ) but i am asking about where to use them.

Quote:
Sets the maximum interval between IDR-frames (aka keyframes) in x264's output.
As far as i know when i render uncompressed from vegas every frame is a keyframe, is this wrong ?

juGGaKNot is offline   Reply With Quote
Old 28th June 2009, 14:25   #37  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
I don't know what VEGAS does. But x264 in "lossless" mode uses I-Frames (probably IDR and Non-IDR) as well as P-Frames.

Only B-Frames are disabled, because they don't help in the special case of lossless encoding.

If you want to enforce an I-Frame only stream for some reason, you can simply set the value of min_keyint to 1
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 28th June 2009 at 14:27.
LoRd_MuldeR is offline   Reply With Quote
Old 28th June 2009, 14:27   #38  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
It's normal. Uncompressed video doesn't have temporal dependencies between frames, so you can seek instantaneously wherever you want in an uncompressed video. The same would be true if you were encoding with mjpeg (all frames are intra), or ASP/AVC with only intra frames (max-keyint set to 1 with x264 for example).

As for when to use open gop : always. There are no (valid) reason not to use it. It's better, period.
__________________
Manao is offline   Reply With Quote
Old 28th June 2009, 14:33   #39  |  Link
juGGaKNot
Registered User
 
juGGaKNot's Avatar
 
Join Date: Feb 2008
Posts: 733
Quote:
Originally Posted by Manao View Post
It's normal. Uncompressed video doesn't have temporal dependencies between frames, so you can seek instantaneously wherever you want in an uncompressed video. The same would be true if you were encoding with mjpeg (all frames are intra), or ASP/AVC with only intra frames (max-keyint set to 1 with x264 for example).

As for when to use open gop : always. There are no (valid) reason not to use it. It's better, period.
K, i will test so maxkeyint 1 ?

Quote:
Originally Posted by Dark Shikari View Post
Again, "max keyint" in scenecut routines should be the distance between keyframes, not the distance between IDR frames.

Last edited by juGGaKNot; 28th June 2009 at 14:36.
juGGaKNot is offline   Reply With Quote
Old 28th June 2009, 14:52   #40  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Quote:
K, i will test so maxkeyint 1 ?
What for ?
__________________
Manao is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:10.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.