Recherche avancée

Sur d’autres sites (5663)

• FFMpeg copy stream SEI type 162 error

  13 juillet 2015, par Vishal Shah

  I am using FFMpeg to copy an RTSP stream to an RTMP stream. Both of which are network streams. This is the command I am using.

  ffmpeg -re -i rtsp ://url.to/rtsp/stream -c copy -f flv rtmp ://target.rtmp/uri/stream

  I am receiving data on the youtube live control room. But After a point I get an error like this in my FFMpeg console and then the data transfer on youtube live stops.

  SEI type 162 size 1496 truncated at 1280

  Can someone throw light on what this error means and how to resolve it ?

  Note that the RTSP stream is over the network

• Changes to the WebM Open Source License

  5 juin 2010, par noreply@blogger.com (John Luther)

  You’ll see on the WebM license page and in our source code repositories that we’ve made a small change to our open source license. There were a couple of issues that popped up after we released WebM at Google I/O a couple weeks ago, specifically around how the patent clause was written.

  As it was originally written, if a patent action was brought against Google, the patent license terminated. This provision itself is not unusual in an OSS license, and similar provisions exist in the 2nd Apache License and in version 3 of the GPL. The twist was that ours terminated "any" rights and not just rights to the patents, which made our license GPLv3 and GPLv2 incompatible. Also, in doing this, we effectively created a potentially new open source copyright license, something we are loath to do.

  Using patent language borrowed from both the Apache and GPLv3 patent clauses, in this new iteration of the patent clause we’ve decoupled patents from copyright, thus preserving the pure BSD nature of the copyright license. This means we are no longer creating a new open source copyright license, and the patent grant can exist on its own. Additionally, we have updated the patent grant language to make it clearer that the grant includes the right to modify the code and give it to others. (We’ve updated the licensing FAQ to reflect these changes as well.)

  We’ve also added a definition for the "this implementation" language, to make that more clear.

  Thanks for your patience as we worked through this, and we hope you like, enjoy and (most importantly) use WebM and join with us in creating more freedom online. We had a lot of help on these changes, so thanks to our friends in open source and free software who traded many emails, often at odd hours, with us.

  Chris DiBona is the Open Source Programs Manager at Google.

  

• ffmpeg encoding slowly, not using much CPU

  30 juin 2012, par eblume

  I am using the latest (as of this post) version of ffmpeg on OS X as installed via homebrew (an OS X 3rd-party package manager with a good reputation.) I am trying to encode video that was recorded using Fraps on another machine to reduce the file size while preserving as much quality as is reasonably possible.

  Fraps records video in a .avi container and I believe does absolutely no encoding - instead, it's just a stream of image files. The resulting files are often enormous, obviously. I want to set up a cron job that finds recorded files and encodes them to H.264 with some sort of audio codec (I'm currently using libmp3lame but will revisit it when I get video working right - will probably switch to a lossless audio codec.)

  My problem is that while encoding seems to be working exactly how I want it - very few compression artifacts but about 5% of the original size - the encoding is taking forever. I'm averaging about 1.5 encoded frames per second, and these are 2-3 hours of 30FPS video. On top of that, my CPU is never fully utilized. On my dual-core CPU I am getting a median usage of about 40% of one core, with occasional peaks of 140% to 160%.

  So the question is : How can I speed up encoding ? I'm sure there's got to be some options I'm missing out on.

  Here's the command I use :

  ffmpeg -i INFILE -c copy -c:a libmp3lame -ar 44100 -q:a 5 \
  
                -threads 0 -c:v libx264 OUTFILE

  Thanks !

  EDIT : Actually, it looks like this command isn't compressing that well either - I'll do some digging but it seems that this might be being too generous with the bitrate for H.264. At first I was getting around 2Mb/s but it's gone up to almost 20Mb/s - looks like I'm basically not compressing at all.