Recherche avancée

Sur d’autres sites (4855)

• C++ Invalid read of size 16, Address is 744 bytes inside a block of size 752 alloc'd

  17 août 2022, par Turgut

  I know there are similar questions to this one but I can't seem to find the solution in my own circumstances.

  


  I've made a program using opengl and ffmpeg that uses a buffer to complete it's operations. Normally, the program runs just fine with no errors whatsoever. However when I run my application using valgrind I get this error :

  


  ==31277== Invalid read of size 16
==31277==    at 0xD27852: memcpy (string_fortified.h:29)
==31277==    by 0xD27852: scale_internal (swscale.c:947)
==31277==    by 0xD29EE8: sws_scale (swscale.c:1213)
==31277==    by 0x268BBC: Videooio::video_encoder::set_frame_yuv_from_rgb(AVFrame*, SwsContext*) (video_encoder.cpp:441)
==31277==    by 0x268D18: Videooio::video_encoder::get_video_frame(Videooio::OutputStream*) (video_encoder.cpp:486)
==31277==    by 0x269032: write_video_frame (video_encoder.cpp:499)
==31277==    by 0x269032: Videooio::video_encoder::encode_one_frame() (video_encoder.cpp:553)
==31277==    by 0x22BD89: Videooio::Application::main_loop() (Application.cpp:212)
==31277==    by 0x21B007: Videooio::Application::Run() (Application.cpp:70)
==31277==    by 0x219C94: main (main.cpp:22)
==31277==  Address 0x50df9c8 is 744 bytes inside a block of size 752 alloc'd
==31277==    at 0x4849013: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==31277==    by 0x21A970: Videooio::Application::Run() (Application.cpp:40)
==31277==    by 0x219C94: main (main.cpp:22)


  


  I've diagnosed the problem down to the following lines but I'm not quite sure how to fix it :

  


  Application.cpp

  


  void Run()
{
  ...
40   encoder = new video_encoder(width, height, fps, duration);
  ...
      while (second < duration)
     {
      auto* fbo = opengl_engine.glBuffer;

      encoder->set_encode_framebuffer(fbo);
212   encoder->encode_one_Frame();
     }
}


  


  video_encoder.h :

  


  namespace Videooio{
class video_encoder{
    public:
        video_encoder(int w, int h, unsigned int fps, unsigned int duration);
        
        void set_encode_framebuffer(uint8_t* data, bool audio_only = false);

        void encode_one_frame();
        ~video_encoder();  
    private:
        int write_frame(AVFormatContext *fmt_ctx, AVCodecContext *c,
                       AVStream *st, AVFrame *frame, AVPacket *pkt);

        AVFrame *get_video_frame(OutputStream *ost);

        int write_video_frame(AVFormatContext *oc, OutputStream *ost);

        uint8_t *rgb_data;

        int width;
        int height;
        
        void set_frame_yuv_from_rgb(AVFrame *frame, struct SwsContext *sws_context);
       
    };
}  


  


  Here is opengl_engine, where fbo is allocated :

  


  ...
if (posix_memalign((void**)&glBuffer, 128, (gl_width * gl_height * 4) ) != 0) 
{
   ERROR("Couldn't allocate frame buffer ");
   return false;
}
...


  


  Here is where I set the rgb_data that is inside the encoder (Probably the culprit too) is set to the allocated fbo :

  


  void video_encoder::set_audio_frame(AVFrame* audio, AVSampleFormat* format)
{
    audio_data = *audio;
    input_sample_fmt = *format;
}


  


  rgb_data is set uninitialized up until this point before it's usage (I've tried mallocing it inside the constructor, which was a horrible practice, but doing so changed nothing.).
And here is where it's used and where valgrind mentions :

  


     void video_encoder::set_frame_yuv_from_rgb(AVFrame *frame, struct SwsContext 
   *sws_context) {
       const int in_linesize[1] = { 4 * width };
       //uint8_t* dest[4] = { rgb_data, NULL, NULL, NULL };
       sws_context = sws_getContext(
               width, height, AV_PIX_FMT_RGBA,
               width, height, AV_PIX_FMT_YUV420P,
               SWS_BICUBIC, 0, 0, 0);
440    std::cout << "Address: " << rgb_data << std::endl;
441    sws_scale(sws_context, (const uint8_t * const *)&rgb_data, in_linesize, 0,
442            height, frame->data, frame->linesize);
}


  


  I'm not %100 sure whether rgb_data is causing this error or not but digging into sws_scale and finding where memcpy is used shows that rgb_data is used inside it.

  


  I've tried changing the buffer size of glBuffer to no avail since valgrind allways says 744 bytes inside a block of size 752 the size of which the error mentions is not changing when I change glBuffers size, this led me to believe that rgb_data might not be the culprit. But it's still my best bet.

  


  I've looked into these questions but I just can't seem to apply them to my own circumstance.

  


  Question 1
Question 2

  


  I'm using ubuntu.

  


• I want to record my computer screen and stream it to other computer browser over same network

  25 décembre 2022, par Abdullah Qasim

  I am using Flask for this purpose. I wanted to create a rtmp server that stream the screen in web browser.

  


  My Python Code is :

  


  import os
import subprocess

from flask import Flask, render_template

app = Flask(__name__)

@app.route('/')
def index():
    return render_template('index.html')

if __name__ == '__main__':
    # Start the RTMP server in a separate process
    subprocess.Popen(['ffmpeg', '-f', 'gdigrab', '-framerate', '25', '-probesize', '100000000000', '-i', 'desktop', '-vcodec', 'libx264', '-preset', 'ultrafast', '-tune', 'zerolatency', '-f', 'flv', 'rtmp://localhost:5000/live/stream_name'])

    # Start the Flask app
    app.run()



  


  My HTML code is :

  


  &#xA;  &#xA;    &#xA;    &#xA;    <code class="echappe-js">&lt;script src=&quot;https://unpkg.com/video.js/dist/video.js&quot;&gt;&lt;/script&gt;&#xA;  &#xA;  &#xA;    &#xA;    &lt;script&gt;&amp;#xA;      var player = videojs(&amp;#x27;my-video&amp;#x27;);&amp;#xA;    &lt;/script&gt;&#xA;  &#xA;&#xA;&#xA;

  


  When I run the flask app it produces an error :

  


  * Serving Flask app 'server' (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
ffmpeg version N-109449-gb92260f70a-20221223 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 12.2.0 (crosstool-NG 1.25.0.90_cf9beb1)
  configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libssh --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --disable-libmfx --enable-libvpl --enable-openal --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra-version=20221223
  libavutil      57. 43.100 / 57. 43.100
  libavcodec     59. 55.103 / 59. 55.103
  libavformat    59. 34.102 / 59. 34.102
  libavdevice    59.  8.101 / 59.  8.101
  libavfilter     8. 53.100 /  8. 53.100
  libswscale      6.  8.112 /  6.  8.112
  libswresample   4.  9.100 /  4.  9.100
  libpostproc    56.  7.100 / 56.  7.100
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
[gdigrab @ 00000134692d9cc0] Capturing whole desktop as 1280x1024x32 at (0,0)
Input #0, gdigrab, from 'desktop':
  Duration: N/A, start: 1671986678.012939, bitrate: 1048586 kb/s
  Stream #0:0: Video: bmp, bgra, 1280x1024, 1048586 kb/s, 25 fps, 25.08 tbr, 1000k tbn
127.0.0.1 - - [25/Dec/2022 21:44:39] code 400, message Bad request version ('û\x9beùSØHãEieÐ×kbz\x84ã^\x9dÚ½\x8bCðúÚîE\x8cßYë×s\x92.')
127.0.0.1 - - [25/Dec/2022 21:44:39] "♥ |☻÷xU▲Ϋ▲6/Åp²fÔ☻ a↑¢.6Õü+c)Â.çÇÉ°µ³Eߨ9ê;Èy ►hBZ¡↨LµrXÏëâM¤.Äÿ{@o↑É[ýÐNäo2¶¤{ö°RTâZ驨´ÅIon×ƶ¼ÈAiæ>7/þ↑m¨Q8bů޵¡!wâÙâÄt±õ§ð² ®
      ·×«2ùðT«{                   ý?ò¸ö$¬pòpów4êñOf¬=dâ2♣D¤B                            ¤↓▲ôm<·-/"CÑu*A&2Öj uõÓ☻ô\ß+ŧ«ø↑1☺Φúì\yª~Ç↑▲¤Yín
eîÔioPþ♣ü Mí▲^ôüdÕ{∟¶¶jE▼j♦1VÒYW×▼©Àñ_K|÷¶Ã}¦  ↑a↔;☻ÿ|É@8u7Ó8.AkÕuwMùÊ÷H5!PÎÐÛ´▼Ãdá~5iã
▬e
ûùSØHãEieÐ×kbz
              ã^CðúÚîEßYë×s." 400 -
[rtmp @ 000001346ae35180] Cannot read RTMP handshake response
rtmp://localhost:5000/live/stream_name: End of file


  


  I have searched on internet to fix this error but did not got any help.

  


• nvenc : De-compensate aspect ratio compensation of DVD-like content.

  28 janvier 2015, par Philip Langdale

  nvenc : De-compensate aspect ratio compensation of DVD-like content.
  For reasons we are not privy to, nvidia decided that the nvenc encoder
  
  should apply aspect ratio compensation to ’DVD like’ content, assuming that
  
  the content is not BT.601 compliant, but needs to be BT.601 compliant. In
  
  this context, that means that they make the following, questionable,
  
  assumptions :
  1) If the input dimensions are 720x480 or 720x576, assume the content has
  
  an active area of 704x480 or 704x576.
  2) Assume that whatever the input sample aspect ratio is, it does not account
  
  for the difference between ’physical’ and ’active’ dimensions.
  From these assumptions, they then conclude that they can ’help’, by adjusting
  
  the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
  
  display only the 704 wide active area with the same aspect ratio as the full
  
  720 wide image - this would be the correct adjustment factor, but what if you
  
  don’t ? And more importantly, what if you’re used to lavc not making this kind
  
  of adjustment at encode time - because none of the other encoders do this !
  And, what if you had already accounted for BT.601 and your input had the
  
  correct attributes ? Well, it’s going to apply the compensation anyway !
  
  So, if you take some content, and feed it through nvenc repeatedly, it
  
  will keep scaling the aspect ratio every time, stretching your video out
  
  more and more and more.
  So, clearly, regardless of whether you want to apply bt.601 aspect ratio
  
  adjustments or not, this is not the way to do it. With any other lavc
  
  encoder, you would do it as part of defining your input parameters or do
  
  the adjustment at playback time, and there’s no reason by nvenc should
  
  be any different.
  This change adds some logic to undo the compensation that nvenc would
  
  otherwise do.
  nvidia engineers have told us that they will work to make this
  
  compensation mechanism optional in a future release of the nvenc
  
  SDK. At that point, we can adapt accordingly.
  Signed-off-by : Philip Langdale <philipl@overt.org>
  
  Reviewed-by : Timo Rothenpieler <timo@rothenpieler.org>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavcodec/nvenc.c