Issue 124 in ffmbc: FFmbc bitrate control

[ff...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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

[ff...@googlecode.com]

Comment #1 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

I will need the source file

[ff...@googlecode.com]

Comment #2 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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.pdf
and confirm you are able to comply with the Copyright licence.

[ff...@googlecode.com]

Comment #3 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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

[ff...@googlecode.com]

Comment #4 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

Sure the copyright is fine

[ff...@googlecode.com]

Comment #5 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

Replied via email.

[ff...@googlecode.com]

Comment #6 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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

[ff...@googlecode.com]

Comment #7 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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/mpeg2videotools/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).

[ff...@googlecode.com]

Comment #8 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

What's $OFFSET here ?

[ff...@googlecode.com]

Comment #9 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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

[ff...@googlecode.com]

Comment #10 on issue 124 by cy.thomp...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

Non-black motion video, I meant.

[ff...@googlecode.com]

Updates:
Status: Invalid

Comment #11 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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.

[ff...@googlecode.com]

Updates:
Status: Accepted

Comment #12 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

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

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ff...@googlecode.com]

Updates:
Status: Fixed

Comment #13 on issue 124 by baptiste...@gmail.com: FFmbc bitrate control
http://code.google.com/p/ffmbc/issues/detail?id=124

Should be fixed in rc8