Recherche avancée

Sur d’autres sites (7258)

• FFMPEG Re-muxing .MKV to MP4\MV4 while retaining Dolby Digital Plus [closed]

  30 décembre 2020, par David F

  I would be grateful if anyone could help me out here. I'm remuxing a large number of video files from .MKV to .MP4\M4V so they play on the Apple platform (including the TV App) without any issues. It has been a bit of a learning curve, but I’m so close now. It's important NOT to convert, but to remux.

  


  I have achieved the ability to remux 4K HDR with Dolby Digital Plus in a .MKV to 4K HDR with Dolby Digtial 5.1. MP4. The issue is retaining the Dolby Digital Plus. This contains the ATMOS information for object based sound.

  


  The media players on Apple reports Dolby Digital Plus for the .MKV and Dolby Digital 5.1 for .MP4

  


  I'm using FFMPEG with the following command :-

  


  ffmpeg -i original.mkv -c:v copy -c:a eac3 -tag:v hvc1 output.mp4

  


  Output from MediaInfo (note .MKV contains only 1 video and 1 audio track)

  


  Audio -----Original.mkv

  


  

  • ID : 2

  


  • Format : E-AC-3 JOC

  


  • Format/Info : Enhanced AC-3 with Joint
Object Coding

  


  • Commercial name : Dolby Digital Plus with Dolby
Atmos

  


  • Codec ID : **A_**EAC3

  


  • Duration : 51 min 51 s

  


  • Bit rate mode : Constant

  


  


  Audio ----- Remuxed .mp4

  


  

  • ID : 2

  


  • Format : E-AC-3

  


  • Format/Info : Enhanced AC-3

  


  • Commercial name : Dolby Digital Plus

  


  • Codec ID : ec-3

  


  • Duration : 51 min 51 s

  


  • Bit rate mode : Constant

  


  


  The remux operation finished in about 1 minute for a 8Gb 4k video file, so we I know there is no reencoding. My theory is the stream is still a E-AC-3 with Joint Object Control, but its marked as a E-AC-3.

  


  I can see that .mp4 can take E-AC-3 Joint Object Control (JOC) with the demo files from Dolby labs.

  


  I've also remuxed an MKV to MKV and able to see the same result. The JOC markings have been removed with FFMPEG

  


  My ask is, does anyone have any knowledge of how to remux and keep Enhanced AC-3 with Joint Object Control with FFMPEG. Does FFMPEG support this ?

  


  Or know if just editing the Format, Format/Info, and Code ID is enough and the sound information in my .MP4\M4V is E-AC-3 JOC. If so can I just edit the media info, if so how ?

  


  I know Dolby Labs to allow free remuxing of Dolby Digital Plus/ Atmos with sample code and information they have uploaded onto Github for developers. I just wonder if FFMPEG supports it

  


  Thanks in advanced.

  


  David

  


• Accented characters are not recognized in python [closed]

  10 avril 2023, par CorAnna

  I have a problem in the python script, my script should put subtitles in a video given a srt file, this srt file is written by another script but in its script it replaces the accents and all the particular characters with a black square symbol with a question mark inside it... the problem I think lies in the writing of this file, what follows and that in overwriting the subtitles I do with ffmpeg the sentences that contain an accented word are not written

  


  def video_audio_file_writer(video_file):

    videos_folder = "Video"
    audios_folder = "Audio"

    video_path = f"{videos_folder}\\{video_file}"

    video_name = Path(video_path).stem
    audio_name = f"{video_name}Audio"

    audio_path = f"{audios_folder}\\{audio_name}.wav"

    video = mp.VideoFileClip(video_path)
    audio = video.audio.write_audiofile(audio_path)

    return video_path, audio_path, video_name

    def audio_file_transcription(audio_path, lang):

    model = whisper.load_model("base")
    tran = gt.Translator()

    audio_file = str(audio_path)

    options = dict(beam_size=5, best_of=5)
    translate = dict(task="translate", **options)
    result = model.transcribe(audio_file, **translate)   

    return result

def audio_subtitles_transcription(result, video_name):

    subtitle_folder = "Content"
    subtitle_name = f"{video_name}Subtitle"
    subtitle_path_form = "srt"

    subtitle_path = f"{subtitle_folder}\\{subtitle_name}.{subtitle_path_form}"

    with open(os.path.join(subtitle_path), "w") as srt:
        # write_vtt(result["segments"], file=vtt)
        write_srt(result["segments"], file=srt)
            
    return subtitle_path

def video_subtitles(video_path, subtitle_path, video_name):

    video_subtitled_folder = "VideoSubtitles"
    video_subtitled_name = f"{video_name}Subtitles"
    video_subtitled_path = f"{video_subtitled_folder}\\{video_subtitled_name}.mp4"

    video_path_b = bytes(video_path, 'utf-8')
    subtitle_path_b = bytes(subtitle_path, 'utf-8')
    video_subtitled_path_b = bytes(video_subtitled_path, 'utf-8')

    path_abs_b = os.getcwdb() + b"\\"

    path_abs_bd = path_abs_b.decode('utf-8')
    video_path_bd= video_path_b.decode('utf-8')
    subtitle_path_bd = subtitle_path_b.decode('utf-8')
    video_subtitled_path_bd = video_subtitled_path_b.decode('utf-8')

    video_path_abs = str(path_abs_bd + video_path_bd)
    subtitle_path_abs = str(path_abs_bd + subtitle_path_bd).replace("\\", "\\\\").replace(":", "\\:")
    video_subtitled_path_abs = str(path_abs_bd + video_subtitled_path_bd)

    time.sleep(3)

    os.system(f"ffmpeg -i {video_path_abs} -vf subtitles='{subtitle_path_abs}' -y {video_subtitled_path_abs}")

    return video_subtitled_path_abs, video_path_abs, subtitle_path_abs

if __name__ == "__main__":

    video_path, audio_path, video_name = video_audio_file_writer(video_file="ChiIng.mp4")
    result = audio_file_transcription(audio_path=audio_path, lang="it")
    subtitle_path = audio_subtitles_transcription(result=result, video_name=video_name)
    video_subtitled_path_abs, video_path_abs, subtitle_path_abs = video_subtitles(video_path=video_path, subtitle_path=subtitle_path, video_name=video_name)
    
    print("Video Subtitled")


  


  Windows 11
Python 3.10

  


• Bit-field badness

  30 janvier 2010, par Mans — Compilers, Optimisation

  Consider the following C code which is based on an real-world situation.

  struct bf1_31 
      unsigned a:1 ;
      unsigned b:31 ;
   ;
  void func(struct bf1_31 *p, int n, int a)
  
  
  
      int i = 0 ;
  
      do 
  
          if (p[i].a)
  
              p[i].b += a ;
  
       while (++i < n) ;
  
  
  

  How would we best write this in ARM assembler ? This is how I would do it :
  

  func :
          ldr     r3,  [r0], #4
          tst     r3,  #1
          add     r3,  r3,  r2,  lsl #1
          strne   r3,  [r0, #-4]
          subs    r1,  r1,  #1
          bgt     func
          bx      lr
  

  The add instruction is unconditional to avoid a dependency on the comparison. Unrolling the loop would mask the latency of the ldr instruction as well, but that is outside the scope of this experiment.

  Now compile this code with gcc -march=armv5te -O3 and watch in horror :

  func :
          push    r4
          mov     ip, #0
          mov     r4, r2
  loop :
          ldrb    r3, [r0]
          add     ip, ip, #1
          tst     r3, #1
          ldrne   r3, [r0]
          andne   r2, r3, #1
          addne   r3, r4, r3, lsr #1
          orrne   r2, r2, r3, lsl #1
          strne   r2, [r0]
          cmp     ip, r1
          add     r0, r0, #4
          blt     loop
          pop     r4
          bx      lr
  

  This is nothing short of awful :

  • The same value is loaded from memory twice.
  • A complicated mask/shift/or operation is used where a simple shifted add would suffice.
  • Write-back addressing is not used.
  • The loop control counts up and compares instead of counting down.
  • Useless mov in the prologue ; swapping the roles or r2 and r4 would avoid this.
  • Using lr in place of r4 would allow the return to be done with pop {pc}, saving one instruction (ignoring for the moment that no callee-saved registers are needed at all).

  Even for this trivial function the gcc-generated code is more than twice the optimal size and slower by approximately the same factor.

  The main issue I wanted to illustrate is the poor handling of bit-fields by gcc. When accessing bitfields from memory, gcc issues a separate load for each field even when they are contained in the same aligned memory word. Although each load after the first will most likely hit L1 cache, this is still bad for several reasons :

  • Loads have typically two or three cycles result latency compared to one cycle for data processing instructions. Any bit-field can be extracted from a register with two shifts, and on ARM the second of these can generally be achieved using a shifted second operand to a following instruction. The ARMv6T2 instruction set also adds the SBFX and UBFX instructions for extracting any signed or unsigned bit-field in one cycle.
  • Most CPUs have more data processing units than load/store units. It is thus more likely for an ALU instruction than a load/store to issue without delay on a superscalar processor.
  • Redundant memory accesses can trigger early flushing of store buffers rendering these less efficient.

  No gcc bashing is complete without a comparison with another compiler, so without further ado, here is the ARM RVCT output (armcc --cpu 5te -O3) :

  func :
          mov     r3, #0
          push    r4, lr
  loop :
          ldr     ip, [r0, r3, lsl #2]
          tst     ip, #1
          addne   ip, ip, r2, lsl #1
          strne   ip, [r0, r3, lsl #2]
          add     r3, r3, #1
          cmp     r3, r1
          blt     loop
          pop     r4, pc
  

  This is much better, the core loop using only one instruction more than my version. The loop control is counting up, but at least this register is reused as offset for the memory accesses. More remarkable is the push/pop of two registers that are never used. I had not expected to see this from RVCT.

  Even the best compilers are still no match for a human.