Recherche avancée

Sur d’autres sites (5708)

• Best Web Video Encoding Practices for IOS (FFMpeg)

  21 juin 2012, par MagicMushroom

  I am working on an online video repository system for a client, written mostly in PHP. At the moment I am building a mobile version of our desktop website. Our desktop site allows users to watch videos in the browser, much like YouTube.

  My client uploads videos through the manager interface I have created, and my application uses FFmpeg on the server to transcode his videos into several resolutions and bitrates. I am no expert on FFmpeg, and while I do not know the ins and outs of each individual setting, I do understand how it works as a whole. Right now, we are using the mp4 container format with the h.264 codec to encode our videos. Our command looks like :

  ffmpeg -y -i "INPUT FILE.mov" -f mp4 -s 640x480 -vcodec libx264 -preset fast -maxrate 1500 -bitrate 1000 -bufsize 4096 -acodec libfaac -ab 192 -ac 2 "OUTPUT_FILE.mp4" >> "FILE.log" 2>&1 &

  I'm hoping to gain information about best practices with encoding video for web streaming on IOS and other mobile devices using FFmpeg. What resolutions and settings make for good mobile streaming video ? How can I ensure maximum compatibility across the sea of Android devices ?

• Node.js asynchronous video conversion slow

  9 décembre 2016, par lukstei

  I wrote a little website/service, which can download a video from a website (currently Youtube) and converts it on the fly to an mp3 file and sends this file back as the response.

  For example, you when you request http://localhost:8000/v=http ://www.youtube.com/watch?v=HhoewflkQu0, then it will download this video and response the audio layer encoded in MP3.

  This all works very well, my problem is that this is very slow and I can’t figure out why.

  ---

  Simplified the script behaves like this :

  Download the video and write it to the stdin of ffmpeg, and the stdout goes to the response.
  Video (MP4, FLV) -> FFMPEG -> MP3

  I used curl to figure out how fast the script is :

  $ curl http://localhost:8000/v=http://www.youtube.com/watch?v=HhoewflkQu0

  I get only about 5-10k.

  So why is this so slow ?

  1. The server, from which I am downloading the video is slow.
  2. The conversion is slow (because of a slow CPU).
  3. The data transfer between node.js -> FFMPEG is slow.

  I tried to download the video in a normal download manager, and i got about 320k, which is my normal download speed, so the first point isn’t the bottleneck.

  To point 2 and 3, I tried to write a local file to the stdin, and I got about 600k so that isn’t it either.

  So why is my script so slow, and what can I do to make it faster ?

  https://gist.github.com/1304637

  Thanks in advance.

• Decoding RIMM streaming file format

  10 septembre 2011, par Thomas

  I want to decode the video (visual) frames within a Blackberry RIMM file. So far I have a parser, and some corresponding container documentation from RIM. 

  The video codec is H264 and is explicitly set on the device using one of the video.encodings properties. However, FFMPEG is not able to decode the frames and this is driving me nuts.

  Edit 1 : The issues seems to be lack of SPS and PPS in the frames, and artificially inserting them have proven unsuccessful so far (all grey image). Blackberry 9700 sends

  0x00 0x00 0x ?? 0x ?? 0xType

  where Type is according to table 7-1 in the H264 spec (I and P frames). We believe the 0x ?? 0x ?? represent the size of the frame, however the size does not always correspond to the size found by the parser (the parser seems to be working correctly).

  I have a windows decoder codec from blackberry, called mc_demux_mp2_ds.ax, and can play some MPEG-4 files captured the same way, but it is a binary for windows. And the H264 files will not play either way. I am aware of previous attempts. The capture url for javax.microedition.media.Manager is

  encoding=video-3gpp_width=176_height=144_video_codec=H264_audio_codec=AAC

  and I am writing to an output stream. Some example files here.

  Edit 2 :Turns out that about 3-4 of the 12-15 available video capture modes are flat out failing and refusing to output data, even in the simplest of test applications. So any working solution should implement MPEG-4, H264 and H263 in both AMR and AAC, in so getting fallback alternatives when one sound codec and/or resolution fails. Reboots, hangs and what not litters the Blackberry video implementation and vary from firmware to firmware ; total suckage.