[FFmpeg-devel] BUG? interlaced encoding using libx264, nal-hrd
erik at slagter.name
Fri Jun 24 16:28:39 CEST 2011
> I made a post a couple days ago about this and I am seeing the same
> thing you're seeing, but this was with non-interlaced material. When
> passing "nal-hrd" to libx264 via -x264opts I get the same error, "VBV
> parameters cannot be changed when NAL HRD is in use".
Well actually the problem is not in the interlacing, but in
activation of nal-hrd, which you need for a proper interlaced
stream (metadata). So yes, that's no surprise then ;-)
> Strange that the
> x264 binary doesn't complain about this, but when called via FFmpeg
> libx264 does.
I've noticed that a lot of the x264 options can be passed via
the x264_param_parse function, but not all of them (notably
profiles, levels and presets). Also some options seem to be
ignored when passed via ffmpeg/x264_param_parse, while x264
processes them okay. So there is some room for difference in
> I see you moved nal-hrd after vbv-bufsize/vbv-maxrate in your argument
> list, so apparently the order of the arguments doesn't matter. That
> is, unless FFmpeg is sending the arguments to libx264 in a different
> order than what is specified in the -x264opts string.
Actually I didn't move it there, it always has been there ;-)
As far as I can see from the libx264 source the ordering of the
x264opts does not make a difference for this problem. The error
appears long after all options have been processed, and in fact
during actual encoding.
Lib264 has a function x264_encoder_reconfig that allows the
caller to change some parameters after encoding has started.
FFmpeg (libx264.c) calls this function when interlacing or
aspect ratio parameters have changed (libx264.c:118). For some
reason this function gets called whenever I specify interlaced
encoding (but maybe it's actually the nal-hrd option that triggers
the call, I didn't test yet).
If I understand it all correctly, it's this call that triggers
the message. Although, imho it shouldn't be called in the first
place, because interlacing nor ar parameters are changing during
the encode. During this call of x264_encoder_config libx264
complains that vbv parameters cannot be changed during the
encoding (that's what it boils down to, according to the source
It's all a bit vague at the moment, I am willing to dive into
the issue and find out what's really happening here, but I was
interested if this was a known issue and maybe someone already
has some fix ready...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5110 bytes
Desc: S/MIME Cryptographic Signature
More information about the ffmpeg-devel