[x264-devel] Encoder questions

[vpstranger at tutanota.com]

I know how to use a search engine for a specific site and it's not a solution, because thus you depend on the quality of engine's index. The mailing list must have its own search. This need is so obvious and vital that I'm surprised not to find it here. In addition it's technically cheap concerning the small size of the archive. If this lack is the mailing software's fault, then it apparently must be replaced. I'm sure there is an alternative with search function that doesn't require additional payments.

11. Nov 2018 20:05 by andreas.rheinhardt at googlemail.com <mailto:andreas.rheinhardt at googlemail.com>:


> I am not an x264 developer, but I think I can answer some of your questions:
>
> vpstranger at tutanota.com <mailto:vpstranger at tutanota.com>> :
>> -Why don't you have a search on the mailing list contents? I might have found answers to some of my questions there, but without search the previous months are essentially unavailable to me.
> Maybe because one can simply use ordinary search engines to search the archive? Use "<search keywords> site:> https://mailman.videolan.org/pipermail/x264-devel <https://mailman.videolan.org/pipermail/x264-devel/>> " or whatever the syntax for your preferred search engine is.> -How does the algorithm decide, whether to insert IDR or simple I frame? Actually, I haven't seen a single IDR frame in my test encodes except for the initial one. So maybe it doesn't use them at all? And what exactly does the keyint parameter (and scenecut) specify? IDR frames only, simple I only or both types?
> Every I frame that is more than keyint_min away from the last keyframe will be a new keyframe (this does not apply for forced keyframes (e.g. via qpfile)). Whether this new keyframe is an IDR frame or not depends upon whether you are in open- or closed-gop mode. In closed-gop mode all keyframes are IDR frames, in open-gop mode the only non-forced IDR frame is the very first frame.
> The keyint parameter is essential the maximum length of a GOP: x264 will start a new GOP (i.e. insert a keyframe) if you are further than keyint away from the last keyframe. Notice that by default x264 also inserts keyframes at scenecuts. The scenecut parameter determines how different a frame has to be from the frames that preceded it in order to be coded as a keyframe.
>
> Btw: I think that x264's behaviour is suboptimal when using open-gop. Currently, x264 uses non-IDR-frames even at scenecuts, although one could save a few bytes when using an IDR frame there. This would also improve the stitchability of the resulting file (if one uses normal recovery point I frames, the frame_num and pic_order_cnt_lsb counters aren't reset so that one can get problems when one simply concatenates two parts of a video). I have actually already propesed a patch for this in February here: > https://mailman.videolan.org/pipermail/x264-devel/2018-February/012398.html <https://mailman.videolan.org/pipermail/x264-devel/2018-February/012398.html>> , but it was ignored. Notice that I don't know the x264 codebase very well -- I looked at the ratecontrol code in February a bit and my code worked well for me, but I don't know whether it would also work well with e.g. multiple lookahead threads.
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org <mailto:x264-devel at videolan.org>
> https://mailman.videolan.org/listinfo/x264-devel <https://mailman.videolan.org/listinfo/x264-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20181115/74d49877/attachment.html>