DVS Atomix LT

Developers
guhlda
2011-08-16
2013-04-25
  • guhlda
    guhlda
    2011-08-16

    Hello,

    Has anyone tested Ingex with new DVS Atomix LT boards, as Centaurus II seems to be end-of-life ?

    Guhlda

     
  • John Fletcher
    John Fletcher
    2011-08-16

    Yes, it works fine with Atomix LT

     
  • guhlda
    guhlda
    2011-08-26

    Testing for the first time with an Atomix LT 4 BNC, I had to upgrade to DVS SDK 4.0.1.17.

    As far s I have tested it works fine with Centaurus LT II, but with Atomix, dvs_sdi raises the error SV_ERROR_BUFFER_NOTALIGNED.

    Any idea ?

    Guhlda

     
  • guhlda
    guhlda
    2011-08-29

    Hello,

    Atomix and Centaurus have different DMA alignment needs. I have downloaded latest CVS source (HEAD and MAIN tarball contain the same sources), that supports Atomix boards.

    This source has a lot of differences from ingex 1.0.0 rc1, differences that I have integrated in my own version of 1.0.0 rc1. But it does not compile:

      player/ingex_player/player.c:2795: mls_finalise_blank_sources  was not declared in this scope.

    I guess these are unstable versions ? Do you have a stable branch, that supports Atomix LT boards ?

    Thank you,
    Guhlda

     
  • John Fletcher
    John Fletcher
    2011-08-30

    I recommend you use the CVS HEAD.

     
  • guhlda
    guhlda
    2011-08-30

    OK fine the mls_finalise_blank_sources was my fault, left there during merge.

    Still there are many problems with YUVlib path: it has been moved from ingex/common/YUVlib to ingex/YUVlib, and many source files do #include "yuvlib/YUV_something.h" instead of #include "YUVlib/YUV_something.h".

    May I recommend to remove all leading path (#include "YUV_something.h") and to add YUVlib path to the Makefiles ?

    Here I have a ingex/Makefile.definitions being included by all makefiles, where I define variables for ffmpeg, libMXF, DVS and YUVlib pathes (absolute to avoid problems), libs, etc.. Then changing a path or directive becomes very easy and reflects everywhere.

    Guhlda

     
  • John Fletcher
    John Fletcher
    2011-08-30

    Yes, we moved the location of YUVlib some time ago.  if you use current CVS head and follow the build instructions, you should have no problems.  YUVlib gets installed to /usr/local/include/yuvlib/

     
  • guhlda
    guhlda
    2011-08-30

    OK I understand. In my case, I don't want to compile against an installed yuvlib, but against the lib compiled in the source, which is also under source control (CVS) and tagged commonly (all source, libs and modules are tagged for the same version). This also ensures that you don't compile an new version against an old yuvlib..

    I have the same for ffmpeg, DVS… This situation is better handled by defining paths in makefiles, where you can define the YUVLIB_INCLUDE as a path to installed include files or to the CVS sources…

    Guhlda

     
  • guhlda
    guhlda
    2011-08-30

    Another problem: latest player does not insert timecodes (VITC, DVITC, LTC, DLTC) to SDI out, while the old (1..0.0-rc1) compiled with the same DVS driver 4.0.1.17 & patched ffmpeg does..

    When debugging dvs_sink.c (line 1516), vitcCount and ltcCount remain null, unless I set -extra-vitc. Where should I look ?

     
  • John Fletcher
    John Fletcher
    2011-08-31

    Regarding YUVlib, I understand your point of view but we preferred to treat YUVlib as an independent library, much like the many others we use - xerces-c, libjpeg etc.  In the future, we will probably put YUVlib and libMXF in separate source code repositories.

    Thanks for the hints regarding timecode output.  What kind of file or shared memory were you playing?

     
  • Philip de Nier
    Philip de Nier
    2011-08-31

    The cvs (dvs_sink.c) has been updated to fix the missing timecode issue.

    Philip

     
  • guhlda
    guhlda
    2011-08-31

    Thank you Philip for your quick fix.

    It works, but I had to add another fix (that I had already in my 1.0.0-rc) related to the source timecode subtype (what is it ?). I'm playing a MPEG TS file using -ffmpeg, and apparently the timecode subtpye is NO_TIMECODE_SUBTYPE. So I added the following code in dvs_sink.c:

    static Timecode get_timecode(DVSSink* sink, TimecodeType type, TimecodeSubType subType, const Timecode* theDefault)
    {
        int i;
        for (i = 0; i < sink->numTimecodes; i++)
        {
            if (sink->timecodes[i].isPresent &&
                sink->timecodes[i].timecodeType == type &&
                sink->timecodes[i].timecodeSubType == subType)
            {
                return sink->timecodes[i].timecode;
            }
        }
        //@ Start add guhlda
        for (i = 0; i < sink->numTimecodes; i++)
        {
            if (sink->timecodes[i].isPresent &&
                sink->timecodes[i].timecodeType == type &&
                sink->timecodes[i].timecodeSubType == NO_TIMECODE_SUBTYPE)
            {
                return sink->timecodes[i].timecode;
            }
        }
        //@ End add guhlda
        return *theDefault;
    }
    static int get_timecode_count(DVSSink* sink, TimecodeType type, TimecodeSubType subType, int theDefault)
    {
        int i;
        for (i = 0; i < sink->numTimecodes; i++)
        {
            if (sink->timecodes[i].isPresent &&
                sink->timecodes[i].timecodeType == type &&
                sink->timecodes[i].timecodeSubType == subType)
            {
                return sink->timecodes[i].timecode.hour * 60 * 60 * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.min * 60 * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.sec * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.frame;
            }
        }
        //@ Start add guhlda
        for (i = 0; i < sink->numTimecodes; i++)
        {
            if (sink->timecodes[i].isPresent &&
                sink->timecodes[i].timecodeType == type &&
                sink->timecodes[i].timecodeSubType == NO_TIMECODE_SUBTYPE)
            {
                return sink->timecodes[i].timecode.hour * 60 * 60 * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.min * 60 * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.sec * sink->roundedTimecodeBase +
                    sink->timecodes[i].timecode.frame;
            }
        }
        //@ End add guhlda
        return theDefault;
    }
    
     
  • Philip de Nier
    Philip de Nier
    2011-08-31

    frame_info.h list the enumerations for TimecodeType and TimecodeSubType. In Ingex the source timecode is the timecode from the camera or timecode generator.

    In ffmpeg_source.c, open_timecode_stream, the assumption is made that the timecode is a source timecode. However, it isn't assumed to be VITC or LTC and therefore the sub-type is set to be unknown.

    It may be better to call using this

    get_timecode_count(sink, SOURCE_TIMECODE_TYPE, NO_TIMECODE_SUBTYPE, 0)
    

    rather than change the implementation of get_timecode(_count)

    Also, you may want to change the default like this in dvs_complete_frame,

        if (sink->sdiVITCSource == VITC_AS_SDI_VITC)
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, VITC_SOURCE_TIMECODE_SUBTYPE, 0);
            fifoBuffer->vitcTimecode = get_timecode(sink, SOURCE_TIMECODE_TYPE, VITC_SOURCE_TIMECODE_SUBTYPE, &defaultTC);
        }
        else if (sink->sdiVITCSource == LTC_AS_SDI_VITC)
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, LTC_SOURCE_TIMECODE_SUBTYPE, 0);
            fifoBuffer->vitcTimecode = get_timecode(sink, SOURCE_TIMECODE_TYPE, LTC_SOURCE_TIMECODE_SUBTYPE, &defaultTC);
        }
        else
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, NO_TIMECODE_SUBTYPE, frameInfo->position % maxTCCount);
            fifoBuffer->vitcTimecode = get_timecode_from_count(sink, vitcCount);
        }
    

    You may also want to do the same with LTC.

    Philip

     
  • guhlda
    guhlda
    2011-08-31

    OK I understand. So I will NOT modify get_timecode & get_timecode_count, but then I have the following in dvs_sdi.c as an alternative to your example (which does not really work):

        vitcCount = -1;
        /* set the VITC and LTC timecodes associated with the frame buffer */
        if (sink->sdiVITCSource == VITC_AS_SDI_VITC)
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, VITC_SOURCE_TIMECODE_SUBTYPE, -1); //@ -1 instead of 0
            fifoBuffer->vitcTimecode = get_timecode(sink, SOURCE_TIMECODE_TYPE, VITC_SOURCE_TIMECODE_SUBTYPE, &defaultTC);
            printf("@@ VITC_AS_SDI_VITC: vitcCount=%u\n", vitcCount);
        }
        else if (sink->sdiVITCSource == LTC_AS_SDI_VITC)
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, LTC_SOURCE_TIMECODE_SUBTYPE, -1);  //@ -1 instead of 0
            fifoBuffer->vitcTimecode = get_timecode(sink, SOURCE_TIMECODE_TYPE, LTC_SOURCE_TIMECODE_SUBTYPE, &defaultTC);
            printf("@@ LTC_AS_SDI_VITC: vitcCount=%u\n", vitcCount);
        }
        if (vitcCount == -1)
        {
            vitcCount = get_timecode_count(sink, SOURCE_TIMECODE_TYPE, NO_TIMECODE_SUBTYPE, -1);
            if (vitcCount == -1)
            {
                vitcCount = frameInfo->position % maxTCCount;
                printf("@@ DEFAULT: vitcCount=%u (position)\n", vitcCount);
            }
            else
                printf("@@ DEFAULT: vitcCount=%u (NO_TIMECODE_SUBTYPE)\n", vitcCount);
            fifoBuffer->vitcTimecode = get_timecode_from_count(sink, vitcCount);
        }
    

    What do you think of this solution ?
    Guhlda

     
  • Philip de Nier
    Philip de Nier
    2011-08-31

    Maybe my code didn't work because the default is VITC_AS_SDI_VITC in player.c. Maybe SDIVITCSource needs another enumeration SOURCE_TC_AS_SDI_VITC as default and a player option to select source timecode. Maybe even more for other cases…
    With your implementation you are assuming that when a user selects -ltc-as-vitc for example that they could get a source timecode or frame count instead if there is no LTC. Not sure whether that would be better than outputting timecode 0, which indicates that there is no LTC.

    Philip

     
  • guhlda
    guhlda
    2011-08-31

    Additional question about timecodes: there is vitcCount that goes to SDI DVITC. There is also ltcCount, is it used to feed LTC separate output, or DLTC ? can you give me a short explanation ?

     
  • Philip de Nier
    Philip de Nier
    2011-08-31

    dvs_sink.c outputs ltcCount to DVS's "analogue" output:

    pbuffer->timecode.ltc_tc = fifoBuffer->ltcCount;
    

    I guess adding something like this will get you DLTC:

    pbuffer->anctimecode.dltc_tc = fifoBuffer->ltcCount;
    

    The same applies to DVITC.

    All this timecode stuff originated from the ingex archive work where both LTC and VITC timecodes where embedded in the VBI and read using the PALFF user module. That's why the code in dvs_sink.c is somewhat limited to that use case.

    Philip

     
  • guhlda
    guhlda
    2011-08-31

    If I understand well, VITC_AS_SDI_VITC poses for "embedded TC" when the source is a SDI in (-shm-in, thus DVITC in reality) ?
    Then, if the source is a file, VITC_AS_SDI_VITC could be understood as the "embedded TC" too ? In that case we don't need to add a SOURCE_TC_AS_VITC, but to handle VITC_AS_SDI_VITC for both cases (SDI or file source), right ?

    Guhlda

     
  • Philip de Nier
    Philip de Nier
    2011-08-31

    I don't consider VITC to pose as the "embedded TC". A source timecode is identified as VITC if it originated from a source as VITC.

    The Ingex Archive MXF file contains a pair of timecodes at the start of every frame. That pair consists of the ingested VITC and LTC, where the LTC was embedded in the VBI on another line alongside the existing VITC.

    VITC_AS_SDI_VITC was therefore created to route the Ingex Archive file's VITC out to the SDI VITC (in the VBI, not ancillary data). LTC_AS_SDI_VITC routed the LTC out to the SDI VITC.

    Only Ingex Archive MXF files and the shared memory source (shm) have their timecodes identified as VITC/LTC/DVITC/DLTC. Other files (MXF or read using the -ffmpeg option) have a source timecode that isn't identified as VITC/etc. because it is unknown where they originated from.

    Philip

     
  • guhlda
    guhlda
    2011-09-19

    I have integrated support for Atomix LT 4BNC, which is slightly different than Atomix LT. The later has AES channels 1-8 + 9-16, while the former only has 9-16 that have to be mapped to 1-8.

    For this I have:
    - integrated DVS SDK 4.0.2.17
    - added -aes0:8 and -aes8:0 flags to dvs_sdi.c audio routing,
    - modified dvs_sink.c FIFO initialization according to SDK new constraint, namely calling sv_black() (needed for all cards).

    I have also extended player's timecode source specs as discussed above:

     --ltc-src <type>       Select the source timecode to output on LTC (XLR out) and DLTC (ANC) (default NONE):
      --vitc-src <type>      Select the source timecode to output on VITC/DVITC (default ALL):
                                 ALL:   all timecodes types
                                 VITC:  vertical interval timecode
                                 LTC:   linear timecode
                                 SYS:   system time
                                 COUNT: frame count
                                 NONE:  00:00:0:00
    

    Then -ltc-as-vitc becomes obsolete (same as -vitc-src LTC), as well as -count-as-vitc (same as -vitc-src COUNT). These definitions might still evolve.

    Are you interested in these code changes ?

    Guhlda

     
  • John Fletcher
    John Fletcher
    2011-09-20

    Yes, we are interested.  Please send me the patches.

    Thanks - John