michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
HarshK23 has quit [Quit: Connection closed for inactivity]
<xue>
the mp3 adding metadata breaks if '-codec copy' option is present
<xue>
it drops first character, 'f' from some lines, not even every other, just some
<xue>
and i end up with 'Error opening input file ile:///home/xue/Music/Filename.mp3.' error
<dank074>
Hello. I am struggling with sending a patch without using `git send-email` since it is complicated to set up. I followed the instructions in the docs for submitting patches and generated an eml file with the command `git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 HEAD`
<dank074>
However, Patchwork still doesn't show my patch, which probably means my patch is still getting rejected
<dank074>
Did I do something wrong? again, this is the command I used: git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 HEAD
<kierank>
not sure
<dank074>
It's a very simple, 1 line change. If someone can submit it then that will be great. I have no idea what I am doing wrong
Labnan- is now known as labnan
<BtbN>
just send it as attachment. gmail mangled up the patch
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
<dank074>
Do I just disregard the previous email and just send a new one with the same subject?
<dank074>
Sorry about all these questions, this is my first time submitting changes via email
<kierank>
yeah
<dank074>
Ok, and just to verify, docs state: "send patches as base64-encoded attachments, so your patch is not trashed during transmission". Is this still the case, or can I send the patch in plaintext?
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
jamrial_ has quit []
^Neo_ has quit [Ping timeout: 248 seconds]
<Compn>
dank074, plaintext is fine
<Compn>
been a while since i saw a patch fail , but sometimes it happens...
dank074 has quit [Remote host closed the connection]
<Traneptora>
he keeps opening asinine issues and when someone with commit access closes it he just reopens it "no seriously this isn't stupid trust"
<Traneptora>
I don't know who has access to trac but he keeps this garbage up and links unrelated issues he also opened
<dank074>
Finally got my patch working. Had to use git send-email since none of the email clients I tried liked the eml file. Thanks for the help, I appreciate it!
<Traneptora>
dank074: no problem. also attaching a .patch file to an email sent with an ordinary client should preserve it bitexactly
<Traneptora>
git send-email is nice too though, it's what I use
<Traneptora>
are you subscribed to ffmpeg-devel@ffmpeg.org? if you aren't, then the email will be held in a moderation queue
<Traneptora>
I don't see it anyway so I think it probably was
<dank074>
Yes I am subscribed, thanks to someone who let me know about that earlier when I couldn't get my patch to show up at all on Patchworks
<michaelni>
Traneptora, why should FFmpeg not optimize the palette for PNG ? It seems a valid feature request that something in FFmpeg does that
<TheLeader>
michaelni: the paletteuse filter, as specified in ticket, can not reduce number of colors in palette
<TheLeader>
also the only way to reduce numbers of palette is to use palettegen per frame
<TheLeader>
which is already implemented
ngaullier has quit [Ping timeout: 268 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Guest97 has joined #ffmpeg-devel
<Traneptora>
michaelni: it is outside the scope of the the PNG encoder to reduce the size of the palette
Guest97 has quit [Client Quit]
<Traneptora>
to do so would require every paletted PNG to run histograms on the frame, determine which colors are used, and then refactor the palette and all the palette indices
<Traneptora>
it would be ridiculous for the png encoder to do this
<Traneptora>
especially ridiculous cause you save a few bytes at most. it's not like the PLTE chunk is going to be more than 256 in width
<TheLeader>
iirc png allows > 256 colors, am i correct?
<TheLeader>
and palettegen only up to 256
<Traneptora>
PNG allows any number of colors in the palette actually, but they're all 8-bit RGB colors
<Traneptora>
well, any number up to the maximum depth of the image
<TheLeader>
yes
<michaelni>
Traneptora, iam not sure why you say its ridiculous for an encoder to safe a few bytes
<michaelni>
its kind of the point of an encoder to safe bytes
<Lynne>
yeah, I think its fine for a PNG encoder to generate a palette if its beneficial, but it should not touch a palette if supplied with one, IMHO
<TheLeader>
michaelni: its about png encoder palette, which is unused entries specifically, me agrees with Lynne.
<michaelni>
sure, my point is just that something should allow eliminating these unused entries and it should be documented
ngaullie has joined #ffmpeg-devel
<Traneptora>
michaelni: how would you propose a PNG encoder supplied with pal8 reduces the size of the palette
<Traneptora>
without doing a full-frame histogram
ngaullier has quit [Ping timeout: 268 seconds]
<Traneptora>
what happens if the palette supplied has a color in index 6 that isn't used? should I eliminate that from the palette, and subtract 1 from every single pixel in the frame whose palette index is >= 6?
<Traneptora>
in what world is that a useful thing to do to save 1 byte
<Traneptora>
cause what you're proposing is probably an enormous number of CPU cycles to save a small handful number of bytes in the PLTE chunk.
<michaelni>
I dont see the issue, you run 1 pass over the image to find unused entries and then during encoding map[pixel] instead of pixel, and its optional when the user wants these bytes safed
<Traneptora>
if you want to implement that kind of functionality you should do it in avfilter
<Traneptora>
not in the PNG encoder. the PNG encoder receives a paletted image it should just encode it
<michaelni>
iam not arguing it should be done in a specific place, just that its a valid feature
<Traneptora>
except you can already reduce the number of colors with the palettegen filter
<Traneptora>
I don't see what the problem is
<michaelni>
can a user who wants to encode to png and wants minimal size find this information?
<michaelni>
nope, it talks about optipng and pngcrush not palettegen
<Traneptora>
both of those tools are significantly more effective tools than trying to shave literal bytes off of a palette
<Traneptora>
we don't even have an option to set zlib compression level
<michaelni>
are you trying to say ffmpeg shouldt try to support video/image encoding ?
<Traneptora>
what
<michaelni>
if we suport it we should be the best
<michaelni>
dont you agree ?
<Traneptora>
no, I think that kind of manipulation is outside the scope of the PNG encoder
<Traneptora>
default prediciton btw, is None
<Traneptora>
at least that one is configurable
<Traneptora>
there isn't even an AVOption to set zlib level why do you think this is in any way a sane idea to waste time on
<Traneptora>
honestly even if someone did I'd NAK it because the computational intensity required to histogram every paletted PNG image is ridiculous
<michaelni>
prediction default should be changed, zlib level should be made configureable
<TheLeader>
Traneptora: avctx->compression_level;
<TheLeader>
but as ffmpeg still have no native zlib decoder/encoder...
<Traneptora>
TheLeader: not documented if so
<Traneptora>
ffmpeg -h encoder=png doesn't mention this avoption
<TheLeader>
because its generic
<Traneptora>
not that we need some kind of NIH'd zlib anyway
<TheLeader>
predates private codec options
<Traneptora>
ah okay
<TheLeader>
in days where everything was global mess
<michaelni>
Traneptora, "I'd NAK", and you conside that acceptable ?
<Traneptora>
if someone can demonstrate through benchmarks that calculating a histogram of every frame to check for unused palette entries and then shifting palette indices if they are present doesn't cause a meaningful performance impact then I might think it's okay
<Traneptora>
but without that kind of benchmarking I wouldn't believe it would be performant, no
<michaelni>
of course it should be benchmarked
<Traneptora>
and what would you say when it inevitable comes up that it's way too slow?
<Traneptora>
I don't even know why I'm having this discussion
<Traneptora>
this is a pointless discussion
<TheLeader>
write native zlib decoder
<michaelni>
Traneptora, you started the dicussion :)
<Traneptora>
?
<Traneptora>
no I didn't, I closed a stupid issue
<Traneptora>
and you pinged me and asked why it shouldn't be implemented
<Traneptora>
I think it should be obvious
<michaelni>
I asked because you suggested to ban a person from trac
<TheLeader>
doesnt those optimizers to lossy quantizations?
<TheLeader>
*do
<TheLeader>
I agree with Traneptora that MasterQuestionable should be banned, only adds more noise to noisy trac, with 0 signal
<Traneptora>
they are constantly spamming issues with links to unrelated issues and have been doing so for months
<michaelni>
Traneptora, also if you have a 16x16 sized png, doing a histogram and removing unused palette entries seems the right thing to do, for a large image it may be better to skip an extra pass for a few bytes by default
<Traneptora>
if you have a 16x16 png why is it paletted
<Traneptora>
and not rgb24
<michaelni>
well then take a slightly larger png, theres a point where this makes sense
<Traneptora>
also why does it matter? the whole image is just a couple of bytes
<Traneptora>
there is never a point where it makes sense
<michaelni>
its the goal of an encoder to maximize quality per byte
<Traneptora>
no
<Traneptora>
it is not
<Traneptora>
the purpose of an encoder is to produce a compliant bitstream
<Traneptora>
absolute smallest size is not an implicit design goal
<michaelni>
the goal of an encoder to maximize quality per byte, doing so quickly and produce a compliant bitstream that plays on existing players
<Traneptora>
it is a tradeoff between performance and bpp
<Traneptora>
what you are suggesting is massively expensive and pretty irrelevant
<michaelni>
I think you need to calm down
<Traneptora>
?
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
<michaelni>
expensive in what way ? (beyond speed and size)
<Traneptora>
TheLeader: most do not unless explicitly enabled
<Traneptora>
computationally expensive
<michaelni>
"doing so quickly" is computationally expensive ? how can that be ?
<Traneptora>
...
<Traneptora>
who here controls trac anyway
<Traneptora>
MasterQuestionable has been spamming trac with garbage for months and months
<michaelni>
about encoders, its a tradeoff between compression and speed, the user should be able to select how much speed vs cmopression matters
<Traneptora>
I'm not going to have this discussion with you
<michaelni>
thanks
<ePirat>
I agree with Traneptora that MasterQuestionable is adding a lot of annoying noise in issues
<michaelni>
yes he does, but he also is doing usefull "maintaince" of trac issues
<michaelni>
ePirat, maybe you could talk with him ?
<michaelni>
or maybe Marth64 can
<michaelni>
if everyone wants him banned, then he shall be banned, yes, but i think some people who are good at this should first try to speak with him
<TheLeader>
MasterQuestionable entries quality are of questionable quality at best, its just a typical troll
derpydoo has quit [Quit: derpydoo]
jamrial has joined #ffmpeg-devel
DauntlessOne4 has quit [Ping timeout: 252 seconds]
DauntlessOne4 has joined #ffmpeg-devel
ngaullie has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
cone-716 has quit [Quit: transmission timeout]
<kierank>
Is "Jack Lau" AI?
<Marth64>
Good morning. I do read Jack Lau as potential spam/AI
<Marth64>
Re:TRAC. I agree with michaelni that MasterQuestionable adds value in the sense of combing TRAC and setting ticket metadata, it is after all a chore. I haven't found them to be rude or unprofessional but see he/she is sometimes too verbose or persistent.
<Marth64>
I can work with them to set some sort of boundaries?
<Marth64>
if MasterQuestionable handles 30% of classifying bug reports as an example thats 30% work done that will never else probably get done
<Marth64>
is kinda how I see it, even if its annoying at times
<TheLeader>
its more 30% good and 330 % bad
<Marth64>
I'll preview through their post history today and take my opinion from there. maybe with carefully crafted feedback such as try not to argue with maintainers and not everything needs a comment, they could be useful
<Marth64>
It's kind of like the Balling case but IIRC Balling was actually aggressive at one point
fflogger has quit [Remote host closed the connection]
fflogger has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<Marth64>
assigning him/herself to CC on every ticket is also a bit much
<jamrial>
i just looked at the last commits that touched vp9.c :p
<jamrial>
and several were all about "threads", so i started with the first
<jamrial>
bam, it was that one
<jamrial>
"switch to progressframe" committed 15 days or so after the last reported good commit. it was a good candidate
<TheLeader>
congratulations on fast tracking
<Marth64>
better than my awful bruteforce approach of resetting HEAD~25 at a time
<BBB>
I mean I did suggest in the firefox report that it was likely one of these
<BBB>
(I CC'ed Andreas upstream)
<BBB>
but I was trying to bisect brute-force
<BBB>
ok well thanks
<BBB>
so can I wait for Andreas to fix this?
<BBB>
- if (s->s.frames[REF_FRAME_SEGMAP].tf.f->buf[0] &&
<BBB>
+ // Non-existent frames have the implicit dimension 0x0 != CUR_FRAME
<BBB>
+ if (!s->s.frames[REF_FRAME_MVPAIR].tf.f ||
<BBB>
that looks fishy
<BBB>
(changing index from segmap to mvpair)
cone-728 has quit [Quit: transmission timeout]
<kasper93>
ffv1enc_vulkan.c:1471:16: error: too few arguments to function ‘ff_ffv1_common_init’
<kasper93>
is this expected?
<jamrial>
no
<jamrial>
i didn't have vulkan enabled, and nobody caught it during review
<kasper93>
I see
cone-716 has joined #ffmpeg-devel
<cone-716>
ffmpeg James Almer master:19045957affc: avcodec/ffv1enc_vulkan: add missing arguent to ff_ffv1_common_init()
<Lynne>
thanks
<steven-netint>
Btw, regarding patch submission process, do I need to git-push to FFmpeg project after my patch gain approval on mailing list? I assume I dont have push permission?
<jamrial>
no, someone will apply it
<BBB>
steven-netint: you can poke any one of us and if we feel comfortable, we can push for you