Recherche avancée

Sur d’autres sites (10230)

• avformat/iamf_parse : reject ambisonics mode > 1

  29 novembre 2024, par Michael Niedermayer

  avformat/iamf_parse : reject ambisonics mode > 1
  ambisonics mode > 1 does not initialize any layer but layer 0
  
  is unconditionally dereferenced
  Fixes : poc-2024-11
  
  Fixes : null pointer dereference
  
  Found-by : 苏童 <220235212@seu.edu.cn>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/iamf_parse.c

• I cannot play a mp3 file on Discord's voice channel using discord.py

  1er décembre 2024, par ra1ned

  I am creating a discord bot that plays lofi for me. It does not play a song for me even though it shows a green indicator on a voice channel.

  


  Here's what I've written :

  


  if message.content == "!join":
    await message.author.voice.channel.connect()
    await message.channel.send("Successfully connected")

if message.content == "!play":
    if message.guild.voice_client is None: 
        await message.channel.send("use !join")
        return
    
    await message.channel.send("playing a song rn")
    print('*** playing a song rn')
    
    message.guild.voice_client.play(discord.FFmpegPCMAudio('lofi.mp3'))


  


  I put FFmpeg.exe and lofi.mp3 in the same directory as this script.
Also, it is strange that FFmpeg does not return any exception nor output on console although it seems to have failed to load the file. I have seen people who had the same problem, but it seems like that they get some error messages, unlike me.

  


  Here's the output on console after using !join

  


  2024-12-01 16:59:39 INFO     discord.voice_state Connecting to voice...
2024-12-01 16:59:39 INFO     discord.voice_state Starting voice handshake... (connection attempt 1)
2024-12-01 16:59:40 INFO     discord.voice_state Voice handshake complete. Endpoint found: japan8946.discord.media
2024-12-01 16:59:40 INFO     discord.voice_state Voice connection complete.


  


  after using !play, it only displays the message I wrote :

  


  *** playing a song rn


  


  Can someone help me with this ?

  


• Different container duration between ffmpeg versions which causes audio gaps

  4 septembre 2024, par blits

  I'm trying to make a looped RTMP stream from a single video (in this
example - YouTube), but starting with version 6.0 it introduces a gap in-between loops in the audio which is quite audible. Version before 6.0 (I
tried 5.1.6 and 4.4.2) work as expected and don't introduce any gaps.

  


  The difference I spotted is that the master version (7.0.2) and the 5.1.6, for
example, report a different duration time. Is there any reason why that might happen ?

  


  v5.1.6 :

  


   Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'demo-video.mp4':
   Metadata:
     major_brand     : isom
     minor_version   : 512
     compatible_brands: isomiso2avc1mp41
     creation_time   : 2024-09-03T15:30:51.000000Z
     encoder         : Blackmagic Design DaVinci Resolve Studio
   Duration: 00:00:05.00, start: 0.000000, bitrate: 35440 kb/s


  


  v7.0.2 :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'demo-video.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 2024-09-03T15:30:51.000000Z
    encoder         : Blackmagic Design DaVinci Resolve Studio
  Duration: 00:00:05.01, start: 0.000000, bitrate: 35346 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 2560x1440 [SAR 1:1 DAR 16:9], 35240 kb/s, 24 fps, 24 tbr, 12288 tbn (default)
      Metadata:
        creation_time   : 2024-09-03T15:30:51.000000Z
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
        encoder         : H.264 NVIDIA
        timecode        : 01:00:00:00


  


  As you can see, v5.1.6 report duration of 00:00:05.00 (which is correct) and v7.0.2 is 00:00:05.01 (1ms longer), which is what I think is causing the issue (but I'm not so sure about that). The original file is 5 seconds long which is what can be checked by ffprobe as well, but some streams report a 00:05.01 duration time.

  


  I tried to remedy this issue in many different ways by trimming the video/audio, using different flags, like -shortest, but that didn't help in any way - there's still a gap in the audio which is noticeable when looping the video. And like I said versions such as v5.1.6 work fine and there's no such gap.

  


  I guess what changed between versions is how ffmpeg interprets these streams but in the end I spent 2 days trying to avoid gaps in audio when streaming and nothing helped.

  


  How to reproduce :

  


  You can just stream the video in any RTMP destination of your liking, like YouTube and observe that there would be gaps (audio break-ups) in between every 5 seconds (once video ends). Video is accessible through the link from the curl command

  


  curl -o stream-audio-gap-issue.mp4 https://r2v.streamloop.app/obj_01j6y0pk83fy8vp06a9mmkkqah.mp4
ffmpeg -re -stream_loop -1 -i stream-audio-gap-issue.mp4 -c copy -f flv rtmp://a.rtmp.youtube.com/live2/[your-key]


  


  Expected : there are no gaps every 5 seconds, like in old versions of ffmpeg

  


  Instead : there are tiny audio gaps which are quite noticable

  


  ffprobe outputs is available on gist : https://gist.github.com/blitss/1e221b4fa8885b1df8ac2096746239cf

  


  I'm looking for literally any workarounds that will help avoid audio gaps whilst still preserving the latest version of ffmpeg.