On Thu, 1 Nov 2018, Martin Storsjö wrote:
On Thu, 1 Nov 2018, Derek Buitenhuis wrote:
On 31/10/2018 21:41, Martin Storsjö wrote:
Even though we do allow reconfiguration, it doesn't look like we support
changing any parameters which would actually affect the delay, only RC
method and targets (
On Thu, 1 Nov 2018, Derek Buitenhuis wrote:
On 31/10/2018 21:41, Martin Storsjö wrote:
Even though we do allow reconfiguration, it doesn't look like we support
changing any parameters which would actually affect the delay, only RC
method and targets (CRF, bitrate, etc). So given that, the curre
On 31/10/2018 21:41, Martin Storsjö wrote:
> Even though we do allow reconfiguration, it doesn't look like we support
> changing any parameters which would actually affect the delay, only RC
> method and targets (CRF, bitrate, etc). So given that, the current patch
> probably should be safe - what
On Wed, 31 Oct 2018, Derek Buitenhuis wrote:
On 30/10/2018 19:49, Martin Storsjö wrote:
Hmm, that might make sense, but with a little twist. The max reordered
frames for H.264 is known, but onto that you also get more delay due to
frame threads and other details that this function within x264 k
On 30/10/2018 19:49, Martin Storsjö wrote:
> Hmm, that might make sense, but with a little twist. The max reordered
> frames for H.264 is known, but onto that you also get more delay due to
> frame threads and other details that this function within x264 knows
> about. So that would make it [H264 m
On Tue, 30 Oct 2018, Derek Buitenhuis wrote:
On 29/10/2018 21:06, Martin Storsjö wrote:
As I guess there can be old frames in flight, the only safe option is to
enlarge, not to shrink it. But in case a realloc moves the array, the old
pointers end up pretty useless.
Just always allocate the m
On 29/10/2018 21:06, Martin Storsjö wrote:
> As I guess there can be old frames in flight, the only safe option is to
> enlarge, not to shrink it. But in case a realloc moves the array, the old
> pointers end up pretty useless.
Just always allocate the max (which is known for H.264), and adjust
n
On Mon, 29 Oct 2018, Derek Buitenhuis wrote:
On 25/10/2018 13:58, Martin Storsjö wrote:
+x4->nb_reordered_opaque = x264_encoder_maximum_delayed_frames(x4->enc) + 1;
Is it possible this changes when the encoder is reconfigured (e.g. to
interlaced)?
Good point. I'm sure it's possible tha
On 25/10/2018 13:58, Martin Storsjö wrote:
> +x4->nb_reordered_opaque = x264_encoder_maximum_delayed_frames(x4->enc) +
> 1;
Is it possible this changes when the encoder is reconfigured (e.g. to
interlaced)?
- Derek
___
ffmpeg-devel mailing list
ff
libx264 does have a field for opaque data to pass along with frames
through the encoder, but it is a pointer, while the libavcodec
reordered_opaque field is an int64_t. Therefore, allocate an array
within the libx264 wrapper, where reordered_opaque values in flight
are stored, and pass a pointer to
10 matches
Mail list logo
