Recherche avancée

Sur d’autres sites (9156)

• Replace remaining occurances of av_free_packet with av_packet_unref

  27 octobre 2015, par Hendrik Leppkes

  Replace remaining occurances of av_free_packet with av_packet_unref
  

  • [DH] doc/examples/decoding_encoding.c
  • [DH] doc/examples/demuxing_decoding.c
  • [DH] doc/examples/extract_mvs.c
  • [DH] doc/examples/filtering_audio.c
  • [DH] doc/examples/filtering_video.c
  • [DH] doc/examples/remuxing.c
  • [DH] doc/examples/transcoding.c
  • [DH] ffmpeg.c
  • [DH] ffplay.c
  • [DH] ffserver.c
  • [DH] libavcodec/avpacket.c
  • [DH] libavcodec/libopusenc.c
  • [DH] libavcodec/libvpxenc.c
  • [DH] libavcodec/utils.c
  • [DH] libavdevice/decklink_dec.cpp
  • [DH] libavdevice/dshow.c
  • [DH] libavdevice/openal-dec.c
  • [DH] libavfilter/lavfutils.c
  • [DH] libavfilter/src_movie.c
  • [DH] libavfilter/vf_mcdeint.c
  • [DH] libavfilter/vf_subtitles.c
  • [DH] libavformat/adp.c
  • [DH] libavformat/aiffenc.c
  • [DH] libavformat/ape.c
  • [DH] libavformat/apngenc.c
  • [DH] libavformat/asfdec_f.c
  • [DH] libavformat/avidec.c
  • [DH] libavformat/brstm.c
  • [DH] libavformat/concatdec.c
  • [DH] libavformat/electronicarts.c
  • [DH] libavformat/ffmdec.c
  • [DH] libavformat/flacdec.c
  • [DH] libavformat/flvdec.c
  • [DH] libavformat/gif.c
  • [DH] libavformat/iff.c
  • [DH] libavformat/img2enc.c
  • [DH] libavformat/libmodplug.c
  • [DH] libavformat/matroskadec.c
  • [DH] libavformat/movenc.c
  • [DH] libavformat/mpeg.c
  • [DH] libavformat/mpegts.c
  • [DH] libavformat/nutdec.c
  • [DH] libavformat/oggdec.c
  • [DH] libavformat/redspark.c
  • [DH] libavformat/rmdec.c
  • [DH] libavformat/sdr2.c
  • [DH] libavformat/siff.c
  • [DH] libavformat/subtitles.c
  • [DH] libavformat/swfdec.c
  • [DH] libavformat/tee.c
  • [DH] libavformat/utils.c
  • [DH] libavformat/vivo.c
  • [DH] libavformat/webpenc.c
  • [DH] libavformat/wtvenc.c
  • [DH] tests/api/api-band-test.c
  • [DH] tests/api/api-flac-test.c
  • [DH] tests/api/api-h264-test.c
  • [DH] tests/api/api-seek-test.c
  • [DH] tools/seek_print.c

• Send sprop-parameter-sets inband rather than in SDP

  21 janvier 2021, par Max

  I am trying to use ffmpeg to stream an MP4 file over rtp. I am sending the stream to a SFU server that will broadcast the stream to users. The clients are expecting to receive an h264 video stream with profile-level-id 42e01f. The issue I'm having is that the video received by the clients does not decode properly (just a black screen). If I transcode the video before sending, then everything works correctly. If I dump the SDP that describes what ffmpeg is sending, there is a distinct difference between the transcoded and non-transcoded version.

  


  For the non-transcoded version, my ffmpeg command looks like

  


  ffmpeg  '-re' \
  '-v' \
  'info' \
  '-protocol_whitelist' \
  'pipe,tls,file,http,https,tcp,rtp' \
  '-i' \
  '-f' 'mp4' \
  'https://storage.googleapis.com/my_bucket/file' \
  '-map' \
  '0:v:0' \
  '-c:v' \
  'copy' \
  '-f' \
  'rtp' \
  '-sdp_file' 'out.sdp' \
  'rtp://142.93.14.110:40425?rtcpport=45155'


  


  When I run this command, out.sdp contains the line

  


  a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z0LAH9kAUAW7AWoCAgKAAAH0gABdwAeMGSQ=,aMuMsg==; profile-level-id=42C01F


  


  However, if I change -c:v copy to -c:v libx264 -preset ultrafast, then the sdp line changes to a=fmtp:96 packetization-mode=1;. Given that there is no SDP exchange between ffmpeg and my SFU, I think the issue is that ffmpeg needs to be sending the sprops in-band rather than setting them in the sdp. Any help here would be amazing. The other possible issue is that the profile levels are sightly different.

  


• h264_mp4toannexb : Don't forget numOfPictureParameterSets

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Don't forget numOfPictureParameterSets
  The format of an AVCDecoderConfigurationRecord, the out-of-band
  
  extradata of H.264 in mp4, is as follows : First four bytes containing
  
  version, profile and level, one byte for the length size and one byte
  
  each for the number of SPS, followed by the SPS (each with its own size
  
  field), followed by a byte containing the number of PPS followed by the
  
  PPS with their size fields. While the number of SPS/PPS may be zero, the
  
  bytes containing these numbers are mandatory. Yet the byte containing
  
  the number of PPS has been ignored in two places :
  
  1. In the initial check for whether the extradata can contain an
  
  AVCDecoderConfigurationRecord. The minimum size is 7, not 6.
  
  2. No check is made for whether the extradata ended right after the last
  
  byte of the last SPS of the SPS array. Instead the first byte of the
  
  padding is read as if it were part of the extradata and contained the
  
  number of PPS (namely zero, given that the padding is zeroed). No error
  
  or warning was ever raised.
  
  This has been changed. Such truncated extradata is now considered
  
  invalid ; the check for 2. has been incorporated into the general size
  
  check.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c