[FFmpeg-user] ffmpeg libx264 VBR and CBR output generates different POC, possible bug

[Maxim Levkov]

spoke too soon, problem persists... still looking for a solution.

False alarm!!!

Regards,
Maxim


On Tue, Nov 13, 2012 at 6:50 PM, Maxim Levkov <maxim.levkov at gmail.com>wrote:

> Hi Roger and Carl,
>
> Needless to say, after countless hours of tinkering, I have solved the
> problem, at least I see a consistently equal output from both CBR and VBR,
> as far as the POC ( picture order count ) goes.
>
> To help gather consistency, I've added a 2 pass and stats file to my
> command line. Then, I use stats file as source for rest of my bitrate
> variations and sequences.
>
> If you go through my post, earlier email, and use the sources for
> reproduction, then you can see the change. At least I've been able to
> reproduce the case consistently with bad and good results.
>
> Here is a modified command line that solved my case:
>
>
> Here is my command line for the CBR and VBR outputs:
>
> /* CBR: */
> -------
> b:\ffmpeg.exe -v 9 -loglevel 99 -i "F:\700_scale(640x360)_1min.
>  avi" -threads 0 ^ -force_key_frames
> 00:00:29.946,00:00:44.961,00:01:17.368,00:01:32.383 ^ -c:v libx264
> -sws_flags lanczos -cmp rd ^
> -x264opts
> pass=1:stats=1:bitrate=700:vbv_maxrate=700:vbv_bufsize=700:nal_hrd=cbr:rc_lookahead=40:interlaced=0:scenecut=0:cabac=1:keyint=120:level=3.2:deblock=1,0,0:aud=1:qpmin=16:qpmax=51:qpstep=10:ref=2:mixed-refs=1:subme=9:me=esa:chroma_me=0:merange=64:8x8dct=0:fast_pskip=0:chroma_qp_offset=0:trellis=2:psy=0:bframes=0:weightp=2:slices=0:sliced_threads=0:ipratio=1.40:qcomp=0.60:partitions=p8x8,b8x8,i8x8,i4x4:direct=auto:mbtree=0:colorprim=bt709:transfer=bt709:colormatrix=bt709
> ^
>
> -aspect 16:9  -pix_fmt yuv420p -c:a libvo_aacenc -ab 128000 -ar 44100 -ac
> 2 -f mp4 -y
> "b:\forced_i_frames_700_640x360_700_5secGOP_CBR_1min_POCtest.mp4"
> -vstats_file b:\consoleOutput_POC_CBR_vstats.txt
> 2>b:\consoleOutput_POC_CBR-loglevel99.txt
>
> /* CBR: */
> -------
> b:\ffmpeg.exe -v 9 -loglevel 99 -i "F:\700_scale(640x360)_1min.
> avi" -threads 0 ^ -force_key_frames
> 00:00:29.946,00:00:44.961,00:01:17.368,00:01:32.383 ^ -c:v libx264
> -sws_flags lanczos -cmp rd ^
>  -x264opts
> pass=2:stats=1:bitrate=700:vbv_maxrate=700:vbv_bufsize=700:nal_hrd=cbr:rc_lookahead=40:interlaced=0:scenecut=0:cabac=1:keyint=120:level=3.2:deblock=1,0,0:aud=1:qpmin=16:qpmax=51:qpstep=10:ref=2:mixed-refs=1:subme=9:me=esa:chroma_me=0:merange=64:8x8dct=0:fast_pskip=0:chroma_qp_offset=0:trellis=2:psy=0:bframes=0:weightp=2:slices=0:sliced_threads=0:ipratio=1.40:qcomp=0.60:partitions=p8x8,b8x8,i8x8,i4x4:direct=auto:mbtree=0:colorprim=bt709:transfer=bt709:colormatrix=bt709
> ^
>
> -aspect 16:9  -pix_fmt yuv420p -c:a libvo_aacenc -ab 128000 -ar 44100 -ac
> 2 -f mp4 -y
> "b:\forced_i_frames_700_640x360_700_5secGOP_CBR_1min_POCtest.mp4"
> -vstats_file b:\consoleOutput_POC_CBR_vstats.txt
> 2>b:\consoleOutput_POC_CBR-loglevel99.txt
> -------
> /* VBR */
> -------
> b:\ffmpeg.exe -v 9 -loglevel 99 -i "F:\700_scale(640x360)-1min.avi"
> -threads 0 ^ -force_key_frames
> 00:00:29.946,00:00:44.961,00:01:17.368,00:01:32.383 ^ -c:v libx264
> -sws_flags lanczos -cmp rd ^
>  -x264opts
> pass=2:stats=1:bitrate=700:vbv_maxrate=750:vbv_bufsize=800:nal_hrd=vbr:rc_lookahead=40:interlaced=0:scenecut=0:cabac=1:keyint=120:level=3.2:deblock=1,0,0:aud=1:qpmin=16:qpmax=51:qpstep=10:ref=2:mixed-refs=1:subme=9:me=esa:chroma_me=0:merange=64:8x8dct=0:fast_pskip=0:chroma_qp_offset=0:trellis=2:psy=0:bframes=0:weightp=2:slices=0:sliced_threads=0:ipratio=1.40:qcomp=0.60:partitions=p8x8,b8x8,i8x8,i4x4:direct=auto:mbtree=0:colorprim=bt709:transfer=bt709:colormatrix=bt709
> ^
>
> -aspect 16:9  -pix_fmt yuv420p -c:a libvo_aacenc -ab 128000 -ar 44100 -ac
> 2 -f mp4 -y
> "b:\forced_i_frames_700_640x360_800_5secGOP_VBR_1min_POCtest.mp4"
> -vstats_file b:\consoleOutput_POC_VBR_vstats.txt
> 2>b:\consoleOutput_POC_VBR-loglevel99.txt
> ----------------------------------------
>
> Note the change "-x264opts pass=2:stats=1:..... " for both VBR and CBR.
>
> Where, 'stats=1', '1' is just a temp extensionless name of the file that
> holds the first pass statistics. I've tried to use FFMPEG indirect '-pass
> 1' and '-pass 2'  options, not within -x264opts, and the result was not
> consistent and rather unsuccessful. Once I placed it within the 'x264opts',
> the output result was consistent, even "log" files looked differently from
> the FFMPEG '-pass 1'/'-pass 2' option.
>
> So, at this moment, I'm not sure whether it needs to be considered a bug,
> or something else, but results speak for themselves.
>
> Regards,
> Maxim
>
>
>
>
>
>
> On Mon, Nov 12, 2012 at 10:54 PM, Maxim Levkov <maxim.levkov at gmail.com>wrote:
>
>> Hi Roger,
>>
>> No, not yet. This was on my list, next.
>>
>> Will update in short order.
>>
>> Regards,
>> Maxim
>>
>>
>>
>> On Mon, Nov 12, 2012 at 9:04 PM, Roger Pack <rogerdpack2 at gmail.com>wrote:
>>
>>> > area of POC (picture order count). Hence, I'm not sure if this is an
>>> issue
>>> > that derives from FFMPEG or libx264, it might be the latter, but could
>>> be
>>> > the FFMPEG '-force_key_frames' option. I think POC should be the same
>>> for
>>> > CBR and VBR.
>>>
>>> Have you tried it with the "x264" executable?
>>> _______________________________________________
>>> ffmpeg-user mailing list
>>> ffmpeg-user at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>>
>>
>>
>