機能追加
  • UMxx: QuickTime 版のエンコーダを追加した。
性能向上
  • UMxx: 全体的に高速化した。
バグ修正
  • ULxx: エンコーダに誤った設定をしてもエラーを返さなかった。

readme 日本語 英語 / ライセンス (GPLv2) 日本語 英語
バイナリ Windows (exe) Mac (zip) / ソース / GitHub

19.0.1 のリリースの時に QuickTime エンコーダがうまく動かないと書きましたが、もうちょっと調べてみたら UMxx 固有の問題ではなかったようで、 UMxx だけリリースしない理由がなくなったので追加しました。動かない理由は調査中です。

高速化の成果ですが、測定パターンにもよりますが 10%~20% 程度です。今は力尽きたのでグラフは省略します。測定結果を見る限りあと15%ぐらいは高速化できそうですが、そのためには読みづらいコードを書く必要があると思われるのでやめておきます。

Trackback

5 comments untill now

  1. Fernando vidigal @ 2018-01-23 07:07

    Hi,

    Any chance that you could add in the near future support for more 10+ bit depth formats like P210 and v410 for instance?
    Now that VirtualDub FilterMod as included support for more 10/16 bit formats like p010,P016,p210,P216, v410 and more it was quite important to have support from a fast codec like utvideo that could add to a more efficient ecosystem providing a better and more strong support to 10 bit formats now easily provided by a lot of capture cards.
    Thanks and I do hope that adding support to more 10 bit formats (not only v210) is part of your future strategy.

  2. 梅澤 威志 @ 2018-01-24 00:20

    To add support of input/output from/to 10bit+ formats (like P210, YUV422P10, etc), there should be:
    – A free (that is, open source) NLE software that pass frames with the formats to/from codecs.
    and
    – A free software framework that can generate test video clips with the formats. (see https://github.com/umezawatakeshi/utvideo-testclip)
    and
    – Of course, my passion and your passion.

    For 8bit formats, I use VirtualDub (and its forks) for first purpose and use VirtualDub and AviSynth for second purpose.

    If you know such software, please let me know.

    In addition, please see the discussion in https://github.com/umezawatakeshi/utvideo/issues/16

  3. Fernando vidigal @ 2018-01-24 07:51

    Thanks for the quick answer.

    About the resources needed
    1- A free (that is, open source) NLE software that pass frames with the formats to/from codecs.

    I can be wrong but I thought that VirtualDub FilterMod from version 18 update 2 (build 40879) do provide support for formats: P010, P210, P016, P216, v410 , y410 (input/output) and currently as fixed some problems within the P210 format that was not working correctly. I can for instance output P210 from my capture card and compress on the fly during capture P210->YUV422P16 to several formats like FFmpeg/FFv1 10 bit, FFmpeg /huufyuv variant 10 bit, x264 and x265 10 bit and vice versa from 10 bit ffv1, Huufyuv, x264,x265 etc to raw YUV uncompressed video v210 or 422 YCbCr 16 bit. The same applies to P010, V410 and Y410 using intermediate 16 bit versions to any codec currently supported and vice versa. I don’t know if this it’s enough.

    2- A free software framework that can generate test video clips with the formats

    I don’t know exactly what you do need for this but if you do need video clips with different W x H and formats/codecs / containers I will be more than happy to try to provide all the clips that you eventually may need , please contact me directly and tell me what test clips you do need . I will be ready to test also any beta version you may provide. If I can help in any other way please do tell me I will try my best even if i am only a user not a dev.

    I have helped the VDFM DEV( shekh ) to test the P210 support now it´s working , but output Y3[10][10] to file is still yet not supported I think.

  4. 梅澤 威志 @ 2018-01-25 14:53

    > 1- A free (that is, open source) NLE software that pass frames with the formats to/from codecs.
    > I thought that VirtualDub FilterMod from version 18 update 2 (build 40879) do provide support
    That’s a good news. I will look into it.

    > 2- A free software framework that can generate test video clips with the formats
    > I don’t know exactly what you do need for this
    Oops, sorry.
    The framework must have following features:
    – Can create clips with exact pixel values from image file sequence (like PNG). Image files may be generated programatically by other framework.
    – Can create clips with exact pixel values programatically (by using SetPixel, for example) — each pixel need 10bit exact value, for example, not 16bit, and vice versa.
    AviSynth (or AviSynthPlus) + VirtualDub FilterMod work fine for 8bit formats. But not sufficient for 10bit+ formats (when I examined before).

    Test clips for unit test may depends on internal structure of codecs, in order to test corner cases. The number of test clips will be vast and clips should be generated systematically.
    Thanks for the offer, but I think that getting you to create test clips is unrealistic.

  5. Fernando vidigal @ 2018-01-26 10:09

    Well I see, the second requirement could be more problematic, however

    from your previous contact with VDFM Dev

    “would be better if output Y3[10][10] to file is supported
    What is possible use for such file? Why do you want it?
    However it is not a big deal, I can put it in “other formats” list in the “pixel format” dialog.
    Output P210 to codec: do you want it? I suspended implementation because there was nothing to gain”

    It seems Shekh has fixed both, in this case I misled you as it´s possible to convert from lossless 10+ bit formats to 10 bit or 16 uncompressed not only 16 bit

    Formats supported
    https://we.tl/ZuMH5ixVSr

    Perhaps this is enough for you.

    If not I think that if you let him know what exactly yours requirements are to be able to support 10+ bit formats, with your codec that he will be willing to help (if there is not too much effort involved of course). I think it can be definitely beneficial in first place obviously for end users but also for both of you as a flexible and strong application as a base for captures and tests with your codec is certainly interesting for you and the VDFM application itself and his dev as to gain with a fast codec support that do allow lossless live captures at high bit depths , high resolutions or high frame rates (where the files are huge and the gain could be tremendous ) this could create a momentum and help to definitely launch a new ecosystem able to support high bit depths formats very much needed at the present time.

Add your comment now