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

[Maxim Levkov]

My research has reached its end. I now can call this either a bug or
something else. I have found that the case of CBR and VBR produces the same
results, as I stated before, despite my efforts to contain it. The 'H264'
VBR transcode and CBR transcode, when muxed, in post processing, into
MPEG2-TS, produces two different time basis. Further investigation leads me
to believe that the issue is with FFMPEG  and x264, as in my case I force
the "I-IDR" frames in specific positions and I also force "regular" GOP
interval, in between forced "I-IDR" positions.

The VBR side of the transcode seemed to have a proper output, when I mux it
in post-process with MPEG2-TS muxer, whereas CBR is skewed. The worst part
of this, is that the duration of the CBR video is about a minute shorter
than VBR, which is totally unacceptable. I would have been fine, if both of
them were identical, but seeing such a disparity, leads to believe that
this is an issue for concern, which needs attention of brilliant team at
FFMPEG... ;) Sidepoint, at first I thought that a commercial muxer that I
use had a bug, and up on further analysis, I muxed with various software
packages of open source nature. I get exactly the same results, regardless
of which muxing software that I use.

I'm willing and able to provide any support in resolving this issue. Please
let me know, how I can go about doing that.

Also, Carl! Did all the other information that I provided you over this
"thread" get filed with team at FFMPEG, or I still need to file a full
report?

Best Regards,
Maxim


On Wed, Nov 14, 2012 at 1:19 AM, Maxim Levkov <maxim.levkov at gmail.com>wrote:

> 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
>>>>
>>>
>>>
>>
>