Recherche avancée

Sur d’autres sites (4031)

• "error C2400 : inline assembler syntax error in ‘opcode’" pxor compiling ffmpeg with mmx flag enabled

  4 octobre 2013, par Kristofer

  I'm trying to compile (visual studio 2005) ffmpeg with mmx flag enabled (HAVE_MMX) but get the following error :
  "error C2400 : inline assembler syntax error in ‘opcode’"
  And it's complaining about xpor_r2r

  Ideas ?

  [Update]
  Jester pointed out that it's probably a problem with the macro :

  #define         mmx_r2r(op,regs,regd) \
       __asm__ volatile (#op " %" #regs ", %" #regd)

  Directly using :
  __asm__ pxor mm7 mm7 works
  Adding volatile (as in the macro mentioned) gives the same error, syntax error as before in 'opcode' found 'data_type'.

  Just removing volatile from the macro does not work, instead gives error in 'opcode' found '('

  Removing the paranthesis instead gives error in 'opcode' found 'bad_token'

• FFmpeg avcodec_decode_video2 decode RTSP H264 HD-video packet to video picture with error

  29 mai 2018, par Nguyen Ba Thi

  I used FFmpeg library version 4.0 to have simple C++ program, in witch is a thread to receive RTSP H264 video data from IP-camera and display it in program window.

  Code of this thread is follow :

  DWORD WINAPI GrabbProcess(LPVOID lpParam)
  
  // Grabbing thread
  
  {
  
    DWORD i;
  
    int ret = 0, nPacket=0;
  
    FILE *pktFile;
  
    // Open video file
  
    pFormatCtx = avformat_alloc_context();
  
    if(avformat_open_input(&pFormatCtx, nameVideoStream, NULL, NULL)!=0)
  
        fGrabb=-1; // Couldn't open file
  
    else
  
    // Retrieve stream information
  
    if(avformat_find_stream_info(pFormatCtx, NULL)<0)
  
        fGrabb=-2; // Couldn't find stream information
  
    else
  
    {
  
        // Find the first video stream
  
        videoStream=-1;
  
        for(i=0; inb_streams; i++)
  
          if(pFormatCtx->streams[i]->codec->codec_type==AVMEDIA_TYPE_VIDEO)
  
          {
  
            videoStream=i;
  
            break;
  
          }
  
        if(videoStream==-1)
  
            fGrabb=-3; // Didn't find a video stream
  
        else
  
        {
  
            // Get a pointer to the codec context for the video stream
  
            pCodecCtxOrig=pFormatCtx->streams[videoStream]->codec;
  
            // Find the decoder for the video stream
  
            pCodec=avcodec_find_decoder(pCodecCtxOrig->codec_id);
  
            if(pCodec==NULL)
  
                fGrabb=-4; // Codec not found
  
            else
  
            {
  
                // Copy context
  
                pCodecCtx = avcodec_alloc_context3(pCodec);
  
                if(avcodec_copy_context(pCodecCtx, pCodecCtxOrig) != 0)
  
                    fGrabb=-5; // Error copying codec context
  
                else
  
                {
  
                    // Open codec
  
                    if(avcodec_open2(pCodecCtx, pCodec, NULL)<0)
  
                        fGrabb=-6; // Could not open codec
  
                    else
  
                    // Allocate video frame for input
  
                    pFrame=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(pCodecCtx->pix_fmt, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrame
  
                    // Note that pFrame is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrame, buffer, pCodecCtx->pix_fmt,
  
                        pCodecCtx->width, pCodecCtx->height);
  
  
  
                    // Allocate video frame for display
  
                    pFrameRGB=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(AV_PIX_FMT_RGB24, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    bufferRGB=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrameRGB
  
                    // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrameRGB, bufferRGB, AV_PIX_FMT_RGB24,
  
                        pCodecCtx->width, pCodecCtx->height);
  
                    // initialize SWS context for software scaling to FMT_RGB24
  
                    sws_ctx_to_RGB = sws_getContext(pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        pCodecCtx->pix_fmt,
  
                        pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        AV_PIX_FMT_RGB24,
  
                        SWS_BILINEAR,
  
                        NULL,
  
                        NULL,
  
                        NULL);
  
  
  
                    // Allocate video frame (grayscale YUV420P) for processing
  
                    pFrameYUV=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(AV_PIX_FMT_YUV420P, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    bufferYUV=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrameYUV
  
                    // Note that pFrameYUV is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrameYUV, bufferYUV, AV_PIX_FMT_YUV420P,
  
                        pCodecCtx->width, pCodecCtx->height);
  
                    // initialize SWS context for software scaling to FMT_YUV420P
  
                    sws_ctx_to_YUV = sws_getContext(pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        pCodecCtx->pix_fmt,
  
                        pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        AV_PIX_FMT_YUV420P,
  
                        SWS_BILINEAR,
  
                        NULL,
  
                        NULL,
  
                        NULL);
  
                  RealBsqHdr.biWidth = pCodecCtx->width;
  
                  RealBsqHdr.biHeight = -pCodecCtx->height;
  
                }
  
            }
  
        }
  
    }
  
    while ((fGrabb==1)||(fGrabb==100))
  
    {
  
        // Grabb a frame
  
        if (av_read_frame(pFormatCtx, &packet) >= 0)
  
        {
  
          // Is this a packet from the video stream?
  
          if(packet.stream_index==videoStream)
  
          {
  
              // Decode video frame
  
              int len = avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
  
              nPacket++;
  
              // Did we get a video frame?
  
              if(frameFinished)
  
              {
  
                  // Convert the image from its native format to YUV
  
                  sws_scale(sws_ctx_to_YUV, (uint8_t const * const *)pFrame->data,
  
                      pFrame->linesize, 0, pCodecCtx->height,
  
                      pFrameYUV->data, pFrameYUV->linesize);
  
                  // Convert the image from its native format to RGB
  
                  sws_scale(sws_ctx_to_RGB, (uint8_t const * const *)pFrame->data,
  
                      pFrame->linesize, 0, pCodecCtx->height,
  
                      pFrameRGB->data, pFrameRGB->linesize);
  
                  HDC hdc=GetDC(hWndM);
  
                  SetDIBitsToDevice(hdc, 0, 0, pCodecCtx->width, pCodecCtx->height,
  
                      0, 0, 0, pCodecCtx->height,pFrameRGB->data[0], (LPBITMAPINFO)&RealBsqHdr, DIB_RGB_COLORS);
  
                  ReleaseDC(hWndM,hdc);
  
                  av_frame_unref(pFrame);
  
              }
  
          }
  
          // Free the packet that was allocated by av_read_frame
  
          av_free_packet(&packet);
  
        }
  
     }
  
     // Free the org frame
  
    av_frame_free(&pFrame);
  
    // Free the RGB frame
  
    av_frame_free(&pFrameRGB);
  
    // Free the YUV frame
  
    av_frame_free(&pFrameYUV);
  
  
  
    // Close the codec
  
    avcodec_close(pCodecCtx);
  
    avcodec_close(pCodecCtxOrig);
  
  
  
    // Close the video file
  
    avformat_close_input(&pFormatCtx);
  
    avformat_free_context(pFormatCtx);
  
  
  
    if (fGrabb==1)
  
        sprintf(tmpstr,"Grabbing Completed %d frames", nCntTotal);
  
    else if (fGrabb==2)
  
        sprintf(tmpstr,"User break on %d frames", nCntTotal);
  
    else if (fGrabb==3)
  
        sprintf(tmpstr,"Can't Grabb at frame %d", nCntTotal);
  
    else if (fGrabb==-1)
  
        sprintf(tmpstr,"Couldn't open file");
  
    else if (fGrabb==-2)
  
        sprintf(tmpstr,"Couldn't find stream information");
  
    else if (fGrabb==-3)
  
        sprintf(tmpstr,"Didn't find a video stream");
  
    else if (fGrabb==-4)
  
        sprintf(tmpstr,"Codec not found");
  
    else if (fGrabb==-5)
  
        sprintf(tmpstr,"Error copying codec context");
  
    else if (fGrabb==-6)
  
        sprintf(tmpstr,"Could not open codec");
  
    i=(UINT) fGrabb;
  
    fGrabb=0;
  
    SetWindowText(hWndM,tmpstr);
  
    ExitThread(i);
  
    return 0;
  
  }
  
  // End Grabbing thread  

  When program receive RTSP H264 video data with resolution 704x576 then decoded video pictures are OK. When receive RTSP H264 HD-video data with resolution 1280x720 it look like that first video picture is decoded OK and then video pictures are decoded but always with some error.

  Please help me to fix this problem !

  Here is problems brief :
  I have an IP camera model HI3518E_50H10L_S39 (product of China).
  Camera can provide H264 video stream both at resolution 704x576 (with RTSP URI "rtsp ://192.168.1.18:554/user=admin_password=tlJwpbo6_channel=1_stream=1.sdp ?real_stream") or 1280x720 (with RTSP URI "rtsp ://192.168.1.18:554/user=admin_password=tlJwpbo6_channel=1_stream=0.sdp ?real_stream").
  Using FFplay utility I can access and display them with good picture quality.
  For testing of grabbing from this camera, I have a simple (above mentioned) program in VC-2005. In "Grabbing thread" program use FFmpeg library version 4.0 for opening camera RTSP stream, retrieve stream information, find the first video stream... and prepare some variables.
  Center of this thread is loop : Grab a frame (function av_read_frame) - Decode it if it’s video (function avcodec_decode_video2) - Convert to RGB format (function sws_scale) - Display to program window (GDI function SetDIBitsToDevice).
  When proram run with camera RTSP stream at resolution 704x576, I have good video picture. Here is a sample :
  704x576 sample
  When program run with camera RTSP stream at resolution 1280x720, first video picture is good :
  First good at res.1280x720
  but then not good :
  not good at res.1280x720
  Its seem to be my FFmpeg function call to avcodec_decode_video2 can’t fully decode certain packet for some reasons.

• Overcoming Fintech and Finserv’s Biggest Data Analytics Challenges

  13 septembre 2024, par Daniel Crough — Banking and Financial Services, Marketing, Security

  Data powers innovation in financial technology (fintech), from personalized banking services to advanced fraud detection systems. Industry leaders recognize the value of strong security measures and customer privacy. A recent survey highlights this focus, with 72% of finance Chief Risk Officers identifying cybersecurity as their primary concern.

  Beyond cybersecurity, fintech and financial services (finserv) companies are bogged down with massive amounts of data spread throughout disconnected systems. Between this, a complex regulatory landscape and an increasingly tech-savvy and sceptical consumer base, fintech and finserv companies have a lot on their plates.

  How can marketing teams get the information they need while staying focused on compliance and providing customer value ? 

  This article will examine strategies to address common challenges in the finserv and fintech industries. We’ll focus on using appropriate tools, following effective data management practices, and learning from traditional banks’ approaches to similar issues.

  What are the biggest fintech data analytics challenges, and how do they intersect with traditional banking ?

  Recent years have been tough for the fintech industry, especially after the pandemic. This period has brought new hurdles in data analysis and made existing ones more complex. As the market stabilises, both fintech and finserve companies must tackle these evolving data issues.

  Let’s examine some of the most significant data analytics challenges facing the fintech industry, starting with an issue that’s prevalent across the financial sector :

  1. Battling data silos

  In a recent survey by InterSystems, 54% of financial institution leaders said data silos are their biggest barrier to innovation, while 62% said removing silos is their priority data strategy for the next year.

  

  Data silos segregate data repositories across departments, products and other divisions. This is a major issue in traditional banking and something fintech companies should avoid inheriting at all costs.

  Siloed data makes it harder for decision-makers to view business performance with 360-degree clarity. It’s also expensive to maintain and operationalise and can evolve into privacy and data compliance issues if left unchecked.

  To avoid or remove data silos, develop a data governance framework and centralise your data repositories. Next, simplify your analytics stack into as few integrated tools as possible because complex tech stacks are one of the leading causes of data silos.

  Use an analytics system like Matomo that incorporates web analytics, marketing attribution and CRO testing into one toolkit.

  

  Matomo’s support plans help you implement a data system to meet the unique needs of your business and avoid issues like data silos. We also offer data warehouse exporting as a feature to bring all of your web analytics, customer data, support data, etc., into one centralised location.

  Try Matomo for free today, or contact our sales team to discuss support plans.

  2. Compliance with laws and regulations

  A survey by Alloy reveals that 93% of fintech companies find it difficult to meet compliance regulations. The cost of staying compliant tops their list of worries (23%), outranking even the financial hit from fraud (21%) – and this in a year marked by cyber threats.

  

  Data privacy laws are constantly changing, and the landscape varies across global regions, making adherence even more challenging for fintechs and traditional banks operating in multiple markets. 

  In the US market, companies grapple with regulations at both federal and state levels. Here are some of the state-level legislation coming into effect for 2024-2026 :

  • Oregon – Oregon Consumer Privacy Act (July 1, 2024)
  • Florida – Florida Digital Bill of Rights (July 1, 2024)
  • Texas – Texas Data Privacy and Security Act (July 1, 2024)
  • Montana – Montana Consumer Data Privacy Act (October 1, 2024)
  • Delaware – Delaware Personal Privacy Act (January 1, 2025)
  • Iowa – Iowa Consumer Data Protection Act (January 1, 2025)
  • New Jersey – SB 332 (January 15, 2025)
  • Tennessee – Tennessee Information Protection Act (July 1, 2025)
  • Indiana – Indiana Consumer Data Protection Act ( January 1, 2026)

  Other countries are also ramping up regional regulations. For instance, Canada has Quebec’s Act Respecting the Protection of Personal Information in the Private Sector and British Columbia’s Personal Information Protection Act (BC PIPA).

  Ignorance of country- or region-specific laws will not stop companies from suffering the consequences of violating them.

  The only answer is to invest in adherence and manage business growth accordingly. Ultimately, compliance is more affordable than non-compliance – not only in terms of the potential fines but also the potential risks to reputation, consumer trust and customer loyalty.

  This is an expensive lesson that fintech and traditional financial companies have had to learn together. GDPR regulators hit CaixaBank S.A, one of Spain’s largest banks, with multiple multi-million Euro fines, and Klarna Bank AB, a popular Swedish fintech company, for €720,000.

  To avoid similar fates, companies should :

  1. Build solid data systems
  2. Hire compliance experts
  3. Train their teams thoroughly
  4. Choose data analytics tools carefully

  Remember, even popular tools like Google Analytics aren’t automatically safe. Find out how Matomo helps you gather useful insights while sticking to rules like GDPR.

  3. Protecting against data security threats

  Cyber threats are increasing in volume and sophistication, with the financial sector becoming the most breached in 2023.

  

  The cybersecurity risks will only worsen, with WEF estimating annual cybercrime expenses of up to USD $10.5 trillion globally by 2025, up from USD $3 trillion in 2015.

  While technology brings new security solutions, it also amplifies existing risks and creates new ones. A 2024 McKinsey report warns that the risk of data breaches will continue to increase as the financial industry increasingly relies on third-party data tools and cloud computing services unless they simultaneously improve their security posture.

  The reality is that adopting a third-party data system without taking the proper precautions means adopting its security vulnerabilities.

  In 2023, the MOVEit data breach affected companies worldwide, including financial institutions using its file transfer system. One hack created a global data crisis, potentially affecting the customer data of every company using this one software product.

  The McKinsey report emphasises choosing tools wisely. Why ? Because when customer data is compromised, it’s your company that takes the heat, not the tool provider. As the report states :

  “Companies need reliable, insightful metrics and reporting (such as security compliance, risk metrics and vulnerability tracking) to prove to regulators the health of their security capabilities and to manage those capabilities.”

  Don’t put user or customer data in the hands of companies you can’t trust. Work with providers that care about security as much as you do. With Matomo, you own all of your data, ensuring it’s never used for unknown purposes.

  

  4. Protecting users’ privacy

  With security threats increasing, fintech companies and traditional banks must prioritise user privacy protection. Users are also increasingly aware of privacy threats and ready to walk away from companies that lose their trust.

  Cisco’s 2023 Data Privacy Benchmark Study reveals some eye-opening statistics :

  • 94% of companies said their customers wouldn’t buy from them if their data wasn’t protected, and 
  • 95% see privacy as a business necessity, not just a legal requirement.

  Modern financial companies must balance data collection and management with increasing privacy demands. This may sound contradictory for companies reliant on dated practices like third-party cookies, but they need to learn to thrive in a cookieless web as customers move to banks and service providers that have strong data ethics.

  This privacy protection journey starts with implementing web analytics ethically from the very first session.

  

  The most important elements of ethically-sound web analytics in fintech are :

  1. 100% data ownership : Make sure your data isn’t used in other ways by the tools that collect it.
  2. Respecting user privacy : Only collect the data you absolutely need to do your job and avoid personally identifiable information.
  3. Regulatory compliance : Stick with solutions built for compliance to stay out of legal trouble.
  4. Data transparency : Know how your tools use your data and let your customers know how you use it.

  Read our guide to ethical web analytics for more information.

  5. Comparing customer trust across industries 

  While fintech companies are making waves in the financial world, they’re still playing catch-up when it comes to earning customer trust. According to RFI Global, fintech has a consumer trust score of 5.8/10 in 2024, while traditional banking scores 7.6/10.

  

  This trust gap isn’t just about perception – it’s rooted in real issues :

  • Security breaches are making headlines more often.
  • Privacy regulations like GDPR are making consumers more aware of their rights.
  • Some fintech companies are struggling to handle fraud effectively.

  According to the UK’s Payment Systems Regulator, digital banking brands Monzo and Starling had some of the highest fraudulent activity rates in 2022. Yet, Monzo only reimbursed 6% of customers who reported suspicious transactions, compared to 70% for NatWest and 91% for Nationwide.

  So, what can fintech firms do to close this trust gap ?

  • Start with privacy-centric analytics from day one. This shows customers you value their privacy from the get-go.
  • Build and maintain a long-term reputation free of data leaks and privacy issues. One major breach can undo years of trust-building.
  • Learn from traditional banks when it comes to handling issues like fraudulent transactions, identity theft, and data breaches. Prompt, customer-friendly resolutions go a long way.
  • Remember : cutting-edge financial technology doesn’t make up for poor customer care. If your digital bank won’t refund customers who’ve fallen victim to credit card fraud, they’ll likely switch to a traditional bank that will.

  The fintech sector has made strides in innovation, but there’s still work to do in establishing trustworthiness. By focusing on robust security, transparent practices, and excellent customer service, fintech companies can bridge the trust gap and compete more effectively with traditional banks.

  6. Collecting quality data

  Adhering to data privacy regulations, protecting user data and implementing ethical analytics raises another challenge. How can companies do all of these things and still collect reliable, quality data ?

  Google’s answer is using predictive models, but this replaces real data with calculations and guesswork. The worst part is that Google Analytics doesn’t even let you use all of the data you collect in the first place. Instead, it uses something called data sampling once you pass certain thresholds.

  In practice, this means that Google Analytics uses a limited set of your data to calculate reports. We’ve discussed GA4 data sampling at length before, but there are two key problems for companies here :

  1. A sample size that’s too small won’t give you a full representation of your data.
  2. The more visitors that come to your site, the less accurate your reports will become.

  For high-growth companies, data sampling simply can’t keep up. Financial marketers widely recognise the shortcomings of big tech analytics providers. In fact, 80% of them say they’re concerned about data bias from major providers like Google and Meta affecting valuable insights.

  This is precisely why CRO:NYX Digital approached us after discovering Google Analytics wasn’t providing accurate campaign data. We set up an analytics system to suit the company’s needs and tested it alongside Google Analytics for multiple campaigns. In one instance, Google Analytics failed to register 6,837 users in a single day, approximately 9.8% of the total tracked by Matomo.

  In another instance, Google Analytics only tracked 600 visitors over 24 hours, while Matomo recorded nearly 71,000 visitors – an 11,700% discrepancy.

  

  Financial companies need a more reliable, privacy-centric alternative to Google Analytics that captures quality data without putting users at potential risk. This is why we built Matomo and why our customers love having total control and visibility of their data.

  Unlock the full power of fintech data analytics with Matomo

  Fintech companies face many data-related challenges, so compliant web analytics shouldn’t be one of them. 

  With Matomo, you get :

  • An all-in-one solution that handles traditional web analytics, behavioural analytics and more with strong integrations to minimise the likelihood of data siloing
  • Full compliance with GDPR, CCPA, PIPL and more
  • Complete ownership of your data to minimise cybersecurity risks caused by negligent third parties
  • An abundance of ways to protect customer privacy, like IP address anonymisation and respect for DoNotTrack settings
  • The ability to import data from Google Analytics and distance yourself from big tech
  • High-quality data that doesn’t rely on sampling
  • A tool built with financial analytics in mind

  Don’t let big tech companies limit the power of your data with sketchy privacy policies and counterintuitive systems like data sampling. 

  Start your Matomo free trial or request a demo to unlock the full power of fintech data analytics without putting your customers’ personal information at unnecessary risk.