FFmbc bitrate control

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ffmbc -i uncompressed.mov - vcodec prores -profile hq output.mov
2. calculate the PSNR for the given frames in accordance with ITU J.247

What is the expected output? What do you see instead?

For all videos, when the encoded video's PSNR is calculated in accordance with 
ITU J.247 [1], the first 30 frames have a PSNR of 50 dB (the maximum allowed in 
J.247).  See image [2].

The first scene in this particular video is a complex scene containing lots of 
multi-coloured elements lasting 250 frames, there is no significant difference 
in the first 30 frames and the last 220.

I am wondering why the objective measurement of picture quality changes after 
30 frames?  Could there be a fault with the allocation of bitrate throughout 
the video

What version of the product are you using? On what operating system?

0.7-rc7 on 64 bit Debian Linux

[1] http://www.itu.int/rec/T-REC-J.247-200808-I/en
[2] http://farm9.staticflickr.com/8197/8185117917_0a5bbdd5e9_o.png

Original issue reported on code.google.com by cy.thomp...@googlemail.com on 14 Nov 2012 at 3:41

[GoogleCodeExporter]

I will need the source file

Original comment by baptiste...@gmail.com on 15 Nov 2012 at 9:40

[GoogleCodeExporter]

The source material is from a standard test sequence.  Before I make it 
available, could you read: 
http://tech.ebu.ch/webdav/site/tech/shared/hdtv/svt-multiformat-conditions-v10.p
df and confirm you are able to comply with the Copyright licence.

Original comment by cy.thomp...@googlemail.com on 20 Nov 2012 at 2:37

[GoogleCodeExporter]

For further information, I've uploaded a graph of FFmbc Pro-Res HQ vs Apple 
Pro-Res HQ.  It can be seen that the overall quality seems to be fractionally 
less, which could be accounted for by the (presumed) bitrate spike at the start.

http://farm9.staticflickr.com/8070/8203473534_004a3bd68f_o.png

Original comment by cy.thomp...@googlemail.com on 20 Nov 2012 at 3:41

[GoogleCodeExporter]

Sure the copyright is fine

Original comment by baptiste...@gmail.com on 21 Nov 2012 at 10:50

[GoogleCodeExporter]

Replied via email.

Original comment by cy.thomp...@googlemail.com on 22 Nov 2012 at 4:31

[GoogleCodeExporter]

This file has black frames at the beginning, and that's why you have so high 
PSNR at the beginning. I'm investigating.

Original comment by baptiste...@gmail.com on 6 Dec 2012 at 7:54

[GoogleCodeExporter]

The psnr tool uses the first frame of motion video in the original file 
($OFFSET) and hunts through the first 1750 frames of the encoded video file for 
the frame that matches most.  It then uses this frame to create the ITU J.247 
compliant PSNR output.

START_POSN=`calcpsnr -g $FRAME_SIZE -l 1750 -z 1 -s $OFFSET,0 $ORIG_FILE 
"$WORK_FILE".yuv|sed -n '/Best Y diff/ {s/.*frame = //;s/, .*//;p}'`

calcpsnr -j247 -g $FRAME_SIZE -w t2b2l2r2 -b -l $NUM_FRAMES -s 
$OFFSET,$START_POSN $ORIG_FILE "$WORK_FILE".yuv > "$WORK_FILE".psnr

calcpsnr is available at: 
http://mpeg2videotools.cvs.sourceforge.net/viewvc/mpeg2videotools/mpeg2videotool
s/src/calcpsnr/

UYVY files are created using something like:
mencoder -demuxer lavf -nosound -ovc raw -of rawvideo "$WORK_FILE" -o 
"$WORK_FILE".yuv

The graph shown contains the correct number of motion video frames (and matches 
the number of Frames created when using the proprietary Pro-Res encoder).

Original comment by cy.thomp...@googlemail.com on 7 Dec 2012 at 11:10

[GoogleCodeExporter]

What's $OFFSET here ?

Original comment by baptiste...@gmail.com on 8 Dec 2012 at 9:58

[GoogleCodeExporter]

Offset = num of frames to first frame of video in original

Original comment by cy.thomp...@googlemail.com on 8 Dec 2012 at 11:22

[GoogleCodeExporter]

Non-black motion video, I meant.

Original comment by cy.thomp...@googlemail.com on 8 Dec 2012 at 11:23

[GoogleCodeExporter]

Ok, to compare accurately, I took the source file and encoded it using FCP.
I then encoded the same source file with ffmbc and then used calcpsnr.
I use ffmbc -i <file> -pix_fmt uyvy422 <file.yuv> to create yuv files.
FFmbc is constantly 1 db PSNR higher than Apple, so I cannot reproduce what you 
are seeing.
The Apple encoded file you sent me if unaligned so is not suitable for testing.

Original comment by baptiste...@gmail.com on 9 Dec 2012 at 1:44

• Changed state: Invalid

[GoogleCodeExporter]

Actually I was wrong, apple encoder was better, but I fixed that and it is now 
better

Original comment by baptiste...@gmail.com on 7 Mar 2013 at 6:38

• Changed state: Accepted

[GoogleCodeExporter]

Should be fixed in rc8

Original comment by baptiste...@gmail.com on 14 Mar 2013 at 9:04

• Changed state: Fixed