Recherche avancée

Sur d’autres sites (6820)

• ffmpeg - preserve time base and pts of all frames during transcode

  18 mars 2021, par jdizzle

  Context :

  


  I have an application that produces mp4s with HEVC encoding. I want to convert them to AVC for use in browser-based displaying. A very crucial part of how I want to use this is to preserve exact PTS times, as this is how we correlate the frames to other data streams not included in the video.

  


  Question :

  


  How do I make ffmpeg preserve this information across the transcode ? All the obvious flags seem to have no effect and ffmpeg just does whatever it wants.

  


  $ ffprobe -show_streams original.mp4 2>/dev/null | grep time_base
codec_time_base=16666667/500000000
time_base=1/1000


  


  Here is my convert command :

  


  $ ffmpeg -i original.mp4 -copyts -copytb 0 test.mp4


  


  And its result :

  


  $ ffprobe -show_streams test.mp4 2>/dev/null | grep time_base
codec_time_base=1/60
time_base=1/15360


  


  I would expect the time_bases to match. The PTS of the frames also don't match when doing ffprobe -show_frames

  


  EDIT :
@Gyan suggested using -video_track_timescale, but that didn't get the exact behavior I was looking for :

  


  $ sdiff <(ffprobe -show_frames test.mp4  | grep pkt_pts_time) <(ffprobe -show_frames original.mp4 | grep pkt_pts_time)
pkt_pts_time=0.000000                           pkt_pts_time=0.000000
pkt_pts_time=0.033000                           pkt_pts_time=0.033000
pkt_pts_time=0.067000                         | pkt_pts_time=0.066000
pkt_pts_time=0.100000                           pkt_pts_time=0.100000
pkt_pts_time=0.133000                           pkt_pts_time=0.133000
pkt_pts_time=0.167000                         | pkt_pts_time=0.166000
pkt_pts_time=0.200000                           pkt_pts_time=0.200000
pkt_pts_time=0.233000                           pkt_pts_time=0.233000
pkt_pts_time=0.267000                         | pkt_pts_time=0.266000
pkt_pts_time=0.300000                           pkt_pts_time=0.300000
pkt_pts_time=0.333000                           pkt_pts_time=0.333000
pkt_pts_time=0.367000                         | pkt_pts_time=0.366000
pkt_pts_time=0.400000                           pkt_pts_time=0.400000
pkt_pts_time=0.433000                           pkt_pts_time=0.433000
pkt_pts_time=0.467000                           pkt_pts_time=0.467000
pkt_pts_time=0.500000                           pkt_pts_time=0.500000
pkt_pts_time=0.533000                         | pkt_pts_time=0.532000
pkt_pts_time=0.567000                         | pkt_pts_time=0.565000
pkt_pts_time=0.600000                         | pkt_pts_time=0.598000
pkt_pts_time=0.633000                         | pkt_pts_time=0.631000
pkt_pts_time=0.667000                         | pkt_pts_time=0.665000
pkt_pts_time=0.700000                         | pkt_pts_time=0.698000
...


  


• FFMPEG Chapter Metadata added to a song file is sometimes off by 1 second

  6 février 2021, par Elthfa

  I attempted to add chapter metadata to a .opus file, but afterward, the file metadata showed timestamps different than the ones I attempted to add.
It seems to be adding an extra second to the timestamps under certain conditions.
I'm not sure if this is a bug, or if maybe I am just using the command wrong.

  


  Here are the commands I performed :

  


  First I removed all existing metadata from the file. I did this using a command I found on stack overflow :

  


  ffmpeg -i test_song.opus -c copy -map_metadata -1 -fflags +bitexact -flags:a +bitexact no_metadata.opus


  


  Then I added the new metadata from an external file I had written :

  


  ffmpeg -i no_metadata.opus -f ffmetadata -i metadata.txt -c copy -map_metadata 1 out.opus


  


  The file 'metadata.txt' looks like :

  


  ;FFMETADATA1
[CHAPTER]
TIMEBASE=1/1000
START=0
END=400
title=400 ms
[CHAPTER]
TIMEBASE=1/1000
START=400
END=500
title=100 ms
[CHAPTER]
TIMEBASE=1/1000
START=500
END=2000s
title=1500 ms
[CHAPTER]
TIMEBASE=1/1000
START=2000
END=97000
title=The Rest


  


  When I print out the basic data from the file, not all the timestamps shown match the ones I had in the metadata file.

  


  > ffmpeg -i out.opus
...
Input #0, ogg, from 'out.opus':
  Duration: 00:01:37.00, start: 0.000000, bitrate: 147 kb/s

    Chapter #0:0: start 0.000000, end 0.400000
    Metadata:
      title           : 400 ms

    Chapter #0:1: start 0.400000, end 1.500000
    Metadata:
      title           : 100 ms
    
    Chapter #0:2: start 1.500000, end 2.000000
    Metadata:
      title           : 1500 ms
    
    Chapter #0:3: start 2.000000, end 97.000000
    Metadata:
      title           : The Rest
...


  


  You can see the issues for chapters 0:1 and 0:2, which show a start and end time of 1.5 seconds respectively, when it should be 0.5 seconds for each.
I tried several combinations for this, and it seems that if the digit in the hundreds of milliseconds place is between 5 and 9 inclusive, it adds and extra second to the timestamp it saves in the metadata.

  


  Is this due to me using the command wrong ? Or formatting the metadata file wrong ? Or is there an issue in the code with rounding timestamps ?

  


  Thanks !

  


• FFmpeg HLS streaming - Why the program date time of older segment changing when re-streaming after discontinuity

  9 novembre 2020, par Suriya Krish

  Following is the ffmpeg command to stream the data.

  


  ffmpeg -re -f avfoundation 
-framerate 30 -i 0 
-codec:v h264_videotoolbox -x264-params keyint=120:scenecut=0 
-codec:a copy -f hls 
-hls_list_size 60 
-hls_time 10 
-hls_flags delete_segments 
-hls_flags +append_list 
-hls_flags +discont_start 
-hls_flags +program_date_time 
-strftime 1 
-strftime_mkdir 1 
-hls_segment_filename 
'%Y%m%dT%H%M%S%z.ts' playlist.m3u8


  


  Following is the playlist.m3u8 content which generated for few seconds.

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:07:53.000+0530
20201109T220753+0530.ts
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:08:03.000+0530
20201109T220803+0530.ts
#EXT-X-ENDLIST


  


  When the re-stream happens(in case of restarting the streaming service), the program date time of older segments(before #EXT-X-DISCONTINUITY) also get changed like below, which is unexpected.

  


  #EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-DISCONTINUITY
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:12:50.633+0530
20201109T220753+0530.ts
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:00.633+0530
20201109T220803+0530.ts
#EXT-X-DISCONTINUITY
#EXTINF:10.000000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:12.000+0530
20201109T221312+0530.ts
#EXTINF:5.400000,
#EXT-X-PROGRAM-DATE-TIME:2020-11-09T22:13:22.000+0530
20201109T221322+0530.ts
#EXT-X-ENDLIST


  


  Why the program date time of older segment should change ? Should we add any arguments in ffmpeg command to handle this ?