Recherche avancée

Sur d’autres sites (5325)

• ffmpeg C API - creating queue of frames

  25 mai 2016, par lupod

  I have created using the C API of ffmpeg a C++ application that reads frames from a file and writes them to a new file. Everything works fine, as long as I write immediately the frames to the output. In other words, the following structure of the program outputs the correct result (I put only the pseudocode for now, if needed I can also post some real snippets but the classes that I have created for handling the ffmpeg functionalities are quite large) :

  AVFrame* frame = av_frame_alloc();
  
  int got_frame;
  
  
  
  // readFrame returns 0 if file is ended, got frame = 1 if
  
  // a complete frame has been extracted
  
  while(readFrame(inputfile,frame, &got_frame)) {
  
    if (got_frame) {
  
      // I actually do some processing here
  
      writeFrame(outputfile,frame);
  
    }
  
  }
  
  av_frame_free(&frame);

  The next step has been to parallelize the application and, as a consequence, frames are not written immediately after they are read (I do not want to go into the details of the parallelization). In this case problems arise : there is some flickering in the output, as if some frames get repeated randomly. However, the number of frames and the duration of the output video remains correct.

  What I am trying to do now is to separate completely the reading from writing in the serial implementation in order to understand what is going on. I am creating a queue of pointers to frames :

  std::queue queue;
  
  int ret = 1, got_frame;
  
  while (ret) {
  
    AVFrame* frame = av_frame_alloc();
  
    ret = readFrame(inputfile,frame,&got_frame);
  
    if (got_frame) 
  
      queue.push(frame);
  
  }

  To write frames to the output file I do :

  while (!queue.empty()) {
  
    frame = queue.front();
  
    queue.pop();
  
    writeFrame(outputFile,frame);
  
    av_frame_free(&frame);
  
  }

  The result in this case is an output video with the correct duration and number of frames that is only a repetition of the last 3 (I think) frames of the video.

  My guess is that something might go wrong because of the fact that in the first case I use always the same memory location for reading frames, while in the second case I allocate many different frames.

  Any suggestions on what could be the problem ?

• Why does ffplay read both video and keyboard input from stdin ?

  27 janvier 2016, par cxrodgers

  I’m trying to compress a video feed from a webcam while simultaneously displaying it, using ffmpeg and ffplay. I do actually have this working, but I want to disable the ffplay window from interpreting keyboard presses.

  It took me a while to figure this out but here’s what I’m using :

  ffmpeg -f video4linux2 -i /dev/video0 -vcodec mpeg4 -f rawvideo - \
  
    | tee output.mkv \
  
    | ffplay -fflags nobuffer -

  (Actually I am doing all of this from a Python script using the subprocess module. Here I have represented it as a straightforward terminal command because the result is the same.)

  So this actually works and does everything I want. The only thing is that if the ffplay window is active, it interprets keypresses (like "F" for fullscreen). Instead I want it to completely ignore all keypresses.

  My questions :

  1. How is this even possible ? I thought I was redirecting video input to stdin, and then telling ffplay to read video from stdin. How can keypresses be multiplexed on the same pipe ?
  2. How can I disable this behavior ? I tried "-nostdin" but it doesn’t work with my version.

  # ffplay -nostdin output.mkv

  ffplay version N-77455-g4707497 Copyright
  (c) 2003-2015 the FFmpeg developers built with gcc 4.8 (Ubuntu
  4.8.4-2ubuntu1 14.04)

  ...

  Failed to set value ’output.mkv’ for option ’nostdin’ : Option not
  found

• avformat/mpegtsenc : do not include adaptation field in teletext TS packets

  21 octobre 2021, par Alex Shumsky

  avformat/mpegtsenc : do not include adaptation field in teletext TS packets
  From ETSI EN 300 472 V1.3.1 (2003-05) Specification for conveying ITU-R System
  
  B Teletext in DVB bitstreams :
  4.1 Transport Stream (TS) packet format
  
  The standard TS packet syntax and semantics are followed, noting the following
  
  constraint :
  
   adaptation_field_control only the values "01" and "10" are permitted.
  Some set top boxes (Motorola, Arris, Zyxel) refuse non-conforming packets.
  Signed-off-by : Alex Shumsky <alexthreed@gmail.com>
  
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] libavformat/mpegtsenc.c