Recherche avancée

Sur d’autres sites (8956)

• New Challenges

  14 mars 2013, par silvia

  I finished up at Google last week and am now working at NICTA, an Australian ICT research institute.

  My work with Google was exciting and I learned a lot. I like to think that Google also got a lot out of me – I coded and contributed to some YouTube caption features, I worked on Chrome captions and video controls, and above all I worked on video accessibility for HTML at the W3C.

  I was one of the key authors of the W3C Media Accessibility Requirements document that we created in the Media Accessibility Task Force of the W3C HTML WG. I then went on to help make video accessibility a reality. We created WebVTT and the <track> element and applied it to captions, subtitles, chapters (navigation), video descriptions, and metadata. To satisfy the need for synchronisation of video with other media resources such as sign language video or audio descriptions, we got the MediaController object and the @mediagroup attribute.

  I must say it was a most rewarding time. I learned a lot about being productive at Google, collaborate successfully over the distance, about how the WebKit community works, and about the new way of writing W3C standard (which is more like pseudo-code). As one consequence, I am now a co-editor of the W3C HTML spec and it seems I am also about to become the editor of the WebVTT spec.

  At NICTA my new focus of work is WebRTC. There is both a bit of research and a whole bunch of application development involved. I may even get to do some WebKit development, if we identify any issues with the current implementation. I started a week ago and am already amazed by the amount of work going on in the WebRTC space and the amazing number of open source projects playing around with it. Video conferencing is a new challenge and I look forward to it.

• Why is this ffmpeg conversion turning up trash ?

  12 octobre 2015, par DigitalJedi805

  So, the company I work for still archives some of our data in Windows Media format.

  I’ve written a C# application that loops through all of our WMVs, and in the event that a corresponding MP4 doesn’t exist, it fires off ffmpeg to convert the file.

  What I’m running into, is a combination of problems.

  When I run the following into ffmpeg ( rough C# ) :

  "-i " + File.FullName + " -vf scale=720:480 -b:v 512k -bufsize 512k -vcodec libx264 -acodec aac -strict experimental " + OutputPath

  I end up with a file that cannot play in our browser based player ( JWPlayer ), and cannot play on my local system in Windows Media Player.

  Additionally, the file is larger than my WMV, and is larger than the file I output with [roughly] the same parameters in AVS Video Converter.

  Furthermore, the file details don’t show any values for the video properties - as in, when I right click and go to properties->details, under ’video’, there is a list of length, height, width, frame rate, and bitrate - they are all empty - when I would very much expect some data normally.

  Does anyone have any idea how I can make the conversion more straightforward, or what might be creating the problem in the first place ?

  I’ve tried running this without scaling or bitrate parameters, and added them as an attempt to resolve the more core problem - obviously to no avail.

  For everyone’s appeasement...

  FFMPEG Output :

  video:537604kB audio:158748kB subtitle:0kB other streams:0kB global headers:0kB
  
  muxing overhead: 1.159483%
  
  [libx264 @ 0453d000] frame I:1234  Avg QP:19.98  size: 33645
  
  [libx264 @ 0453d000] frame P:94430 Avg QP:22.92  size:  3984
  
  [libx264 @ 0453d000] frame B:208152 Avg QP:30.67  size:   638
  
  [libx264 @ 0453d000] consecutive B-frames:  7.6%  1.8%  4.0% 86.6%
  
  [libx264 @ 0453d000] mb I  I16..4: 10.5% 61.2% 28.2%
  
  [libx264 @ 0453d000] mb P  I16..4:  0.4%  1.4%  0.3%  P16..4: 26.8%  9.3%  4.8%
  
   0.0%  0.0%    skip:57.0%
  
  [libx264 @ 0453d000] mb B  I16..4:  0.0%  0.0%  0.0%  B16..8: 21.6%  1.1%  0.2%
  
   direct: 0.4%  skip:76.6%  L0:42.6% L1:55.1% BI: 2.3%
  
  [libx264 @ 0453d000] 8x8 transform intra:65.1% inter:71.9%
  
  [libx264 @ 0453d000] coded y,uvDC,uvAC intra: 61.6% 59.3% 30.9% inter: 6.0% 6.7%
  
   1.7%
  
  [libx264 @ 0453d000] i16 v,h,dc,p: 34% 52%  7%  7%
  
  [libx264 @ 0453d000] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 27% 24%  3%  4%  4%  5%
  
   4%  7%
  
  [libx264 @ 0453d000] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 27% 38% 10%  3%  5%  4%  6%
  
   3%  5%
  
  [libx264 @ 0453d000] i8c dc,h,v,p: 47% 35% 14%  4%
  
  [libx264 @ 0453d000] Weighted P-Frames: Y:0.2% UV:0.1%
  
  [libx264 @ 0453d000] ref P L0: 67.8% 12.3% 14.3%  5.6%  0.0%
  
  [libx264 @ 0453d000] ref B L0: 88.7%  9.7%  1.6%
  
  [libx264 @ 0453d000] ref B L1: 92.6%  7.4%
  
  [libx264 @ 0453d000] kb/s:434.44

  I’ll make the video files available shortly.

• ffmpeg drop frames on purpose to lower filesize

  20 octobre 2014, par max

  Our security system records and archives our IP cameras streams with ffmpeg -use_wallclock_as_timestamps 1 -i rtsp://192.168.x.x:554/mpeg4 -c copy -t 60 my_input_video.avi

  I run it with crontab every minute so it creates videos of 60 seconds ( 15Mb) for each camera every minute. When an intrusion occurs, the camera sends a picture through FTP and a script called by incrontab :

  1- forwards immediately the picture by email

  2- selects the video covering the minute the intrusion occured, compress it with h264 (to 2,6Mb) and sends it by email

  It is working really well but if a thief crosses the path of various cameras, the connection to the SMTP server is not fast enough so video emails are delayed. I’d like to compress the videos even more to avoid that. I could lower the resolution (640x480 to 320x240 for example) but sometimes 640x480 is handy to zoom on something which looks to be moving...

  So my idea is to drop frames in the video in order to lower the filesize. I don’t care if the thief is walking like a "stop motion Lego" on the video, the most important is I know there is someone so I can act.

  mediainfo my_input_video.avi says Frame rate = 600.000 fps but it is of course wrong. FPS sent by IP cameras are always false because it varies with the network quality ; this is why i use "-use_wallclock_as_timestamps 1" in my command to record the streams.

  with ffmpeg -i  my_input_video.avi -vcodec h264 -preset ultrafast -crf 28 -acodec mp3 -q:a 5 -r 8 output.avi the video is OK but filesize is higher (3Mb)

  with ffmpeg -i  my_input_video.avi -vcodec h264 -preset ultrafast -crf 28 -acodec mp3 -q:a 5 -r 2 output.avi the filesize is lower (2,2Mb) but the video doesn’t work (it is blocked at the first frame).

  Creating a mjpeg video (mjpeg = not interlaced frames) in the middle of the process (first exporting to mjpeg with less frames and then exporting to h264) creates same results.

  Do you know how I can get my thief to walk like a "stop motion Lego" to lower the filesize to a minimum ?

  Thanks for any help