On Tue, Jul 8, 2025 at 5:08 PM Devin Heitmueller
wrote:
> I took a quick look at your branch. So this is a good start, IMHO...
thanks!
> Note that I took a look at the MCC demuxer last year, and it's got a
> bunch of issues where the parsing makes a bunch of assumptions (e.g.
> doesn't filter o
I'm currently writing a .mcc muxer, it currently translates from eia-608/708 to
full vanc packets before outputting a .mcc file:
https://github.com/programmerjake/FFmpeg/tree/add-mcc-mux
I want to add the ability to the mxf and mcc muxers/demuxers to keep the full
vanc data when doing stream cop
On July 13, 2025 4:43:57 AM PDT, Michael Niedermayer
wrote:
> Hi all
>
> Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
i'll note that I ran into some important upsides and downsides with both of
those when picking which to use for projects i've worked on, hopefully this
Signed-off-by: Jacob Lifshay
---
doc/APIchanges | 3 +++
libavutil/attributes.h | 2 ++
libavutil/avstring.h | 2 +-
libavutil/version.h| 2 +-
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 80eb408788..5c40b7c13d 100644
--- a
Fixes: https://trac.ffmpeg.org/ticket/11591
Signed-off-by: Jacob Lifshay
---
libavcodec/mpeg12enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 8364368fde..e48437eb8a 100644
--- a/libavcodec/mpeg12enc.c
+++ b
On Thu, May 15, 2025 at 6:15 PM Andreas Rheinhardt
wrote:
> Thanks for this patch (and for the bug report; and sorry for causing you
> trouble). Your patch was also my first attempt to fix this, but
> unfortunately ff_copy_bits() may overread, yet the side data buffer need
> not be padded, so my p
On July 23, 2025 10:48:51 AM PDT, Michael Niedermayer
wrote:
> On Wed, Jul 23, 2025 at 06:43:51PM +0200, Dimitry Andric wrote:
> > As long as there is a command line option to disable checking, it should
> > be a good default.
>
> > There are many sites out there with badly configured
> > cer
On July 23, 2025 3:06:40 PM PDT, Timo Rothenpieler
wrote:
> I've registered a dummy-user with the ffmpeg-devel address as its E-Mail and
> subscribed it to all the repo notifications.
>
> So things will get forwared to the ML via it now.
It seems to not be working, since you sent this I've got
On July 23, 2025 1:01:32 PM PDT, "Tomas Härdin" wrote:
> Perhaps I should have made it clear that I'm just spitballing what kind
> of workflows we should keep in mind with this stuff. I'm not suggesting
> we need to add support for everything right away. Just that we should
> take steps toward a s
h the only reason I'm contributing now using git send-email is
because I'm being paid to, if I weren't being paid I'm much less
likely to have bothered even when I had the code in a git repo.
Jacob Lifshay
___
ffmpeg-devel mailing list
f
On Thu, Jul 24, 2025 at 8:40 PM compn wrote:
> people can always just manually attach patches to emails sent to
> ffmpeg-devel list. no need for git send mail.
ok, I prefer to never do that though because it makes reading the
patches very annoying. Anyone should be able to read the patches
withou
Replying to softworkz from the mailing list archive:
I tried out the .clang-format file you proposed and I ended up using:
AlignConsecutiveDeclarations:Consecutive
instead of:
> +AlignConsecutiveDeclarations:AcrossEmptyLinesAndComments
since otherwise clang-format will indent the f
Idk if forgejo notifies anyone when I make it no longer WIP, so I'm
sending this email.
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20024
Also, can libklvanc be added to the CI images? that PR uses libklvanc
for some parts and it'd be nice if CI tested that.
Jacob
On July 23, 2025 4:43:43 AM PDT, Michael Niedermayer
wrote:
> Hi everyone
>
> I intend to create the release/8.0 branch in the next 1-2 weeks
> after that i intend to make teh 8.0 release in the following 1-2 weeks
>
> If theres something you want in it make sure its pushed before the branch
>
On Mon, Aug 4, 2025 at 8:06 PM Kacper Michajlow wrote:
> Slightly related, I don't like how simple the web ui commit log of
> forgejo is, it doesn't show commiter at all. For me this information
> is as important as the author. I'm keeping notes on forgejo usage and
> will share it when the time c
On August 4, 2025 6:49:20 AM PDT, Alan Kelly via ffmpeg-devel
wrote:
> The gather is unmasked but the instruction does a merge into ymm4, which
> depends on the value of ymm4 from the previous loop iteration. The
> out-of-order scheduler does not know statically that the instruction is
> fully
On July 22, 2025 5:21:24 AM PDT, "Tomas Härdin" wrote:
> mån 2025-07-07 klockan 21:12 -0700 skrev Jacob Lifshay:
> > I'm currently writing a .mcc muxer, it currently translates from eia-
> > 608/708 to full vanc packets before outputting a .mcc file:
> > http
On Mon, May 26, 2025 at 6:34 PM Ramiro Polla wrote:
> -[ -x "$(command -v gzip)" ] && enable gzip
> +gzip -V > /dev/null 2>&1 && enable gzip
idk if you intend it to build with busybox gzip, but busybox gzip
doesn't support the -V option, a better command could be something like:
gzip < /dev/null
On May 27, 2025 9:12:47 AM PDT, Ramiro Polla wrote:
> Hi Jacob,
>
> Thanks. I hadn't thought about gzip implementations that don't support -V.
>
> What about the following?
> echo | gzip -c > /dev/null 2>&1 && enable gzip
That should also work afaik. busybox does support -c.
Jacob
_
On May 30, 2025 4:10:45 AM PDT, Ramiro Polla wrote:
> I'll postpone this part of the patchset (patches 1 to 3) for a while
> to give more time for people to comment. If anybody can find a system
> where zlib doesn't support gzip, please let us know.
idk if anyone is using it as the system zlib
On August 11, 2025 5:22:26 AM PDT, Lynne wrote:
> I would like to hear other options or suggestions that developers may have,
> and ultimately, if there's a consensus on the amount of options that that the
> project would benefit from having a plugins interface, a vote on the type of
> interfac
On Tue, Aug 12, 2025 at 2:58 AM Nicolas George wrote:
> @@ -316,6 +316,10 @@ libavfilter
> ===
>
> Generic parts:
> +
> + Famework and orphaned filters Nicolas George
framework is misspelled here
Jacob
___
ffmpeg-devel mailing list
f
PR #20182 opened by Jacob Lifshay (programmerjake)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20182
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20182.patch
Fix some memory leaks. Also adds a test to actually test smpte436m_to_eia608
which I forgot to add in #20024
reported in
On August 11, 2025 6:10:52 AM PDT, Michael Niedermayer
wrote:
> On Mon, Aug 11, 2025 at 09:22:26PM +0900, Lynne wrote:
> > Option 3 - we have an official source plugin interface, free for
> >everyone to use, with license limitations. All source plugins
> >The list of so
On August 20, 2025 10:47:03 PM PDT, Lynne via ffmpeg-devel
wrote:
> +Hardware accelerated decoding: Vulkan VP9, VAAPI VVC, OpenHarmony
> H264/5
> +Hardware accelerated encoding: Vulkan AV1, OpenHarmony H264/5
> +Filters: colordetect, pad_cuda, scale_d3d11, Whisper, and others
maybe
On August 19, 2025 1:45:01 AM PDT, ffmpeg--- via ffmpeg-devel
wrote:
> We have have already completed implementation of this protocol into FFMPEG 7
> and I enclose patches to add this to the current FFmpeg origin/master.
>
>
> If the .eml patches dont make it through the email, here are lin
PR #20289 opened by Jacob Lifshay (programmerjake)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20289
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20289.patch
Add myself to codeowners. I didn't add myself to maintainers because I'm not
planning on being all that active,
On August 19, 2025 2:27:12 PM PDT, Michael Niedermayer via ffmpeg-devel
wrote:
> Hi all
>
> what name should we give 8.0 ?
IDK if it's a very good suggestion, but Hachi? It's both the Japanese number 8,
as well as a common nickname. There's a famously loyal dog with that name:
https://en.w
On September 18, 2025 2:15:22 AM PDT, Nicolas George via ffmpeg-devel
wrote:
> If this web monster does not let you push code in your private fork
> without asking to include it upstream, it is one more reason not to use
> that thing.
It does let you push to your private fork without updating
On Thu, Sep 18, 2025 at 12:03 AM Nicolas George via ffmpeg-devel
wrote:
>
> Timo Rothenpieler via ffmpeg-devel (HE12025-09-18):
> > The problem is they can be very frequent. And not only force pushes.
> > So the current implementation is a compromise between visibility and
> > spam-level.
>
> They
30 matches
Mail list logo
