Recherche avancée

Sur d’autres sites (12774)

• FFmpeg only reading one channel

  29 août 2017, par AbstractDissonance

  Trying to read a stereo wav file and ffmpeg is only reading one channel. ffprobe returns 2 channels.

  I have used -ac 2 and then added -channel_layout stereo but all return 1 channel(or basically filling half the buffer I created).

  Basically the output size of ffmpeg is about half the wav file size.

  What I would like is for it to return every channel in

  Channel1_sample1, channel2_sample1, ..., ChannelN_sample1, channel1_sample2, etc...

  But, in reality, I’d rather just have it work with stereo ;) I’m giving it plenty large enough buffer to read to, so that isn’t the problem either.

  Here is the output

  ffprobe.exe -hide_banner -v quiet -print_format flat -show_streams -i temp.wav
  
  streams.stream.0.index=0
  
  streams.stream.0.codec_name="pcm_s16le"
  
  streams.stream.0.codec_long_name="PCM signed 16-bit little-endian"
  
  streams.stream.0.profile="unknown"
  
  streams.stream.0.codec_type="audio"
  
  streams.stream.0.codec_time_base="1/44100"
  
  streams.stream.0.codec_tag_string="[1][0][0][0]"
  
  streams.stream.0.codec_tag="0x0001"
  
  streams.stream.0.sample_fmt="s16"
  
  streams.stream.0.sample_rate="44100"
  
  streams.stream.0.channels=2
  
  streams.stream.0.channel_layout="unknown"
  
  streams.stream.0.bits_per_sample=16
  
  streams.stream.0.id="N/A"
  
  streams.stream.0.r_frame_rate="0/0"
  
  streams.stream.0.avg_frame_rate="0/0"
  
  streams.stream.0.time_base="1/44100"
  
  streams.stream.0.start_pts="N/A"
  
  streams.stream.0.start_time="N/A"
  
  streams.stream.0.duration_ts=14200200
  
  streams.stream.0.duration="322.000000"
  
  streams.stream.0.bit_rate="1411200"
  
  streams.stream.0.max_bit_rate="N/A"
  
  streams.stream.0.bits_per_raw_sample="N/A"
  
  streams.stream.0.nb_frames="N/A"
  
  streams.stream.0.nb_read_frames="N/A"
  
  streams.stream.0.nb_read_packets="N/A"
  
  streams.stream.0.disposition.default=0
  
  streams.stream.0.disposition.dub=0
  
  streams.stream.0.disposition.original=0
  
  streams.stream.0.disposition.comment=0
  
  streams.stream.0.disposition.lyrics=0
  
  streams.stream.0.disposition.karaoke=0
  
  streams.stream.0.disposition.forced=0
  
  streams.stream.0.disposition.hearing_impaired=0
  
  streams.stream.0.disposition.visual_impaired=0
  
  streams.stream.0.disposition.clean_effects=0
  
  streams.stream.0.disposition.attached_pic=0
  
  streams.stream.0.disposition.timed_thumbnails=0
  
  ffmpeg.exe -i temp.wav -loglevel quiet -f s16le -ac 2 -channel_layout stereo -

  temp.wav is just a standard stereo wav file.

• Slightly wrong color in MP4 videos written by PyAV

  26 septembre 2024, par Yossi Kreinin

  I am writing MP4 video files with the following PyAV-based code (getting input frames represented as numpy arrays - the sort produced by imageio.imread - as input) :

  


  class MP4:
    def __init__(self, fname, width, height, fps):
        self.output = av.open(fname, 'w', format='mp4')
        self.stream = self.output.add_stream('h264', str(fps))
        self.stream.width = width
        self.stream.height = height
        # these 2 lines can be removed and the problem still reproduces:
        self.stream.pix_fmt = 'yuv420p'
        self.stream.options = {'crf': '17'}
    def write_frame(self, pixels):
        frame = av.VideoFrame.from_ndarray(pixels, format='rgb24')
        packet = self.stream.encode(frame)
        self.output.mux(packet)
    def close(self):
        packet = self.stream.encode(None)
        self.output.mux(packet)
        self.output.close()


  


  The colors in the output MP4 video are slightly different (apparently darker) than the colors in the input images :

  


  Screen grab of an image viewer showing an input frame :

  


  

  


  Screen grab of VLC playing the output MP4 video :

  


  

  


  How can this problem be fixed ? I variously fiddled with the frame.colorspace attribute, stream options and VideoFrame.reformat but it changed nothing ; of course I could have been fiddling incorrectly.

  


  As you can see, the input has simple flat color regions, so I doubt it's any sort of compression artifact, eg YUV420 dropping some of the chroma info or other such.

  


• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  9 octobre 2020

  Ouais, une légère-subtile-discrète bordure en bas, ça reste raisonnable. J’ai essayé dans l’inspecteur, c’est pas mal, pourquoi pas.

  Il va quand même me falloir plus de lectures pour me faire une idée sur l’argument qui dit que sans ça les gens auraient du mal à identifier les boutons. Même dans les exemples de theming de material - c’est un peu eux qui ont remis au goût du jour les ombres portées et l’idée de relief et de strates verticales - ils donnent des exemples de boutons flat : https://material.io/design/material-theming/overview.html#material-theming
  Donc ça me semble pas être un horizon indépassable :p

  Concernant la couleur de base, à un moment j’hésitais à partir sur la couleur de l’utilisateur, la version claire.
  D’ailleurs vous noterez que c’est celle utilisée pour les boutons des formulaires, comme .boutons a déjà un fond de couleur claire j’ai fait une exception pour eux. Mais c’est bien des boutons de base, pas la variante .principal.
  Mais bon, j’étais pas convaincu, je préfèrerais quand même arriver à faire fonctionner le gris clair dans toutes les situations.
  Dans Bootstrap, Semantic-ui et cie, les boutons de base sont également gris clairs.

  Pour SVP je vais poursuivre dans les tickets liés du coup, sinon on va s’éparpiller.
  Juste @marcimat, le truc que je propose c’est ni plus ni moins que la maquette de rasta. C’est même moins d’ailleurs. Et j’ai rien de spécial à ajouter en plus.