Recherche avancée

Sur d’autres sites (4471)

• avcodec/mpegvideo_dec, rv34 : Simplify check for "does pic exist ?"

  28 avril 2024, par Andreas Rheinhardt

  avcodec/mpegvideo_dec, rv34 : Simplify check for "does pic exist ?"
  The days in which an MPVPicture* is set with the corresponding frame
  
  being blank are over ; this allows to simplify some checks.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/mpegvideo_dec.c
  • [DH] libavcodec/rv34.c

• flvdec : Honor the "flv_metadata" option for the "datastream" metadata field

  9 février 2024, par Martin Storsjö

  flvdec : Honor the "flv_metadata" option for the "datastream" metadata field
  By default the option "flv_metadata" (internally using the field
  
  name "trust_metadata") is set to 0, meaning that we don't allocate
  
  streams based on information in the metadata, only based on
  
  actual streams we encounter. However the "datastream" metadata field
  
  still would allocate a subtitle stream.
  When muxing, the "datastream" field is added if either a data stream
  
  or subtitle stream is present - but the same metadata field is used
  
  to preemtively create a subtitle stream only. Thus, if the field
  
  was added due to a data stream, not a subtitle stream, the demuxer
  
  would create a stream which won't get any actual packets.
  If there was such an extra, empty subtitle stream, running
  
  avformat_find_stream_info still used to terminate within reasonable
  
  time before 3749eede66c3774799766b1f246afae8a6ffc9bb. After that
  
  commit, it no longer would terminate until it reaches the max
  
  analyze duration, which is 90 seconds for flv streams (see
  
  e6a084641aada7a2e4672172f2ee26642800a361,
  
  24fdf7334d2bb9aab0abdbc878b8ae51eb57c86b and
  
  f58e011a1f30332ba824c155078ca701e29aef63).
  Before that commit (which removed the deprecated AVStream.codec), the
  
  "st->codecpar->codec_id = AV_CODEC_ID_TEXT", set within the demuxer,
  
  would get propagated into st->codec->codec_id by numerous
  
  avcodec_parameters_to_context(st->codec, st->codecpar), then further
  
  into st->internal->avctx->codec_id by update_stream_avctx within
  
  read_frame_internal in libavformat/utils.c (demux.c these days).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/flvdec.c

• Converting a rtsp stream to hls but got error "Non-monotonous DTS in output stream 0:0"

  8 mai 2023, par Devi

  I'm converting a rtsp live camera stream to hls using ffmpeg, it is all good the first few hours, each segment file sizes around 1.1M, which match the setting of segment_time of 5 seconds. However, when I check back a few days later, the size of each segment file became 20G, and I found that some error are logged.

  


  My current implementation is like this :

  


  ffmpeg -fflags nobuffer \
           -rtsp_transport tcp \
           -i rtsp://abc.com/live.sdp \
           -fps_mode 0 \
           -copyts \
           -c copy \
           -movflags frag_keyframe+empty_moov \
           -hls_flags delete_segments+append_list \
           -f segment \
           -segment_list_flags live \
           -segment_time 5 \
           -segment_list_size 3 \
           -segment_format mpegts \
           -segment_list /app/mount/test/live.m3u8 \
           -segment_list_type m3u8 \
           -segment_wrap 10 \
           /app/mount/test/%04d.ts \
           2>&1 


  


  Here's the logged error :

  


  [segment @ 0x7fe5123101c0] Non-monotonous DTS in output stream 0:0; previous: 14179898636, current: 11332822107; changing to 14179898637. This may result in incorrect timestamps in the output file.
[segment @ 0x7fe5123101c0] stream:0 start_pts_time:157550 pts:14179898637 pts_time:157554 dts:14179898637 dts_time:157554 -> pts:14179898637 pts_time:157554 dts:14179898637 dts_time:157554
[NULL @ 0x7fe510744880] unknown SEI type 229
[segment @ 0x7fe5123101c0] Non-monotonous DTS in output stream 0:0; previous: 14179898637, current: 11332823907; changing to 14179898638. This may result in incorrect timestamps in the output file.
[segment @ 0x7fe5123101c0] stream:0 start_pts_time:157550 pts:14179898638 pts_time:157554 dts:14179898638 dts_time:157554 -> pts:14179898638 pts_time:157554 dts:14179898638 dts_time:157554
[segment @ 0x7fe5123101c0] Non-monotonous DTS in output stream 0:0; previous: 14179898638, current: 11332825707; changing to 14179898639. This may result in incorrect timestamps in the output file.
[segment @ 0x7fe5123101c0] stream:0 start_pts_time:157550 pts:14179898639 pts_time:157554 dts:14179898639 dts_time:157554 -> pts:14179898639 pts_time:157554 dts:14179898639 dts_time:157554


  


  I've tried :

  


  

  1. Changing the option -fps_mode with passthrough, vfr, drop.

  


  2. Changing the option -c with -c copy, -c:a copy -c:v libx264.

  


  


  None of the above works for me.