Recherche avancée

Sur d’autres sites (8107)

• `ffmpeg -f concat` don't work when all input streams appear to have the same spec

  2 octobre 2024, par Roy

  My ffmpeg command :

  


  ffmpeg -safe 0 -f concat -i list.txt -c copy out.mp4


  


  My 1st input file :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\Applications\ffmpeg_6.0_full\a.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf60.3.100
  Duration: 00:00:04.97, start: 0.000000, bitrate: 40 kb/s
  Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 2 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 27 kb/s, 30 fps, 30 tbr, 30k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc60.3.100 libx264


  


  My 2nd input file :

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\Applications\ffmpeg_6.0_full\b.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp41isom
    creation_time   : 2023-03-08T06:47:13.000000Z
    artist          : Microsoft Game DVR
    title           : PUBG: BATTLEGROUNDS
  Duration: 00:10:00.16, start: 0.000000, bitrate: 20885 kb/s
  Stream #0:0[0x1](und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 20739 kb/s, 30 fps, 30 tbr, 30k tbn (default)
    Metadata:
      creation_time   : 2023-03-08T06:47:13.000000Z
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : AVC Coding
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 131 kb/s (default)
    Metadata:
      creation_time   : 2023-03-08T06:47:13.000000Z
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]


  


  The above command outputs some warning signals :

  


  [mov,mp4,m4a,3gp,3g2,mj2 @ 0000025239902d40] Auto-inserting h264_mp4toannexb bitstream filter
[mp4 @ 00000252396fe5c0] Non-monotonous DTS in output stream 0:1; previous: 218112, current: 150024; changing to 218113. This may result in incorrect timestamps in the output file.
...
a lot of them
...
frame=25992 fps=21754 q=-1.0 Lsize= 1519621kB time=00:14:49.39 bitrate=13996.8kbits/s speed= 744x
video:9649kB audio:1519216kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown


  


  The resultant video can play the first part of the video correctly, then the video players either skips directly to the end of the video (MPC-HC), or don't render anything at all while timer passes as normal (VLC).

  


  My impression of the concat is that it requires all videos to have the same spec, which I think my input achieved (all the "Steam #0:0", etc, line matches). I only see the following difference, which I assumed that should be okay :

  


  

  1. Metadata are different both for the whole input (e.g. "major_brand") and for each stream (e.g. "encoder"). I assumed that metadata won't affect the processing.

  


  2. The order of video/audio streams are different in the two inputs : the 1st input file has audio then video ; the 2nd input file has video then audio. I assumed that ffmpeg knows the difference and won't concat a video stream to an audio stream.

  


  


  The full output of the command can be found in this pastebin : https://pastebin.com/Z5q97Uyg

  


• avcodec/aarch64/opusdsp_neon : Simplify opus_postfilter_neon

  7 février, par Krzysztof Pyrkosz

  avcodec/aarch64/opusdsp_neon : Simplify opus_postfilter_neon
  This change removes one extra floating point operation and simplifies
  
  load operations at the beginning of the loop by using dedicated register
  
  for each of the 5 pointers and interleaving it with calculations. The
  
  first case seems to be a bit slower, but the performance increase is
  
  substantial in the other two.
  A78 before :
  
  postfilter_15_neon :                                   1684.8 ( 4.23x)
  
  postfilter_512_neon :                                  1395.5 ( 5.10x)
  
  postfilter_1022_neon :                                 1357.0 ( 5.25x)
  After :
  
  postfilter_15_neon :                                   1742.2 ( 4.09x)
  
  postfilter_512_neon :                                  1169.8 ( 6.09x)
  
  postfilter_1022_neon :                                 1160.0 ( 6.12x)
  A72 before :
  
  postfilter_15_neon :                                   3144.8 ( 2.39x)
  
  postfilter_512_neon :                                  3141.2 ( 2.39x)
  
  postfilter_1022_neon :                                 3230.0 ( 2.33x)
  After :
  
  postfilter_15_neon :                                   2847.8 ( 2.64x)
  
  postfilter_512_neon :                                  2877.8 ( 2.61x)
  
  postfilter_1022_neon :                                 2837.2 ( 2.65x)
  x13s before :
  
  postfilter_15_neon :                                   1615.4 ( 2.61x)
  
  postfilter_512_neon :                                   963.1 ( 4.39x)
  
  postfilter_1022_neon :                                  963.6 ( 4.39x)
  After :
  
  postfilter_15_neon :                                   1749.6 ( 2.41x)
  
  postfilter_512_neon :                                   707.1 ( 5.97x)
  
  postfilter_1022_neon :                                  706.1 ( 5.99x)
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavcodec/aarch64/opusdsp_neon.S

• Duplicated PTS value when using rtsp transport UDP (H264 FU-A)

  25 janvier, par Christoph

  I’m implementing a packet loss counter based on the PTS from the av_packet, and it works fine when using RTSP/TCP as the transport mode. However, when I switched to RTSP/UDP, two packets consistently share the same PTS. This puzzled me because I assumed that av_read_frame would parse the stream and provide "valid" packets.

  


  In both cases, the stream is FU-A H.264, and I expected FFmpeg to handle reassembly in both transport modes identically. My understanding was that if UDP packets were splitted, FFmpeg would reassemble them into a single av_packet, similar to how it handles reassembly for TCP packets split due to MTU and FU-A.

  


  I could adapt my packet loss calculation by simply ignoring packets with the same PTS as the previous one, but I want to understand what’s happening here.

  


  TCP

  


  packet pts: -9223372036854775808, dts: -9223372036854775808, size: 52672, key-frame: true, discard: false, corrupt: false
packet pts: 3598, dts: 3598, size: 6034, key-frame: false, discard: false, corrupt: false
packet pts: 7196, dts: 7196, size: 5730, key-frame: false, discard: false, corrupt: false
packet pts: 10794, dts: 10794, size: 6153, key-frame: false, discard: false, corrupt: false
packet pts: 14392, dts: 14392, size: 2269, key-frame: false, discard: false, corrupt: false
packet pts: 17989, dts: 17989, size: 2656, key-frame: false, discard: false, corrupt: false
packet pts: 21587, dts: 21587, size: 2659, key-frame: false, discard: false, corrupt: false


  


  UDP

  


  packet pts: -9223372036854775808, dts: -9223372036854775808, size: 1391, key-frame: true, discard: false, corrupt: false
packet pts: 0, dts: 0, size: 109265, key-frame: true, discard: false, corrupt: false
packet pts: 3598, dts: 3598, size: 878, key-frame: false, discard: false, corrupt: false
packet pts: -> 3598, dts: 3598, size: 7728, key-frame: false, discard: false, corrupt: false
packet pts: 7195, dts: 7195, size: 887, key-frame: false, discard: false, corrupt: false
packet pts: -> 7195, dts: 7195, size: 7149, key-frame: false, discard: false, corrupt: false
packet pts: 10793, dts: 10793, size: 795, key-frame: false, discard: false, corrupt: false
packet pts: -> 10793, dts: 10793, size: 7777, key-frame: false, discard: false, corrupt: false
packet pts: 14391, dts: 14391, size: 119, key-frame: false, discard: false, corrupt: false
packet pts: -> 14391, dts: 14391, size: 2075, key-frame: false, discard: false, corrupt: false


  


  For reference here my code

  


  // PackageLossDetection detects possible packet loss based on PTS (Presentation Time Stamp) values.
// It compares the PTS of the packet with the expected PTS, calculated using the stream's time base and average frame rate.
// If the deviation between the expected and actual PTS exceeds a defined tolerance.
//
// Parameters:
//   - pkt: incoming packet whose PTS is to be checked.
//   - stream: the stream containing time base and average frame rate information.
func (s *AvSource) PackageLossDetection(pkt *astiav.Packet, stream *astiav.Stream) {

    // When using UDP as RTSP Transport packages in tuple has same PTS
    // TODO: Maybe we should invest more time to find a better solution
    if s.lastPts == pkt.Pts() {
        return
    }

    if pkt.Pts() > 0 {

        const tolerance = 4 // Allowable deviation in PTS steps
        if stream.AvgFrameRate().Num() == 0 {
            s.log.Warn().Str("stream", s.stream.Name).Msg("PackageLossDetection, no frame rate information available")
            return
        }

        var ptsBetween = stream.TimeBase().Den() * stream.TimeBase().Num() / stream.AvgFrameRate().Num()
        if math.Abs(float64(pkt.Pts()-(s.lastPts+int64(ptsBetween)))) > tolerance {
            s.log.Warn().Str("stream", s.stream.Name).Msgf("PackageLossDetection, PTS steps: %d, expected: %d, got: %d", int(ptsBetween), s.lastPts+int64(ptsBetween), pkt.Pts())
            utils.SafeIncrementInt64(&s.metrics.LossCount)
        }

        s.lastPts = pkt.Pts()
    }
}