From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 881A747221 for ; Thu, 31 Aug 2023 19:35:30 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CE2F568C7E9; Thu, 31 Aug 2023 22:35:26 +0300 (EEST) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3FE4D68C60A for ; Thu, 31 Aug 2023 22:35:21 +0300 (EEST) Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4013454fa93so12705965e9.0 for ; Thu, 31 Aug 2023 12:35:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693510520; x=1694115320; darn=ffmpeg.org; h=content-transfer-encoding:to:subject:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=d+BfTfyuTGUcWbAWBBRCwJC0gCa7BAVvTET+VosLTMk=; b=LkGG3ft2vs1oyFKOPER2TZCYb4TXykTVa/0FfUs7EJDonNSmJe37eHlnKh2tUvLL+H M8Tb2c708MEnw2AbX6a874mZ4+DI3qXB0PZkrU2rBmaiEVdDuIV54K1MCANSsuc9y2g4 nUY51ExuLDgmTNcSYdnOOw1twff/yYCZO2VnwPDuxDlb61OHMu9FaQwSQjoT6Wvvlhnp ZaFAP9A+FrojBbg/nbKmUlOt5Wio8atxkyF4VZTGaPmbOMafJbv7i463D8H7uA6hHiJC QJco1QqHjKBX7I6sdXM13bQH2mBF5fBIXkpcie7vivw+VMLbuktFXNIWt7hvEM/HfMry sR2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693510520; x=1694115320; h=content-transfer-encoding:to:subject:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=d+BfTfyuTGUcWbAWBBRCwJC0gCa7BAVvTET+VosLTMk=; b=RtFH7zBYvGOddZxuZeswUHNuT1pTiCRlJ0yReuOMzanevpYJsA0dGF+LZfQf+JU/eA jmIn9UJcd4mQMfDQuy20WPUJAzvBKUMvHVPIm2QX7XcVAv2SBycuzUOlHnmIqr6NhA9S lkysgnSvlTVBKwzJWOor1MZ2KyCWh7NBDGKEIDIhx9haUKRLa9vrxZPc42YwVIHB8adS hf/z0FRWMYsR4kQq3b3qbspCZqsGL6cXqQirLDh4vK/FRzJES7Dx3NP4YGe6B/lEWvca Obyi/fxkGsqxApEvu4III/ZKesXH4jhz6IuwfuVIZnm1Ybetemx/gBAK/SraW0PMX2ZG NfoQ== X-Gm-Message-State: AOJu0YwuWlKHKmJNwbJ9TYEKwx95S4jZtFPBv8LrImZyd3mZ5oUldQto kLgg9i7r2mVBYXCxKZ/901SFvOsW2Wg= X-Google-Smtp-Source: AGHT+IH/a/5bouQ7S2oCD5Pd4qvblIv8Mhv/tIni5hVtwFkB1LAFgTL4jQOSXZKe/fRmIFl/EV0R4w== X-Received: by 2002:adf:f58f:0:b0:319:55bc:4416 with SMTP id f15-20020adff58f000000b0031955bc4416mr356280wro.5.1693510519898; Thu, 31 Aug 2023 12:35:19 -0700 (PDT) Received: from ?IPV6:2a01:c23:5cc9:5800:da6a:fa16:c32:eb6e? (dynamic-2a01-0c23-5cc9-5800-da6a-fa16-0c32-eb6e.c23.pool.telefonica.de. [2a01:c23:5cc9:5800:da6a:fa16:c32:eb6e]) by smtp.gmail.com with ESMTPSA id c18-20020adfed92000000b003143c6e09ccsm3129801wro.16.2023.08.31.12.35.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 12:35:19 -0700 (PDT) Message-ID: <76fbb5b4-c39f-4884-8a5f-7cd514ba8d3f@gmail.com> Date: Thu, 31 Aug 2023 21:35:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: de-DE, en-US From: Johannes Maibaum To: FFmpeg development discussions and patches Subject: [FFmpeg-devel] Working on an LTC source filter - can this be made seekable? X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Hello, as my first dive into the ffmpeg source, I am working on an Linear/Longitudinal Time Code (LTC) source filter for ffmpeg using https://github.com/x42/libltc here: https://git.sr.ht/~jmaibaum/ffmpeg/log/ltc The basics are working fine and turned out to be fairly easy to achieve, even though I am still missing essential features, major refactorings, and proper testing, before I would consider it ready for inclusion into ffmpeg. I am planning to get there eventually once my free time allows. Yet, I am now facing an issue where I am unsure if the plan to add the ltcsrc as a libav source filter was correct in the first place? One of the use-cases I have in mind for the ltcsrc filter involves having it generate an LTC signal while playing another audio or video file in sync, i.e. the LTC signal should of course always match the current position of the audio/video file's playback position. It should be possible to seek arbitrarily inside the video player, thus. the LTC timecode being generated after a seek event signal must always stay in sync to the new playback position of the audio/video file. But apparently libav-filters are by design not supporting seek events at all though, at least not from ffplay, where running ffplay -f lavfi -i ltcsrc and then trying to seek results in "error while seeking". This error also happens with all other filters I tried using in the ffplay command line above. Similar quick checks trying to use the filter from within mpv resulted in an unseekable playback. I can successfully send commands (via asendcmd) to change the timecode being generated on the fly, but this feels like a bad workaround for the use-case described above. I took a brief look into other ffmpeg modules (codecs, formats, devices), but from my current understanding a (source) filter is the correct way to implement ltcsrc. Thus, my question is: Can this use-case even be solved by implementing ltcsrc as a filter? If not, how can I implement an ltcsrc that can be used "like" a filter (i.e. supporting things like receiving commands to change other parameters on the fly) in my use-case, but also supporting seek events? Cheers, Johannes _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".