0

rvio ffmpeg -> libx264 and prores

Martin Kenzel

September 01, 2015 14:28

None

Follow

I am using rvio on Win7 x64 and I was wondering how I could access some of the options provided by ffmpeg and libx264, specifically the crf parameter. So far I can successfully pass parameters like level and profile and every other parameter that is documented when I run "rvio -formats", but the crf value doesnt seem to be among them (which isnt suprising since the -formats seems to show only the .mov specific parameters?)

so far my commandline is sometling like:

rvio image.tif -codec libx264 -outparams profile=144 -level=31 vcc:qmin=11 vcc:qmax=51  etc.

 

but there doesnt seem to be a parameter for the crf value. If i try the logical solution "vcc:crf=15" ffmpeg outputs "Could not match option: vcc:crf".

 

Is there a way to somehow pass parameters to ffmpeg or x264 directly that are not exposed in the rvio-formats documentation? The method described in this thread:  https://tweaksoftware.zendesk.com/entries/464107-h264-codec-on-osx-not-working-  doesnt seem to apply to ffmpeg/libx264.

 

On a side note: is there a way to use all codecs offered by ffmpeg or are only a selected few supported by rvio? The "image codecs" section doesn't list libx264 or mpeg4 although they run fine from within rvio . Then again the codecs prores, prores_aw or prores_ks are not available from within rvio while they run perfectly with a standalone installation of ffmpeg.

• Facebook
• Twitter
• LinkedIn

11 comments

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  I believe that the crf is set on the AVCodec (vc == video track's AVCodec) and not the AVCodecContext (vcc == video track's AVCodecContext). Please try:

  rvio image.tif -codec libx264 -outparams profile=144 -level=31 vcc:qmin=11 vcc:qmax=51 vc:crf=15

  As far as a complete listing of supported codecs goes there isn't really one place that they are all reported. We highlight the ones we support in the -formats output but as you discovered there are more that we support and do not document. We do not compile ffmpeg with all of the possible extra codecs like libvpx, libvorbis, etc compiled in. However you can extend the support for some other if you follow the directions in the src/mio_ffmpeg/README file within your RV install. We leave it up to you to get licenses for the codecs which are patented should you choose to recompile with support enabled.

  Please let us know if there is anything else we can help with.

  Thanks,
  Jon

• 0
  
  Martin Kenzel September 03, 2015 07:39

  Thank you for pointing out the AVCodec vs AVCodecContext thing. I guess all "private" options of a codec would be in the vc then.

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  I believe so. The same is true for "ac:" and "acc:" when you are passing audio parameters.

  Thanks,
  Jon

• 0
  
  Martin Kenzel September 03, 2015 07:39

  I have one more question about libx264 colorspace handling: The files I write look off in QT player of course (the known YUV - RGB conversion stuff) and I was wondering if I could fix this by setting my colorspace to RGB (guessing that 709 is interpreted as legacy range by QT).

  But as you already reported here: http://ffmpeg.org/pipermail/ffmpeg-devel/2014-November/165185.html  it is not possible to set the colorspace to index 0 (rgb) from within ffmpeg. Has this been fixed by the ffmpeg devs already or is there any workaround by passing this flag to libx264 directly via vcc:x264-params?

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  That patch of mine has been included in ffmpeg now as well as in any released versions of RV/RVIO. You can certainly change that value when using RVIO, but it appears to have no impact in the libavcodec + libswscale output. If you can send me some samples as well as the commands you used to create them I can take a closer look. I am in the middle of testing our movie plugin using ffmpeg 2.5 which might change the results as well. Now would be a good time to check.

  Thanks,
  Jon

• 0
  
  Martin Kenzel September 03, 2015 07:39

  Thank you for your reply Jon!

  Unfortunately I get the error:
  ERROR [16]: MovieFFMpeg: Value 0.000000 for parameter 'colorspace' out of range [1 - 10]
  WARNING: MovieFFMpeg: Unable to set 'colorspace' to '0'.
  WARNING: MovieFFMpeg: Could not match option: 'vcc:colorspace'

  both with rvio_hw 4.2.3 and 4.2.4. The commandline I used was:

  rvio_hw.exe "file.#.tif" -codec libx264 -outparams vcc:colorspace=0 -o "file.mov"

  setting vcc:colorspace to 1 works, but is recognized as REC709 (like it should be I guess)

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  Well this is embarrassing. It looks like I did not get that patch into our windows version. Since our next release will hopefully have the 2.5 branch of ffmpeg in it my patch will be included on all platforms. If it doesn't have 2.5 we will back patch windows as well.

  Sorry,
  Jon

• 0
  
  Martin Kenzel September 03, 2015 07:39

  Hey Jon,

  I just tried with ffmpeg 2.5.3 directly and it seems to work indeed.

  As you mentioned it does not seem to have any impact on the output file though. I was hoping that Quicktime would finally display my file in full range on default. But comparing files written with ffmpeg and QT the main difference seems to be the missing "colr" / "nclc" atom in the ffmpeg output. Oddly the values stored in this atom seem be exactly the ones I can define in libx264 via colorspace, color_primaries and color_trc. But I'm guessing that libx264 stores those values in some place inaccessible to the Quicktime player? In that regard this recent ffmpeg commit seems interesting: https://www.mail-archive.com/ffmpeg-cvslog@ffmpeg.org/msg06541.html

  since it is newer than the 2.5.3 release I doubt that it is included in the latest ffmpeg build though.

  thank you for answering all my questions so quickly!

  Martin

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  Thank you for pointing out that patch. We have already incorporated atom support through an additional library. That change by ffmpeg might cause conflicts in later updates. Thank you for the heads up.

  For the record, if you set the color space, the primaries, and the transfer function in the video codec context (vcc) that is where we will look when writing H.264 mov files' colr atoms. Which is definitely something QuickTime should see. My concern is that ffmpeg/x264 is not properly encoding the video to match the metadata and that is why it looks wrong.

  Do you have anything with which you can inspect atom values?

  Thanks,
  Jon

• 0
  
  Martin Kenzel September 03, 2015 07:39

  Hi Jon,

  you are right, rvio does embed exactly the same atom information as Quicktime (checked under Windows with AtomBox).

  Oddly enough - when I write a h264 mov with rvio and export it from Quicktime again the two movs look different. While the rv export holds the correct color values, qt seems to apply another colorspace transformation which results in a loss of brightness, especially in the green channel (g=255 becomes g=210)

  A plausible explanation for that would be Qt calculating Y for Rec. 601, where the green channel is weighted with approx. 0.82 times the intensity of Rec. 709's luma (0.587*g vs. 0.7152*g).

  The odd thing here is that this happens regardless of the colr atom being present or not. I tested it with (a): a file with no colr atom exported via ffmpeg and (b): a file written via rvio with rec709 in "colr". Quicktime seems to think that both files are in Rec. 601 colorspace though (tested with QT7 under Windows).

• 0
  
  Jon Morley September 03, 2015 07:39

  Hi Martin,

  Thank you for the report. I am not surprised sadly. I have not done a good job describing the situation in our discourse, but I will try again. I think the main issue is the metadata is not strictly connected to the imagery data. In fact you can strip or add COLR atoms at any time which would not make any changes to the encoded video tracks.

  Not all players respect the COLR atom. As you pointed out ffmpeg is still in the process of introducing some support there. We use an alternate library (at least until ffmpeg adds support) for handling the COLR and other color atoms (like ACLR for DNxHD/AVID QuickTime). We get consistent results across each platform we support with this system, but the QuickTime 7 player does not seem consistent in our testing between each platform. Again this was a big motivator for us to get away from that library (not to mention it was keeping us from 64-bit). I simply don't think there is a magic metadata setting that will get all of Apple's players to produce the same imagery.

  Thanks,
  Jon