[x264-devel] Re: discontinous encoding

Måns Rullgård mru at mru.ath.cx
Mon Aug 9 02:35:31 CEST 2004


Laurent Aimar <fenrir at via.ecp.fr> writes:

> On Mon, Aug 09, 2004, Måns Rullgård wrote:
>> I'm using x264 for real-time encoding of video, and to make that
>> possible I have to use an SMP machine and encode two or more GOPs in
>> parallel.  The resulting stream plays nicely, but I'm wondering
>> whether this manner of encoding can cause a non-conformant stream.
>> Any comments on this?  I'm using completely separate encoder contexts
>> and force an IDR frame when there is a discontinuity.
>
>  If you use same SPS/PPS and each encoder creates GOP starting with
>  IDR,

That's the case.

> then the stream should be valid if you take care of the
> i_idr_pic_id.
>
>  The constraint is that if you have 2 consecutive access units that are
> IDR frames, then i_idr_pic_id for theses IDR should not be equal.

Just to make sure I get this right, are you saying this constraint is
only for IDR frames with no intervening non-IDR frames?  Or do you
mean consecutive IDR frames, whatever is between them, must have
different i_idr_pic_id?

> Currently I just increase it by 1 every IDR, so that can fail, but
> it's easy to avoid : for N encoder threads, just init it for thread
> n to n and increase it by 2^X such as 2^X >= N and X < 16.  (you
> have to wrap i_idr_pic_id when >= 2^16)

That should work of course.  The problem is passing the information
from the threading module to x264 in a sensible way.  There would be
some changes required to x264, I suppose.

-- 
Måns Rullgård
mru at mru.ath.cx

-- 
This is the x264-devel mailing-list
If you are in trouble, please contact <postmaster at videolan.org>



More information about the x264-devel mailing list