Recherche avancée

Sur d’autres sites (7917)

• Possible bug in latest google chrome (v62) ?

  21 novembre 2017, par Jalal El-Shaer

  The following demo was working perfectly :

  http://jsfiddle.net/r6wz0nz6/2/

  The following is a sample of ’video-preview’ class in action :

  <a href="https://www.youtube.com/watch?v=v1uyQZNg2vE" target="_blank" class="video-preview" data-frames="100" data-source="http://i.imgur.com/BX0pV4J.jpg">
  
  </a>

  Now, if you use your mouse to scroll from left-to-right, somehow it is not working (shows thumbnail instead of current image position). This was working perfectly before v62. While, from right-to-left, it works normally.

  Updated Please watch how this looks here : https://www.youtube.com/watch?v=HvDP-YXJgOk

  Question : How can I overcome this bug/issue ?

  P.S. the demo is based on this blog post (https://www.binpress.com/tutorial/how-to-generate-video-previews-with-ffmpeg/138)

  Update 2
  Interesting, in the following part :

  elm.mousemove(function(e) {
  
  var left = e.clientX - elm.position().left;
  
  slider.show().css('left', left -1); // <<---------------------- this line
  
  img.css('left', -Math.floor((left / width) * frames) * width);

  if I remove the ’-1’ like so :
  slider.show().css('left', left);
  It works from Left-To-Right, but now from Right-To-Left is showing same bug !!

  Proposed Workaround by @A. Wollf
  Change the "mouseout" to "mouseleave" and it seems to fix it : http://jsfiddle.net/r6wz0nz6/388

• Revision e2c2a65695 : Fix PICK_MODE_CONTEXT index in non-RD coding mode This commit fixes a bug in th

  12 décembre 2014, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_encodeframe.c

  
  
  Fix PICK_MODE_CONTEXT index in non-RD coding mode

  This commit fixes a bug in the PICK_MODE_CONTEXT index for
  horizontal partition case. The compression performance change
  is less than 0.01% level, since most blocks are selected to
  use square block size in RTC coding mode.

  Change-Id : I67effc18ae8795fccdd82a55f4efc609fa5cb3e1

• Google Speech - Streaming Request Returns EOF Error

  16 octobre 2017, par Josh

  Using Go, I’m taking a RTMP stream, transcoding it to FLAC (using ffmpeg) and attempting to stream to Google’s Speech API to transcribe the audio. However, I keep getting EOF errors when sending the data. I can’t find any information on this error in the docs so I’m not exactly sure what’s causing it.

  I’m chunking the received data into 3s clips (length isn’t relevant as long as it’s less than the maximum length of a streaming recognition request).

  Here is the core of my code :

  func main() {
  
  
  
      done := make(chan os.Signal)
  
      received := make(chan []byte)
  
  
  
      go receive(received)
  
      go transcribe(received)
  
  
  
      signal.Notify(done, os.Interrupt, syscall.SIGTERM)
  
  
  
      select {
  
      case <-done:
  
          os.Exit(0)
  
      }
  
  }
  
  
  
  func receive(received chan<- []byte) {
  
      var b bytes.Buffer
  
      stdout := bufio.NewWriter(&b)
  
  
  
      cmd := exec.Command("ffmpeg", "-i", "rtmp://127.0.0.1:1935/live/key", "-f", "flac", "-ar", "16000", "-")
  
      cmd.Stdout = stdout
  
  
  
      if err := cmd.Start(); err != nil {
  
          log.Fatal(err)
  
      }
  
  
  
      duration, _ := time.ParseDuration("3s")
  
      ticker := time.NewTicker(duration)
  
  
  
      for {
  
          select {
  
          case <-ticker.C:
  
              stdout.Flush()
  
              log.Printf("Received %d bytes", b.Len())
  
              received <- b.Bytes()
  
              b.Reset()
  
          }
  
      }
  
  }
  
  
  
  func transcribe(received <-chan []byte) {
  
      ctx := context.TODO()
  
  
  
      client, err := speech.NewClient(ctx)
  
      if err != nil {
  
          log.Fatal(err)
  
      }
  
  
  
      stream, err := client.StreamingRecognize(ctx)
  
      if err != nil {
  
          log.Fatal(err)
  
      }
  
  
  
      // Send the initial configuration message.
  
      if err = stream.Send(&speechpb.StreamingRecognizeRequest{
  
          StreamingRequest: &speechpb.StreamingRecognizeRequest_StreamingConfig{
  
              StreamingConfig: &speechpb.StreamingRecognitionConfig{
  
                  Config: &speechpb.RecognitionConfig{
  
                      Encoding:        speechpb.RecognitionConfig_FLAC,
  
                      LanguageCode:    "en-GB",
  
                      SampleRateHertz: 16000,
  
                  },
  
              },
  
          },
  
      }); err != nil {
  
          log.Fatal(err)
  
      }
  
  
  
      for {
  
          select {
  
          case data := <-received:
  
              if len(data) > 0 {
  
                  log.Printf("Sending %d bytes", len(data))
  
                  if err := stream.Send(&speechpb.StreamingRecognizeRequest{
  
                      StreamingRequest: &speechpb.StreamingRecognizeRequest_AudioContent{
  
                          AudioContent: data,
  
                      },
  
                  }); err != nil {
  
                      log.Printf("Could not send audio: %v", err)
  
                  }
  
              }
  
          }
  
      }
  
  }

  Running this code gives this output :

  2017/10/09 16:05:00 Received 191704 bytes
  
  2017/10/09 16:05:00 Saving 191704 bytes
  
  2017/10/09 16:05:00 Sending 191704 bytes
  
  2017/10/09 16:05:00 Could not send audio: EOF
  
  
  
  2017/10/09 16:05:03 Received 193192 bytes
  
  2017/10/09 16:05:03 Saving 193192 bytes
  
  2017/10/09 16:05:03 Sending 193192 bytes
  
  2017/10/09 16:05:03 Could not send audio: EOF
  
  
  
  2017/10/09 16:05:06 Received 193188 bytes
  
  2017/10/09 16:05:06 Saving 193188 bytes
  
  2017/10/09 16:05:06 Sending 193188 bytes // Notice that this doesn't error
  
  
  
  2017/10/09 16:05:09 Received 191704 bytes
  
  2017/10/09 16:05:09 Saving 191704 bytes
  
  2017/10/09 16:05:09 Sending 191704 bytes
  
  2017/10/09 16:05:09 Could not send audio: EOF

  Notice that not all of the Sends fail.

  Could anyone point me in the right direction here ? Is it something to do with the FLAC headers or something ? I also wonder if maybe resetting the buffer causes some of the data to be dropped (i.e. it’s a non-trivial operation that actually takes some time to complete) and it doesn’t like this missing information ?

  Any help would be really appreciated.