Recherche avancée

Sur d’autres sites (16547)

• avcodec/decode : Set KEY flag+pict_type generically for intra-only codecs

  9 mai 2024, par Andreas Rheinhardt

  avcodec/decode : Set KEY flag+pict_type generically for intra-only codecs
  This commit is the analog of 3f11eac75741888c7b2b6f93c458766f2613bab5
  
  for decoding : It sets the AV_FRAME_FLAG_KEY and (for video decoders)
  
  also pict_type to AV_PICTURE_TYPE_I. It furthermore stops setting
  
  audio frames as always being key frames — it is wrong for e.g.
  
  TrueHD/MLP. The latter also affects TAK and DFPWM.
  The change already improves output for several decoders where
  
  it has been forgotten to set e.g. pict_type like speedhq, wnv1
  
  or tiff. The latter is the reason for the change to the exif-image-tiff
  
  FATE test reference file.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/decode.c
  • [DH] libavcodec/pthread_frame.c
  • [DH] tests/ref/fate/exif-image-tiff

• How to publish selfmade stream with ffmpeg and c++ to rtmp server ?

  10 janvier 2024, par rLino

  Have a nice day to you, people !

  



  I am writing an application for Windows that will capture the screen and send the stream to Wowza server by rtmp (for broadcasting). My application use ffmpeg and Qt.
I capture the screen with WinApi, convert a buffer to YUV444(because it's simplest) and encode frame as described at the file decoding_encoding.c (from FFmpeg examples) :

  



  ///////////////////////////
//Encoder initialization
///////////////////////////
avcodec_register_all();
codec=avcodec_find_encoder(AV_CODEC_ID_H264);
c = avcodec_alloc_context3(codec);
c->width=scr_width;
c->height=scr_height;
c->bit_rate = 400000;
int base_num=1;
int base_den=1;//for one frame per second
c->time_base= (AVRational){base_num,base_den};
c->gop_size = 10;
c->max_b_frames=1;
c->pix_fmt = AV_PIX_FMT_YUV444P;
av_opt_set(c->priv_data, "preset", "slow", 0);

frame = avcodec_alloc_frame();
frame->format = c->pix_fmt;
frame->width  = c->width;
frame->height = c->height;

for(int counter=0;counter<10;counter++)
{
///////////////////////////
//Capturing Screen
///////////////////////////
    GetCapScr(shotbuf,scr_width,scr_height);//result: shotbuf is filled by screendata from HBITMAP
///////////////////////////
//Convert buffer to YUV444 (standard formula)
//It's handmade function because of problems with prepare buffer to swscale from HBITMAP
///////////////////////////
    RGBtoYUV(shotbuf,frame->linesize,frame->data,scr_width,scr_height);//result in frame->data
///////////////////////////
//Encode Screenshot
///////////////////////////
    av_init_packet(&pkt);
    pkt.data = NULL;    // packet data will be allocated by the encoder
    pkt.size = 0;
    frame->pts = counter;
    avcodec_encode_video2(c, &pkt, frame, &got_output);
    if (got_output) 
    {
        //I think that  sending packet by rtmp  must be here!
        av_free_packet(&pkt);             

    }

}
// Get the delayed frames
for (int got_output = 1,i=0; got_output; i++)
{
    ret = avcodec_encode_video2(c, &pkt, NULL, &got_output);
    if (ret < 0)
        {
            fprintf(stderr, "Error encoding frame\n");
            exit(1);
        }
        if (got_output)
        {
        //I think that  sending packet by rtmp  must be here!
        av_free_packet(&pkt);      
        }
}

///////////////////////////
//Deinitialize encoder
///////////////////////////
avcodec_close(c);
av_free(c);
av_freep(&frame->data[0]);
avcodec_free_frame(&frame);


  



  I need to send video stream generated by this code to RTMP server.
In other words, I need c++/c analog for this command :

  



  ffmpeg -re -i "sample.h264" -f flv rtmp://sample.url.com/screen/test_stream


  



  It's useful, but I don't want to save stream to file, I want to use ffmpeg libraries for realtime encoding screen capture and sending encoded frames to RTMP server inside my own application.
Please give me a little example how to initialize AVFormatContext properly and to send my encoded video AVPackets to server.

  



  Thanks.

  


• avcodec/refstruct : Add simple API for refcounted objects

  4 août 2022, par Andreas Rheinhardt

  avcodec/refstruct : Add simple API for refcounted objects
  For now, this API is supposed to replace all the internal uses
  
  of reference counted objects in libavcodec ; "internal" here
  
  means that the object is created in libavcodec and is never
  
  put directly in the hands of anyone outside of it.
  It is intended to be made public eventually, but for now
  
  I enjoy the ability to modify it freely.
  Several shortcomings of the AVBuffer API motivated this API :
  
  a) The unnecessary allocations (and ensuing error checks)
  
  when using the API. Besides the need for runtime checks it
  
  imposes upon the developer the burden of thinking through
  
  what happens in case an error happens. Furthermore, these
  
  error paths are typically not covered by FATE.
  
  b) The AVBuffer API is designed with buffers and not with
  
  objects in mind : The type for the actual buffers used
  
  is uint8_t* ; it pretends to be able to make buffers
  
  writable, but this is wrong in case the buffer is not a POD.
  
  Another instance of this thinking is the lack of a reset
  
  callback in the AVBufferPool API.
  
  c) The AVBuffer API incurs unnecessary indirections by
  
  going through the AVBufferRef.data pointer. In case the user
  
  tries to avoid this indirection and stores a pointer to
  
  AVBuffer.data separately (which also allows to use the correct
  
  type), the user has to keep these two pointers in sync
  
  in case they can change (and in any case has two pointers
  
  occupying space in the containing context). See the following
  
  commit using this API for H.264 parameter sets for an example
  
  of the removal of such syncing code as well as the casts
  
  involved in the parts where only the AVBufferRef* pointer
  
  was stored.
  
  d) Given that the AVBuffer API allows custom allocators,
  
  creating refcounted objects with dedicated free functions
  
  often involves a lot of boilerplate like this :
  
  obj = av_mallocz(sizeof(*obj)) ;
  
  ref = av_buffer_create((uint8_t*)obj, sizeof(*obj), free_func, opaque, 0) ;
  
  if (!ref) 
  
      av_free(obj) ;
  
      return AVERROR(ENOMEM) ;
  
  
  
  (There is also a corresponding av_free() at the end of free_func().)
  
  This is now just
  
  obj = ff_refstruct_alloc_ext(sizeof(*obj), 0, opaque, free_func) ;
  
  if (!obj)
  
      return AVERROR(ENOMEM) ;
  
  See the subsequent patch for the framepool (i.e. get_buffer.c)
  
  for an example.
  This API does things differently ; it is designed to be lightweight*
  
  as well as geared to the common case where the allocator of the
  
  underlying object does not matter as long as it is big enough and
  
  suitably aligned. This allows to allocate the user data together
  
  with the API's bookkeeping data which avoids an allocation as well
  
  as the need for separate pointers to the user data and the API's
  
  bookkeeping data. This entails that the actual allocation of the
  
  object is performed by RefStruct, not the user. This is responsible
  
  for avoiding the boilerplate code mentioned in d).
  As a downside, custom allocators are not supported, but it will
  
  become apparent in subsequent commits that there are enough
  
  usecases to make it worthwhile.
  Another advantage of this API is that one only needs to include
  
  the relevant header if one uses the API and not when one includes
  
  the header or some other component that uses it. This is because there
  
  is no RefStruct type analog of AVBufferRef. This brings with it
  
  one further downside : It is not apparent from the pointer itself
  
  whether the underlying object is managed by the RefStruct API
  
  or whether this pointer is a reference to it (or merely a pointer
  
  to it).
  Finally, this API supports const-qualified opaque pointees ;
  
  this will allow to avoid casting const away by the CBS code.
  * : Basically the only exception to the you-only-pay-for-what-you-use
  
  rule is that it always uses atomics for the refcount.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/Makefile
  • [DH] libavcodec/refstruct.c
  • [DH] libavcodec/refstruct.h