Recherche avancée

Sur d’autres sites (10285)

• Combine .dash video and audio segments to .mp4

  11 décembre 2019, par Mike Stevens

  I was able to download some dash video segments (youtube-dl was apparently blocked from downloading the .mpd and just downloading, concatenating as normal) and was hoping to combine/concatenate them so I could watch in VLC, perhaps using ffmpeg. I was able to download the relevant .mpd and .ismc files, so I have all of the DASH video and audio segments, as well as the .mpd and .ismc downloaded and in one folder.

  The video files are labelled as such

  video=869000.dash
  
  video=869000-0.dash
  
  video=869000-600.dash
  
  video=869000-1200.dash

  and the audio in a similar fashion

  audio=96000.dash
  
  audio=96000-0.dash
  
  audio=96000-96225.dash

  Would anyone know of a way to combine all of these into one watchable video file ? AdobeHDS used to work great for combining fragments, and youtube-dl cleary has some sort of method to do it, but neither works with this particular .mpd. I don’t believe concatenate in ffmpeg will work, when I try to do that, it initializes the first .dash file (audio or video), but stops there.

  When I try to put the .mpd file through ffmpeg, it returns "Failed to open an initialization section in playlist 0". I would’ve assumed this initialization was the video=869000.dash file though (which is the one segment file that ffmpeg does recognize) ?

• problem in loading texture from AVFrame(android)

  25 mars 2013, par SieuTruc

  I get a problem when loading data from AVFrame to openGL :

   int target_width = 320;
  
                  int target_height = 240;
  
                  img_convert_ctx = sws_getContext(pCodecCtx->width, pCodecCtx->height,
  
                                             pCodecCtx->pix_fmt,
  
                                             target_width, target_height, PIX_FMT_RGBA, SWS_FAST_BILINEAR,
  
                                             NULL, NULL, NULL);
  
                  if(img_convert_ctx == NULL) {
  
                      LOGE("could not initialize conversion context\n");
  
                      return;
  
                  }
  
                  sws_scale(img_convert_ctx, (const uint8_t* const*)pFrame->data, pFrame->linesize, 0, pCodecCtx->height, pFrameRGB->data, pFrameRGB->linesize);
  
                  //free(data);
  
                  int line=target_width*target_height*4;
  
                  data=(char*)malloc(line);
  
                  if (!data)
  
                      LOGE("create data frame fail");
  
                  LOGE("successful data");
  
                  filldata(data,pFrameRGB,target_width,target_height);

  with function filldata as :

      static void filldata(char *data,AVFrame *pFrame,int w,int h)
  
  {uint8_t *frameLine;
  
      int  yy;
  
      int i=0;
  
  
  
  for (yy = 0; yy < h; yy++) {
  
  
  
  frameLine = (uint8_t *)pFrame->data[0] + (yy * pFrame->linesize[0]);
  
  
  
  int xx;
  
  
  
  for (xx = 0; xx < w; xx++) {
  
              int in_offset = xx * 4;
  
  
  
  data[i++] = frameLine[in_offset];
  
  
  
  data[i++] = frameLine[in_offset+1];
  
  
  
  data[i++] = frameLine[in_offset+2];
  
  
  
  data[i++] = frameLine[in_offset+3];
  
          }
  
      }
  
  }

  After that i use data to transfer to

  glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, *wi, *he, 0, GL_RGBA, GL_UNSIGNED_BYTE, (GLvoid*)data);

  but it cannot show texture, maybe data above and data in function gltextimage2D are different.
  Please help me figure out what is the format for gltextimage2D so i can configure data to show texture. OR anyone has some sample code to show me.

• avfilter/af_afade : improve accuracy and speed of gain computation

  25 novembre 2015, par Ganesh Ajjanagadde

  avfilter/af_afade : improve accuracy and speed of gain computation
  Gain computation for various curves was being done in a needlessly
  
  inaccurate fashion. Of course these are all subjective curves, but when
  
  a curve is advertised to the user, it should be matched as closely as
  
  possible within the limitations of libm. In particular, the constants
  
  kept here were pretty inaccurate for double precision.
  Speed improvements are mainly due to the avoidance of pow, the most
  
  notorious of the libm functions in terms of performance. To be fair, it
  
  is the GNU libm that is among the worst, but it is not really GNU libm’s fault
  
  since others simply yield a higher error as measured in ULP.
  "Magic" constants are also accordingly documented, since they take at
  
  least a minute of thought for a casual reader.
  Reviewed-by : Paul B Mahol <onemda@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavfilter/af_afade.c