Recherche avancée

Sur d’autres sites (4751)

• Video files recorded in Google Chrome have stuttering audio

  4 juin 2018, par maxpaj

  Background

  I’m developing a platform where users can record videos of themselves or their screen and send them as video messages to customers / clients.

  I have limited users to only using my application with Google Chrome and I’m using the MediaRecorder API to record the video data from the users screen or webcamera. The codecs that are used for recording are VP8/OPUS (WEBM container).

  I need the videos to run in as many browsers as possible, so I’m using a 3rd party service to transcode videos from whatever format I’m getting from the users to a H.265/AAC MP4 container (caniuse MPEG-4/H.264).

  Issue

  Lately I’ve seen that some videos recorded on Mac OSX machines have the video and audio out of sync or that the video and audio stutters, depending on which player I’m using. I call these video files corrupt, for lack of a better word. Playing a corrupt file in Google Chrome renders smooth playing audio. Playing the video in VLC on my Windows machine renders stuttering audio.

  When I run the corrupt video files through the transcoding service I get video files with stuttering audio, no matter which player I’m using.

  This is an unwanted result and pretty much unacceptable since the audio needs to be smooth in order for the recipient of a video to not be bothered with the quality.

  Debugging

  According to the transcoding service support, this happens because of their mechanisms that try to sync up the audio and video from the corrupt file :

  Inspecting our encoding logs, I’ve noticed the following kind of
  warnings :

  [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0] pcm_encode_frame :
  filling in for 5856 missing samples (122 ms) before pts 40800 to
  correct sync ! [2018-05-16 14:08:38.009] [pcm_s16le @ 0x1d608c0]
  pcm_encode_frame : dropping 2880 samples (60 ms) at pts 43392 to help
  correct sync to -3168 samples (-66 ms) !

  The problem here comes from the way that the audio in the original
  source file is encoded.

  -

  you should ensure that the audio is not out of sync (audio timestamps
  are correct) in your source file before submitting the job

  Running a corrupt file through ffmpeg on my own machine, re-encoding with the same codecs, produces the same kind of stuttering video. The logs produce an alarming amount of errors. Here is a sample of the log output :

  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 194.8kbits/s dup=0 drop=5 speed=0.31x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15394; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15434, current: 15414; changing to 15434. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 193.3kbits/s dup=0 drop=5 speed=0.309x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15499; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15539, current: 15519; changing to 15539. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in timeitrate= 192.0kbits/s dup=0 drop=5 speed=0.308x
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15627; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [webm @ 0000029938e09b00] Non-monotonous DTS in output stream 0:1; previous: 15667, current: 15647; changing to 15667. This may result in incorrect timestamps in the output file.
  
  [libopus @ 0000029938e24d80] Queue input is backward in time

  I tried running the same inputs through another transcoding service and those outputs worked a lot better - video was still stuttering but the audio played smoothly, which is more important to the use case of my application.

  To my knowledge, this have so far only occurred for users on Mac OSX machines.

  Questions

  1. Is there anything I can do to have the files work better ? Or is this entirely a consequence of how encoding of video and audio in Google Chrome works ?

  2. One step in the right direction would be to just be able to detect when the video is corrupt. How can I do that ?

• ffmpeg : stream copy from .mxf into NLE-compatible format

  9 juin 2013, par David

  Because my NLE software does not support the .mxf-files from Canon XF100 I need to convert them into a supported format.

  As far as I know, mxf-files are just another container format for mpeg2 streams, so it would be really nice to extract the streams and place them into another container (without reencoding).

  I think ffmpeg can do this – correct me if I'm wrong – by running the following command :

  ffmpeg -i in.mxf -vcodec copy out.m2ts (or .ts, .mts, ...)

  ffmpeg finishes without errors after about 2 seconds (in.mxf is abut 170mb) :

  c:\video>c:\ffmpeg\bin\ffmpeg -i in.MXF -vcodec copy out.m2ts
  
  ffmpeg version N-53680-g0ab9362 Copyright (c) 2000-2013 the FFmpeg developers
  
    built on May 30 2013 12:14:03 with gcc 4.7.3 (GCC)
  
    configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-av
  
  isynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enab
  
  le-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetyp
  
  e --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --ena
  
  ble-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-l
  
  ibopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libsp
  
  eex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-
  
  amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --
  
  enable-libxvid --enable-zlib
  
    libavutil      52. 34.100 / 52. 34.100
  
    libavcodec     55. 12.102 / 55. 12.102
  
    libavformat    55.  8.100 / 55.  8.100
  
    libavdevice    55.  2.100 / 55.  2.100
  
    libavfilter     3. 73.100 /  3. 73.100
  
    libswscale      2.  3.100 /  2.  3.100
  
    libswresample   0. 17.102 /  0. 17.102
  
    libpostproc    52.  3.100 / 52.  3.100
  
  Guessed Channel Layout for  Input Stream #0.1 : mono
  
  Guessed Channel Layout for  Input Stream #0.2 : mono
  
  Input #0, mxf, from 'in.MXF':
  
    Metadata:
  
      uid             : 1bb23c97-6205-4800-80a2-e00002244ba7
  
      generation_uid  : 1bb23c97-6205-4800-8122-e00002244ba7
  
      company_name    : CANON
  
      product_name    : XF100
  
      product_version : 1.00
  
      product_uid     : 060e2b34-0401-010d-0e15-005658460100
  
      modification_date: 2013-01-06 11:05:02
  
      timecode        : 01:42:14:22
  
    Duration: 00:00:28.32, start: 0.000000, bitrate: 51811 kb/s
  
      Stream #0:0: Video: mpeg2video (4:2:2), yuv422p, 1920x1080 [SAR 1:1 DAR 16:9
  
  ], 25 fps, 25 tbr, 25 tbn, 50 tbc
  
      Stream #0:1: Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
  
      Stream #0:2: Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
  
  Output #0, mpegts, to 'out.m2ts':
  
    Metadata:
  
      uid             : 1bb23c97-6205-4800-80a2-e00002244ba7
  
      generation_uid  : 1bb23c97-6205-4800-8122-e00002244ba7
  
      company_name    : CANON
  
      product_name    : XF100
  
      product_version : 1.00
  
      product_uid     : 060e2b34-0401-010d-0e15-005658460100
  
      modification_date: 2013-01-06 11:05:02
  
      timecode        : 01:42:14:22
  
      encoder         : Lavf55.8.100
  
      Stream #0:0: Video: mpeg2video, yuv422p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-3
  
  1, 25 fps, 90k tbn, 25 tbc
  
      Stream #0:1: Audio: mp2, 48000 Hz, mono, s16, 128 kb/s
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (copy)
  
    Stream #0:1 -> #0:1 (pcm_s16le -> mp2)
  
  Press [q] to stop, [?] for help
  
  frame=  532 fps=0.0 q=-1.0 size=  143511kB time=00:00:21.25 bitrate=55314.1kbits
  
  frame=  561 fps=435 q=-1.0 size=  151254kB time=00:00:22.42 bitrate=55242.0kbits
  
  frame=  586 fps=314 q=-1.0 size=  158021kB time=00:00:23.41 bitrate=55288.0kbits
  
  frame=  609 fps=255 q=-1.0 size=  164182kB time=00:00:24.34 bitrate=55235.4kbits
  
  frame=  636 fps=217 q=-1.0 size=  171463kB time=00:00:25.42 bitrate=55235.1kbits
  
  frame=  669 fps=194 q=-1.0 size=  180133kB time=00:00:26.72 bitrate=55226.3kbits
  
  frame=  699 fps=173 q=-1.0 size=  188326kB time=00:00:27.92 bitrate=55256.6kbits
  
  frame=  708 fps=169 q=-1.0 Lsize=  190877kB time=00:00:28.30 bitrate=55233.6kbit
  
  s/s
  
  video:172852kB audio:442kB subtitle:0 global headers:0kB muxing overhead 10.1461
  
  18%

  Unfortunately the output file turns out to be displayed correctly only by vlc player.
  My NLE-software (Cyberlink Power Director) is able to open the file but most of the picture is green. Only a few pixels on the left edge show the original video :

  output file

  Any ideas how to solve that problem ? Is there a better way to use .mxf-files in NLE-software without native support ?

  thanks in advance

• NAB 2010 wrapup

  15 avril 2010

  Another year of NAB has come and gone. Making it out of Vegas with some remaining faith in humanity seems like a successful outcome. So, anything worth talking about at the show ?

  First off, there’s 3d. 3D is The Next Big Thing, and that was obvious to anyone who spent half a second on the show floor. Everything from camera rigs, to post production apps, to display technology was all 3d, all the time. I’m not a huge fan of 3d in most cases, but the industry is at least feigning interest.

  Luckily, at a show as big as NAB, there’s plenty of other cool stuff to see. So, what struck my fancy ?

  First off, Avid and Adobe were showing new versions of Media Composer and Premiere. Both sounded pretty amazing on paper, but I must say I was somewhat underwhelmed by both in reality. Premiere felt a little rough around the edges - the Mercurial Engine wasn’t the sort of next generation tech that I expected. Media Composer 5 has some nice new tweaks, but it’s still rather Avid-y - which is good for Avid people, less interesting for the rest of us.

  In other software news, Blackmagic Design was showing off some of what they’re doing with the DaVinci technology that they acquired. Software-only Da Vinci Resolve for $999 is a pretty amazing deal, and the demos were quite nice. That said, color correction is an art, so just making the technology cheaper isn’t necessarily going to dramatically change the number of folks who do it well - see Color.

  Blackmagic also has a pile of new USB 3.0 hardware devices, including the absolutely gorgeous UltraStudio Pro. Makes me pine for USB 3.0 on the mac.

  On the production side, we saw new cameras from just about everyone. To start at the high end, the Arri Alexa was absolutely stunning. Perhaps the nicest digital cinema footage I’ve seen. Not only that, but they’ve worked out a usable workflow, recording to ProRes plus RAW. At the price point they’re promising, the world is going to get a lot more difficult for RED.

  Sony’s new XDCam EX gear is another good step forward for that format. Nothing groundbreaking, but another nice progression. I was kind of hoping we’d see 4:2:2 EX gear from them, but I suppose they need to justify the disc based formats for a while longer.

  The Panasonic AG-AF100 is another interesting camera, bringing micro 4/3rds into video. The only strange thing is the recording side - AVCHD to SD cards. While I’m thrilled to see them using SD instead of P2, it sure would have been nice to have an AVCIntra option.

  Finally, Canon’s 4:2:2 XF cams are a nice option for the ENG/EFP market. Nothing groundbreaking, aside from the extra color sampling, but it’s a nice step up from what they’ve been doing.

  Speaking of Canon, it’s interesting to see the ways that the 5d and 7d have made their way into mainstream filmmaking. At one point, I thought they’d be relegated to the indie community - folks looking for nice DoF on a budget. Instead, they seem to have been adopted by a huge range of productions, from episodic TV to features. While they’re not right for everyone, the price and quality make them an easy choice in many cases.

  One of the stars of the show for me was the GoPro, a small waterproof HD camera that ships with a variety of mounts, designed to be used in places where you couldn’t or wouldn’t use a more full featured camera. No LCD, just a record button and a wide angle lens. I bought two.

  Those are the things that stand out for me. While there was plenty of interesting stuff to be seen, given the current economic conditions at the University, I wasn’t exactly in a shopping mindset. The show definitely felt more optimistic than it did last year, and companies are again pushing out new products. However, attendances was about 20% lower than 2008, and that was definitely noticeable on the show floor.