Recherche avancée

Sur d’autres sites (6792)

• 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 ?

  


• ffmpeg : avcodec_open2 returns invalid argument

  26 octobre 2020, par roari

  I'm reusing the sample code from the developer 64-bit release of FFmpeg in my application to encode a video :

  


  AVCodec* pCodec_{nullptr};
AVCodecContext* pContext_{nullptr};

avcodec_register_all();
pCodec_ = avcodec_find_encoder(AV_CODEC_ID_MPEG2VIDEO);
if (!pCodec_) {}

pContext_ = avcodec_alloc_context3(pCodec_);
if (!pContext_) {}

pContext_->bit_rate = 400000;
pContext_->width = size.width();
pContext_->height = size.height();

pContext_->time_base.den = 1;
pContext_->time_base.num = fps;

pContext_->gop_size = 10;
pContext_->max_b_frames = 1;
pContext_->pix_fmt = AV_PIX_FMT_BGR0;

if (codec_id == AV_CODEC_ID_H264) {
    av_opt_set(pContext_->priv_data, "preset", "slow", 0);
}

int err = avcodec_open2(pContext_, pCodec_, nullptr);
if (err < 0) {}


  


  AVCodec* and AVCodecContext* look like they are allocated correctly. avcodec_open2 then returns invalid argument (-22).

  


  I use : Windows 10 64, VS2013 Compiler, Qt Creator IDE, ffmpeg(2016-05-12) 64bit.

  


  The sample I took the code from is decoding_encoding.c.

  


  Any ideas ?