Sur d’autres sites (7651)

• 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.

• FFmpeg - Wave64 (.w64) file format : question regarding chunk GUIDs

  26 janvier 2023, par pdu

  I am having trouble understanding the headers of the Wave64 (.w64) files generated by ffmpeg and especially the GUIDs.

  


  The specification

  


  I have found this document which describes the file format and the GUIDs. I have also found other websites (here and here) that (indirectly) point to the same document. So this document is the only thing I have.

  


  According to this document the GUIDs are 128bits/16bytes long and should start with the FourCC of the Wave file format, but in lowercase instead of uppercase (see page 3). It also says that the 64bits fields are stored in little-endian (see item 3 of the list page 1), but it does not say anything about 128bits fields (but it should be the same).
For example the GUID for the RIFF chunk is : 66666972-912E-11CF-A5D6-28DB04C10000.

  


  The problem

  


  When I open a .w64 file generated by ffmpeg with an hex editor, I get this : 72 69 66 66 2E 91 CF 11 A5 D6 28 DB 04 C1 00 00. At the beginning, 76 69 66 66 stands for riff in ASCII. We can see that 0x66666972 from the spec was indeed stored in little-endian order (so far, so good). If we continue, we have 2E 91 and CF 11, which are still little-endian for 0x912E and 0x11CF. But now it gets weird : the following group of bytes are : A5 D6 and 28 DB 04 C1 00 00 for 0xA5D6 and 0x28DB04C10000 in the spec. So it is in big-endian now ?

  


  For reference, the relevant ffmpeg source files are wavenc.c, w64.h and w64.c.
I have also found this thread where someone implemented a .wav to .w64 converter (see the .7z attachment in the first post) and the GUIDs are stored in the same way as ffmpeg.

  


  Conclusion

  


  Seeing that two different implementations are doing the same thing, it probably means that I am missing something. Do you have any explanation ?

  


• Wave64 (.w64) file format : question regarding chunk GUIDs

  24 janvier 2023, par pdu

  I am having trouble understanding the headers of the Wave64 (.w64) files generated by ffmpeg and especially the GUIDs.

  


  The specification

  


  I have found this document which describes the file format and the GUIDs. I have also found other websites (here and here) that (indirectly) point to the same document. So this document is the only thing I have.

  


  According to this document the GUIDs are 128bits/16bytes long and should start with the FourCC of the Wave file format, but in lowercase instead of uppercase (see page 3). It also says that the 64bits fields are stored in little-endian (see item 3 of the list page 1), but it does not say anything about 128bits fields (but it should be the same).
For example the GUID for the RIFF chunk is : 66666972-912E-11CF-A5D6-28DB04C10000.

  


  The problem

  


  When I open a .w64 file generated by ffmpeg with an hex editor, I get this : 72 69 66 66 2E 91 CF 11 A5 D6 28 DB 04 C1 00 00. At the beginning, 76 69 66 66 stands for riff in ASCII. We can see that 0x66666972 from the spec was indeed stored in little-endian order (so far, so good). If we continue, we have 2E 91 and CF 11, which are still little-endian for 0x912E and 0x11CF. But now it gets weird : the following group of bytes are : A5 D6 and 28 DB 04 C1 00 00 for 0xA5D6 and 0x28DB04C10000 in the spec. So it is in big-endian now ?

  


  For reference, the relevant ffmpeg source files are wavenc.c, w64.h and w64.c.
I have also found this thread where someone implemented a .wav to .w64 converter (see the .7z attachment in the first post) and the GUIDs are stored in the same way as ffmpeg.

  


  Conclusion

  


  Seeing that two different implementations are doing the same thing, it probably means that I am missing something. Do you have any explanation ?