Recherche avancée

Sur d’autres sites (3111)

• How to accurately/precisely seek to a timestamp in media with ffmpeg API ?

  11 novembre 2024, par wangt13

  I am writing a simple audio player with ffmpeg ver.4.4.4, and I want to seek to specific timestamp of the audio media (a MP3 file).

  


  Here is my code.
I am using avformat_seek_file() with flags of AVSEEK_FLAG_ANY | AVSEEK_FLAG_BACKWARD, and when I set seek_pos to 10 second when it is playing frames of 3rd second, it seemed NOT jump to the 10th second, it only played the audios after 3rd second !

  


  Then I added the code skipping/discarding the packets whose pts is before the seek position. This time, it loops in the if (curr_s < seek_ts), not going to 10th seconds.

  


  It seemed NO keyframe at 10th second.

  


  void decode_func(...)
{
    while (1) {
        if (av_read_frame(pfmtctx, packet) < 0) {
            avcodec_flush_buffers(pcodectx);
            printf("Got end of media, breaking\n");
            break;
        }
        /**
         * Discard the packet of pts before seek position
         */
        curr_s = packet->pts * av_q2d(pfmtctx->streams[stream]->time_base);
        if (seek_ts) {
            if (curr_s < seek_ts) {
                avcodec_flush_buffers(pcodectx);
                av_frame_unref(pFrame);
                continue;
            } else {
                seek_ts = 0;
            }
        }
        if (seek_req) {
            int64_t seek_abs;
            seek_req = 0;
            seek_abs = (seek_pos)*AV_TIME_BASE;
            printf("Seek to %lld, pts: %lld\n", seek_abs, packet->pts;
            if (seek_abs < 0) {
                seek_abs = 0;
            }
            if (avformat_seek_file(pfmtctx, -1, INT64_MIN, seek_abs, INT64_MAX, AVSEEK_FLAG_ANY | AVSEEK_FLAG_BACKWARD) >= 0) {
                avcodec_flush_buffers(pcodectx);
                seek_ts = seek_abs;
                continue;
            } else {
                printf("Failed to seek to %lld\n", seek_abs);
                seek_ts = 0;
            }
        }

        res = avcodec_send_packet(pcodectx, packet);
        while (res >= 0) {
            res = avcodec_receive_frame(pcodectx, pFrame);
            if (res == AVERROR(EAGAIN)) {
                break;
            } else if (res == AVERROR_EOF) {
                break;
            } else if (res >= 0) {
             /// Processing decoded frame
            }
        av_frame_unref(frame);
    }
}


  


  So, how can I precisely (almost) seek to a timestamp with FFMPEG ?

  


• configure : drop yasm support

  3 octobre 2024, par Lynne

  configure : drop yasm support
  We started defauling to nasm 8 years ago.
  
  We are still compatible with yasm 0.8.0, released in 2009. **15 years ago**.
  
  The time has more than come to remove support for it.
  Maintaining compatibility started cutting into writing new code long ago.
  
  We still can't have 2-argument instructions, preprocessor booleans, and all
  
  AVX2 code must still be wrapped in ifdefs. Newly added code often breaks this.
  

  • [DH] Changelog
  • [DH] configure
  • [DH] doc/developer.texi
  • [DH] doc/optimization.txt
  • [DH] doc/platform.texi

• Is it still possible to compile modern x264 with the nal long start code used prior to release r1510 ?

  25 avril 2024, par Bryan Knowles

  I'm currently nerding out on old technology with HD-DVDs. The only freely available muxer is hddvdmux, I'm using MultiAVCHD for this.
Beginning with r1510, x264 switched to short start packets for NAL HRD (from what I understand). This makes the stream incompatible with hddvdmux.
deank on doom9 patched hddvdmux to accept short start codes, but in doing so, the video file plays too quickly and the audio goes out of sync.
The results I'm getting from the 2009 release of x264 leave much to be desired in comparison to modern releases, and I'd like to get those benefits while still maintaining compatibility with the original hddvdmux.
Is it possible ? If so... Any chance someone could compile a Windows binary for me with that change ? (I think it needs to be 32 bit, but not sure)

  


  I've tried multiple options with MultiAVCHD 4.1, fell back to 4.0 but am seeing weird rainbowing effects in the color from the extremely old version if x264. I admit I haven't dived in to programming, but seemed like a single change might be a reasonable request from someone already knowledgeable.