Recherche avancée

Sur d’autres sites (9556)

• AAC : Fix M/S stereo encoding

  3 mars 2015, par Claudio Freire

  AAC : Fix M/S stereo encoding
  This patch fixes a pointer arithmetic bug in adjust_frame_information that resulted in heavily corrupted audio when using M/S encoding. Also, a backup copy of untransformed coefficients has to be kept around or attempts at re-processing the frame (which happens when hevavily overspending bits during transients) will result in re-encoding of the coefficients and subsequent corruption of the resulting stream.
  A/B testing shows the bug as corrected, but still cannot prove that M/S coding is a win at least in numbers. Limited listening tests do show improvement on M/S encoded samples in lower bitrates, but they’re hidden among the other artifacts that remain to be corrected in the encoder.
  Some of the regressions flagged in the report do show poor stereo image (but not buggy), so M/S encoding is clearly not good enough yet to be defaulted to auto.
  In numbers, Patched against Unpatched, stereo_mode auto :
    Files : 114
  
    Bitrates : 6
  
    Tests : 683
    Serious Regressions : 0 (0%)
  
    Regressions : 0 (0%)
  
    Improvements : 227 (33%)
  
    Big improvements : 92 (13%)
  
    Worst regression - mybloodrusts.wv - 256k
  
      - StdDev : 28.61       pSNR : -0.43     maxdiff : 1372.00
  
    Best improvement - 60.wv - 384k
  
      - StdDev : -369.57     pSNR : 45.02     maxdiff : -13322.00
  
    Average          - StdDev : -80.56       pSNR : 2.49      maxdiff : -8858.00
  Patched against Unpatched stereo_mode ms_off shows no difference.
  Patched stereo_mode auto vs Unpatched stereo_mode ms_off shows a small average improvement, just not too significant :
    Serious Regressions : 0 (0%)
  
    Regressions : 10 (1%)
  
    Improvements : 45 (6%)
  
    Big improvements : 2 (0%)
  
    Worst regression - Illinois.wv - 256k
  
      - StdDev : 33.20       pSNR : -2.03     maxdiff : 477.00
  
    Best improvement - song_of_circomstances.flac - 384k
  
      - StdDev : -3.97       pSNR : 7.61      maxdiff : -826.00
  
    Average          - StdDev : -10.25       pSNR : 0.20      maxdiff : -281.00
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/aac.h
  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aacenc.c

• How can I convince ffserver to save a locally-sourced webcam stream to a file in high resolution AND stream it in lower resolution ?

  2 novembre 2015, par Dominic Jacobssen

  We have a remote Linux machine, accessible over VPN, which has a USB webcam. We want to use this for video conferencing, but we also want to store the stream for archiving.

  Since the streaming bandwidth is limited, it makes sense to capture the stream on the same machine as the webcam and rsync that across after-the-fact, rather than trying to capture the streamed content, which is necessarily going to be poor quality.

  We’re trying to use ffmpeg and ffserver to achieve this, but with little success. Most of the articles on the internet either deal with just streaming a webcam, or rebroadcasting a remote stream. We found we had to recompile ffserver because of a missing "my_addr->sin_family = AF_INET ;" in the version of ffserver.c we had been using, since fixed in git.

  Here’s the ffserver.conf we’re trying to use :

  Port 43688
  
  BindAddress 127.0.0.1
  
  MaxHTTPConnections 2000
  
  MaxClients 1000
  
  MaxBandwidth 1000
  
  CustomLog -
  
  NoDaemon
  
  <feed>
  
  ReadOnlyFile /tmp/feed.ffm
  
  FileMaxSize 20M
  
  ACL allow 127.0.0.1
  
  </feed>
  
  <stream>
  
  Feed feed.ffm
  
  Format mp4
  
  VideoSize qvga
  
  VideoGopSize 12
  
  VideoHighQuality
  
  Video4MotionVector
  
  VideoCodec libx264
  
  VideoBitRate 100
  
  VideoBufferSize 40
  
  VideoFrameRate 5
  
  VideoQMin 3
  
  VideoQMax 31
  
  AudioCodec libfaac
  
  AudioBitRate 32
  
  AudioChannels 2
  
  AudioSampleRate 22050
  
  ACL allow localhost
  
  </stream>

  When we fire this up, we get the error :

  Unable to create feed file '/tmp/feed.ffm' as it is marked readonly

  Fair enough, but this is not what is implied in the docs. Changing the directive to :

  File /tmp/feed.ffm

  allows ffserver to fire up and appear to sit and wait for ffmpeg to connect to it. However, when we fire up ffmpeg with the command :

  ffmpeg -f alsa -i pulse -r 16000 -f video4linux2 -s qvga -i /dev/video0 -r 5 -f mp4 -vcodec libx264 -sameq -acodec libfaac -ab 32k http://127.0.0.1:43688/feed.ffm

  then the webcam lights up and ffserver acknowledges the connection with the messages :

  New connection: POST /feed.ffm
  
  [POST] "/feed.ffm HTTP/1.1" 200 0

  but after a few seconds we get the errors :

  [mp4 @ 0x264b160] muxer does not support non seekable output
  
  Could not write header for output file #0 (incorrect codec parameters ?)

  We’ve tried various other formats (mpeg, mpegts, avi) and codecs (mpeg1video, mpeg2video, mpeg4), all without success.

  Moreover, we were under the impression that ffserver could reencode input format to a lower resolution for streaming, but if the stream resolution doesn’t match the feed resolution, we get an error about the resolutions not matching.

  Has anyone ever managed to get this working correctly ? I’ve read about vlc being able to do something like this, but the vlc command lines are well nigh impenetrable.

  Thanks !

  Dominic

• Ffmpeg concat demuxer shifts video stream start time

  9 octobre 2020, par cake_donkey

  Summary

  


  Ffmpeg concat demuxer shifts video stream start time when invoked with -c copy option.

  


  Reproduction

  


  Given an before.mp4 containing video and audio streams both with start_time=0 and start_pts=0.

  


  Given concat demuxer input file concat.txt with contents :

  


  file before.mp4


  


  Run command ffmpeg -f concat -i concat.txt -c copy concat.mp4

  


  Run command ffprobe concat.mp4 -show_streams and observe that video stream start_time and start_pts are now non-zero (in my tests, the magnitude of this shift is small, on the scale of 0 -> 0.022969).

  


  This causes the processed video, when opened using QuickTime player on Mac, to initially display a blank frame, although the rest of the video plays normally. In the image linked below, the left is what we see when first opening before.mp4 ; the right is what we see when first opening concat.mp4 :

  


  https://i.stack.imgur.com/lWxgF.jpg

  


  Note that this issue occurs when concat demuxer is used to concatenate multiple mp4 files too. I used only one file above for ease of reproduction.

  


  I understand that this issue may be dependent on the codecs used. Therefore, I've included the ffprobe output for before.mp4 below :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'before.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.45.100
  Duration: 00:00:06.50, start: 0.000000, bitrate: 998 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1024x768 [SAR 1:1 DAR 4:3], 865 kb/s, 50 fps, 50 tbr, 12800 tbn, 100 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 126 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


  


  What I would like to do

  


  Invoke concat demuxer with -c copy (i.e. without reencoding) without unexpected adjustments to output video stream start time.

  


  I have a limited understanding of audio and video codecs and containers, so any suggestions on why this issue might occur, whether or not it could be fixed by ffmpeg, or suggestions for any other workarounds would be greatly appreciated !

  


  Workarounds I've tried

  


  start_time and start_pts are reset to 0 when the processed video is reencoded without any filters : ffmpeg -i concat.mp4 concat_reencoded.mp4.

  


  This issue is not present when concat demuxer is invoked without -c copy option.

  


  However, both of the above are undesirable since reencoding degrades video quality, which I would like to avoid.

  


  This issue is also not present if before.mp4 is remuxed to before.mkv via ffmpeg -i before.mp4 -c copy before.mkv before being processed by concat demuxer. However, this causes a slight change in fps (e.g. 30 -> 29.96) which I also haven't figured out how to avoid without reencoding.