Recherche avancée

Sur d’autres sites (11837)

• FFMPEG MKV -> MP4 Batch Conversion

  15 juillet 2024, par blaziken386

  I'm trying to write a program that lets me convert a series of .mkv files with subtitle files into .mp4 files with the subs hardcoded.

  


  Right now, the script I use is

  


  ffmpeg -i input.mkv -vf subtitles=input.mkv output.mp4



  


  This is fine, but it means I can only convert them one at a time, and it's kind of a hassle because it means I have to fiddle with it every few minutes to set up the next one.

  


  I have another script I use for converting .flac files to .mp3 files, which is

  


  @ECHO OFF

FOR %%f IN (*.flac) DO (
echo Converting: %%f
ffmpeg -i "%%f" -ab 320k -map_metadata 0 "%%~nf.mp3"
)

echo Finished

PAUSE



  


  Running that converts every single .flac folder into an .mp3 equivalent, with the same filename and everything.

  


  I've tried to combine the above scripts into something like this :

  


  @ECHO OFF

FOR %%f IN (*.mkv) DO (
echo Converting: %%f
ffmpeg -i "%%f" -vf subtitles=%%f "%%~nf.mp4"
)

echo Finished

PAUSE


  


  but every time I do so, it returns errors like "invalid argument" or "unable to find a suitable output type", or "error initializing filters", or "2 frames left in the queue on closing" or something along those lines. I've swapped out subtitles=%%f for "subtitles-%%f" or subtitles="%%f.mkv" and so on and so forth, and none of those give me what I want either. Sometimes it creates Empty .mp4 file containers with nothing in them, sometimes it does nothing at all.

  


  I don't really understand what exactly is happening under the hood in that flac->mp3 code, because I grabbed it from a different stackoverflow post years ago. All I know is that trying to copy that code and repurpose it into something else doesn't work. Is this just an issue where I've fucked up the formatting of the code and not realized it, or is this a "ffmpeg can't actually do that because of a weird technical issue" thing ?

  


  I also tried the code listed here, when Stackoverflow listed that as a possible duplicate, but that gave me similar errors, and I don't really understand why !

  


  Also, if it's relevant, I'm running windows.

  


• On memcpy application crashes - FFMPEG, C++

  3 mai 2013, par Spamdark

  I have been working with ffmpeg, I got it working good, but I got a memory leak, I followed some instructions to fix it (like use av_frame_unref), so I needed to update ffmpeg to the version 1.2.
  This is weird for me, because everything was working good, and then, with the update, the application started to crash in a memcpy.

  Honestly, I don't know what's happening, I tried to google it but no answer. I would appreciate your help, here is the segment of the code which is failing :

  int WbMedia::DecodeAudioFrame(int16_t *audio_buf){
  
  static AVFrame *frame;
  
  static AVPacket pkt;
  
  static uint8_t *audio_pkt_data = NULL;
  
  static int audio_pkt_size = 0;
  
  static bool first_time = true;
  
  
  
  if(first_time){
  
      first_time=false;
  
  }
  
  
  
  int len1, data_size = 0;
  
  
  
  for(;;){
  
      bool do_rt = false;
  
  
  
      while(audio_pkt_size > 0){
  
          int obt_frame = 0;
  
  
  
          if (!frame) {
  
              if (!(frame = avcodec_alloc_frame())) {
  
                  MessageBox(0,"Out of memory error","Error: Memory",MB_ICONWARNING | MB_OK);
  
                  return -1;
  
              }
  
          }
  
  
  
          len1 = avcodec_decode_audio4(_audio_ccontext,frame,&obt_frame,&pkt);
  
          if(len1 < 0){
  
              audio_pkt_size = 0;
  
              break;
  
          }
  
  
  
          if(obt_frame){
  
              data_size = av_samples_get_buffer_size(NULL,channel_count,sample_fr,_audio_ccontext->sample_fmt,1);
  
              memcpy(audio_buf,frame->data[0],data_size);
  
          }
  
  
  
          audio_pkt_data+=len1;
  
          audio_pkt_size-=len1;
  
  
  
          if(data_size < 0){
  
              continue;
  
          }
  
  
  
  
  
          return data_size;
  
      }
  
  
  
      if(pkt.data){
  
          //MessageBox(0,"hi","Hi",MB_OK); // This is only for test if the app si reaching this av_free_packet
  
          av_free_packet(&pkt);
  
      }
  
  
  
      if(do_rt){
  
          return data_size;
  
      }
  
  
  
      // Try to get a new packet
  
      if(!audio_packets.empty()){
  
          WaitForSingleObject(Queue_Audio_Mutex,INFINITE);
  
              pkt = *audio_packets.front();
  
              audio_packets.pop();
  
          ReleaseMutex(Queue_Audio_Mutex);
  
  
  
          audio_pkt_size = pkt.size;
  
          audio_pkt_data = pkt.data;
  
      }else{
  
          return -1;
  
      }
  
  }
  
  return 0;
  
  }

  Thanks so much.

• Could there be an unexpected collision of MS VC runtimes ?

  25 mai 2016, par sharpener

  I have learned the hard way, it’s not very good to share heap pointers between two dlls who each depends on different MS VC runtime. Fair enough. Based on this experience and current weird behavior of a program chain being debugged I would like to ask a

  Question :

  Could lib1.dll using one runtime (eg. msvcrt.dll) possibly damage heap of lib2.dll using different runtime (eg. vcruntime140d.dll) ? No pointers shared, just pairs of malloc/free on the same runtime.

  Background : (for those who would ask for it)

  • I have standard zeranoe ffmpeg libraries dependent on msvcrt.dll.
  • I created small C dll covering required functionality based on those ffmpeg libs, let’s call it libvideo.dll. It’s dependent on VS2015 runtime.
  • I created libvideosharp.dll a managed C# wrapper library (also VS2015) for libvideo.dll (marshalling).
  • I created C# test app using the libvideosharp.dll (also VS2015).
  • Debugging the C# test app (and associated libraries in the chain) I experience following :
    1. libvideo.dll mallocs and inits a data structure.
    2. libvideo.dll calls some ffmpeg init routines (av_register_all, avformat_network_init) which might malloc on its own runtime.
    3. libvideo.dll’s data structure is corrupted (not even passed to ffmpeg libs in any way, just independent malloced block).