Sur d’autres sites (8081)

• Accessing web content with ffmpeg on android

  9 janvier 2017, par Pure_eyes

  I’m using ffmpeg inside my xamarin.android project,by accessing a statically build version for the corresponding architecture of the device.
  I’m using https://www.johnvansickle.com/ffmpeg/, static builds which support https protocol.
  I’m calling ffmpeg by starting a new process and passing the arguments.Here is a pseudo code for the operation :

  arguments = {'-i',inputFileName,...}
  
  run('./ffmpeg',arguments,redirectOutput = true,...)
  
       .OnOutput(s) => log(s)

  Now,I want to access a file in the web, directly with ffmpeg, since from my testing it is more efficient in term of bandwidth, and speed.

  The problem i’m facing is that because i’m using a static build of ffmpeg, we need to statically link gclib, which results loss of dns resolution as stated in the readme :

  A limitation of statically linking glibc is the loss of DNS resolution. Installing
  nscd through your package manager will fix this or you can use
  "ffmpeg -i http://<ip address="address" here="here">/"</ip> instead of "ffmpeg -i http://example.com/"

  But the content that i’m trying to get provides strictly only through HTTPS,so there is no way to access it via the ip.
  But on Linux systems i had no problem accessing the content(With the same command as for android), thanks to nscd, which isn’t present in android.

  • Is there anyway to use android’s dns resolution ?
  • Or compile ffmpeg
    differently, as stated in this
    question ?Maybe using android
    NDK would default this ?Would ffmpeg even work then ?
  • Or somehow pipe the content, to
    ffmpeg’s stdin, and tell it to input from pipe (Would it still be
    more efficient, than downloading and saving the file, then running
    ffmpeg ) ?

  All suggestions are welcomed !

  EDIT

  As for SushiHangover advice, i was able to implement it via piping,i came up with two ways :

  Process ffmpegProcess = new Process();
  
  ffmpegProcess.StartInfo.FileName = "ffmpeg";
  
  ffmpegProcess.StartInfo.Arguments = ....
  
  ffmpegProcess.StartInfo.UseShellExecute = false;
  
  ffmpegProcess.StartInfo.RedirectStandardInput = true;
  
  ffmpegProcess.Start();
  
  
  
  //Way 1
  
  var data = await GetBytesAsync();
  
  await ffmpegProcess.StandardInput.BaseStream.WriteAsync(b, 0,b.Length);
  
  
  
  // Way 2
  
  await (await GetStreamAsync()).CopyToAsync(ffmpegProcess.StandardInput.BaseStream);

  Which both work, but they aren’t efficient in term of bandwidth as ffmpeg itself, i tested the network traffic with NetBalancer.

  Way 1 (Fresh Data - First time running program) : 401 KB Upload/ 19.7 MB Download
  Way 1 (Second time running program) : 334.3 KB Upload/ 17.7 MB Download
  Way 2 (Second time running program) : 370 KB Upload/ 16.6 MB Download
  Through FFmpeg Only (Fresh Data - First time running program) : 142.4 KB Upload / 5.3 MB Download
  Through FFmpeg Only (Second time running program) : 67.5 KB Upload / 3.7 MB Download

  Who can i overcome the gap ? I speculate that ffmpeg only reads the headers, and able to download only the needed audio stream based on my arguments, rather than the whole video as my snippets do.

• Which audio codecs are supported for HLS ?

  22 janvier 2017, par Jofsey

  Does HLS protocol specify audio codec ? If it does, which are supported ?

  I’ve tried to search, but found different lists :

  MP3, HE-AAC or AC-3

  according to wikipedia

  AAC, AAC-LC, HE-AAC (accPlus) v1 & v2, MP3

  according to this

  AAC-LC, HE-AACV1-2, AC-3, and EC-3

  according to FairPlay overview (which is subset of HLS)

• ppc : Adjust AltiVec function suffix

  19 janvier 2017, par Vittorio Giovara

  ppc : Adjust AltiVec function suffix
  Architecture should always be the last element.
  

  • [DH] common/mc.c
  • [DH] common/pixel.c
  • [DH] common/ppc/mc.c
  • [DH] common/ppc/mc.h
  • [DH] common/ppc/pixel.c
  • [DH] common/ppc/pixel.h