[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