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
Everything has quit [Quit: leaving]
iive has quit [Quit: They came for me...]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
cone-254 has quit [Quit: transmission timeout]
lemourin has quit [Quit: Ping timeout (120 seconds)]
lemourin has joined #ffmpeg-devel
<Lynne>
consider watching the Lynch film instead
<Lynne>
particularly drunk, at least you'll have fun
Lynne has quit [Remote host closed the connection]
michaelni has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 245 seconds]
thilo has quit [Ping timeout: 264 seconds]
michaelni has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
arch1t3cht4 has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 276 seconds]
arch1t3cht has quit [Ping timeout: 246 seconds]
arch1t3cht4 is now known as arch1t3cht
ramiro has joined #ffmpeg-devel
<compn>
the lynch film is much better. with the spicediver fanedit of course
arch1t3cht has quit [Ping timeout: 272 seconds]
^Neo has quit [Ping timeout: 246 seconds]
jamrial has quit []
Cheetahze has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 246 seconds]
\\Mr_C\\ has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
rodeo has quit [Ping timeout: 264 seconds]
rodeo has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<elenril>
filthy secondaries
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 244 seconds]
Lynne has joined #ffmpeg-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #ffmpeg-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Lynne has quit [Remote host closed the connection]
Lynne has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<fflogger>
[newticket] lilydjwg: Ticket #11298 ([undetermined] AMD VAAPI HEVC encoding a 1080p video results in a 1920x1088 one) created https://trac.ffmpeg.org/ticket/11298
IndecisiveTurtle has quit [Ping timeout: 276 seconds]
Cheetahze has quit [Quit: Connection closed for inactivity]
System_Error has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
michaelni: Appologies for the ping, would you mind giving the vc2 patch another chance, since it should build now (patchwork says make succeeded). I can also split the patch more if needed as its a bit large.
<michaelni>
IndecisiveTurtle, sure ill look
<IndecisiveTurtle>
Thanks. Also note it needs new vulkan headers so you might need to update, judging by the error messages you posted
Everything has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
keith has quit [Ping timeout: 252 seconds]
keith has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Daemon404 has quit [Ping timeout: 260 seconds]
beastd has quit [Ping timeout: 260 seconds]
Daemon404 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
arch1t3cht has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Lynne has quit [Ping timeout: 252 seconds]
Sebastinas has quit [Ping timeout: 272 seconds]
Lynne has joined #ffmpeg-devel
Sebastinas has joined #ffmpeg-devel
<thardin>
how do I build probetest? make -C tools probetest fails because it can't include demux.h
<thardin>
managed to build it. not quite sure what it does. let's see here..
cone-790 has joined #ffmpeg-devel
<cone-790>
ffmpeg Ronald S. Bultje master:a5dabfc9c03f: enc_recon_frame_test: don't print an error on EOF.
<thardin>
so I see mp3_read_probe() returns at most AVPROBE_SCORE_EXTENSION+1 at the moment. it will hit that path if it can seek past the ID3. perhaps one solution is to return AVPROBE_SCORE_EXTENSION+1 if ID3 and AVPROBE_SCORE_EXTENSION+2 if actual MP3 essence
<Traneptora>
thardin: just make tools/probetest, no -C
<Traneptora>
it basically generates random crap and sees if you get false positives for any of the probers
<ePirat>
BtbN, can you look into the mail server issues?
<BtbN>
Which mail server issues?
<ePirat>
BtbN, of the ffmpeg mail server
<BtbN>
I'm not aware of any? What's wrong?
<ePirat>
BtbN, it keeps not sending out emails in a timely manner, sometimes even swallowing them completely
<BtbN>
If it's gmail, Google simply hates it
<ePirat>
not just to my gmail address but also even to patchwork…
<jamrial>
what address does patchwork use to get emails?
<BtbN>
postfix is running and looks happy. No spam of "rejected by gmail" in sight
<thardin>
Traneptora: I see. I'm making the mp3 probe very bad to see if FATE catches it
<BtbN>
I'm also getting mails fine on my end
<ePirat>
also patchwork is unable to send emails which is a bit ridiculous given ffmpeg has a mail server set up…
<thardin>
I'm expecting some kind of test to fail if i just return a score of 1
<thardin>
there we go, mp3-float-conf-compl
<ePirat>
BtbN, it was ok the last few days
<BtbN>
I'm really not seeing any issue. Postfix is sending mails fine for all I can tell
<ePirat>
BtbN, it is happens its somewha easy to spot by the patches in patchwork where the series is "Untitle series …"
<BtbN>
I'd suspect that's more an issue on the side of patchwork than the mail server
<thardin>
2b07f572af mp3_probe: consider id3 tags to be low scoring mp3.
<thardin>
michaelni: any idea why?
<Traneptora>
usually fate itself doesn't run probetest
<ePirat>
BtbN, is there a reason why patchwork isnt using ffmpegs mailserver?
<Traneptora>
er, make fate doesn't, you have to run it manually
<BtbN>
It's physically on a different server I think
<BtbN>
I'm not involved in managing patchwork
<ePirat>
ok but that does not make that impossible?
<ePirat>
it would be great to get this fixed eventually, not just the incoherent email delivery to patchwork but also that it cant send emails
<thardin>
the commit has no corresponding FATE update
<BtbN>
The ffmpeg mailserver isn't set up for users logging into it from what I can tell
<jamrial>
thardin: my guess is that, back then, nothing but mp3 used id3 tags
<thardin>
what else uses ID3?
<BtbN>
There's a lot of "said: 450 Your message had a temporary delivery error and will be automatically retried; Message was greylisted and will be retried later (in reply to end of DATA command))"
<BtbN>
so the delay on the ML is probably your provider greylisting the ML
<jamrial>
i think some fringe formats do
<Traneptora>
WAV and AIFF allow id3
<ePirat>
BtbN, ok, thanks for having a look. I will ping you again when it happens much on patchwork, maybe you can see something nteresting in the logs then
<Traneptora>
as does a particular MP4 atom iirc
<thardin>
Traneptora: at the very start of the file? that would conflict with RIFF
<ePirat>
BtbN, I dont mind much if I miss some but when I cant then even get it form patchwork, thats quite annoying
<JEEB>
didn't HLS with raw audio segments also do ID3? like ADTS etc
<BtbN>
From the logs of postfix, there is zero interaction between the main ffmpeg mailserver, and the patchwork server
<thardin>
ID3 shouldn't have been made. RIFF WAVE should have been used instead
<BtbN>
its IP does not appear in the log whatsoever
<thardin>
or AIFF
<BtbN>
So I'm not sure how patchwork gets its mails at all
<ePirat>
:D
<BtbN>
I see however two addresses the ML tries to send to: ffmpeg.patchworks@gmail.com and ffmpegpatchwork2@gmail.com
<BtbN>
so is patchwork set up to get its mail via a gmail address, which is subscribed to the ML? oO
<ePirat>
apparently…
<thardin>
JEEB: this is why being strict with tests is important. if there's nothing grounding the probe score stuff then it can't be changed with any amount of confidence
<ePirat>
BtbN, that would explain it not working at least whenever I lack mails too as both is gmail…
<BtbN>
gmail is currently aggressively greylisting the ML for some reason
<BtbN>
the other day it decided to flat out reject all mail, no requeue, citing "policies"
<thardin>
removing the special handling of ID3 in mp3_read_probe() doesn't hurt fate-mp3
<Traneptora>
thardin: don't know how it's handled specifically but I know some software supports exporting id3 wavs
<JEEB>
thardin: btw if you ever get interested, check which thing gets probed if avformat is given 0 bytes
<JEEB>
or I guess it might be avcodec in this case
<JEEB>
since I saw this a lot with MPEG-TS PIDs that received zero bytes of data
<thardin>
Traneptora: yeah but that's not a problem for mp3dec. it won't catch such files I think
<thardin>
or more correctly wavdec out to probe them with higher score
<Traneptora>
this is a probe though
<thardin>
ought
<Traneptora>
yea, ideally the RIFF header will win
<thardin>
most of the time when a file has a good header right at the start of it, it receives a high score
<Traneptora>
but you asked what else uses ID3 and the answer is wav, aiff, and mp4 as far as I am aware
<thardin>
so for MP3, if there's an ID3 header there, that seems like a sure bet for me. especially if we don't have any counterexamples in FATE
<Traneptora>
mp4 has a very rigid format so I don't expect that one to be rejected in favor of mp3
<thardin>
Traneptora: yeah wikipedia says so as well. but they'd have to be store in suitable atoms/boxes in that case
<Traneptora>
there's an atom for it
<Traneptora>
wikipedia links a now-deprecated microsoft doc page for wav info, but you can find info on it on mp3tag forums and the like
<thardin>
the only case of a format allowing skipping stuff at the start is MXF
<thardin>
that I know of
<Traneptora>
mp3 format should allow garbage at the start
<Traneptora>
there's an interesting experiment where you can concat a basic jpeg file and a basic mp3 file and play it as an mp3
<thardin>
sure. but if it has an ID3 there then that seems like a no-brainer. it's MP3
<Traneptora>
no, basic jpeg at the *start*
<thardin>
that's not ID3
<Traneptora>
but the decoder is able to skip the jpeg and read the mp3
<thardin>
that it can
<Traneptora>
just pointing out that it's not just mxf that allows garbo at start
<Traneptora>
but if the file starts with an ID3 blob I don't see any reason to treat it as anything other than mp3
<Traneptora>
as AFAIK it's just mp3 that uses ID3 blobs at offset 0
<thardin>
mp3 as a "format" is an abomination anyway. it's just an essence stream, not a proper container. but I'd argue ID3v2 *is*
<Traneptora>
all my old mp3s reside inside matroska for this reason
<thardin>
yeah that's what I'm getting at
<thardin>
sure it should get a score of 100 or maybe 99 if there's ID3 @ 0
<thardin>
surely*
<Traneptora>
I think 75 would be enough
<Traneptora>
strictly greater than 50 is probably fine, as that's what you need to beat mpegts false positives
<thardin>
here's also an opportunity to remove that awful ID3 logic in format.c
<thardin>
75 sounds reasonable to me. if there's a MIME type too then one can add a little more as Spotify suggests. and maybe MXF should trump it
<thardin>
which it would, because mxf_probe() returns AVPROBE_SCORE_MAX
<Lynne>
its fun how after all these optimizations, range coding is faster than golomb in ffv1
<JEEB>
:D
<Lynne>
to put things in perspective, on a 6900XT, on an 8-bit bgr0 1080p input, I get 48fps
<cone-790>
ffmpeg Leo Izen master:18883fbcab75: avcodec/jpegxl_parser: fix reading lz77-pair as initial entropy symbol
<Lynne>
and the input video is just some 60fps live-action youtube clip
<Lynne>
not screen content or anything
<thardin>
does OBS support ffv1 or huffyuv these days?
<thardin>
I did some screen capture stuff the other day and it struggled to get over 15 fps even at 1/3 resolution
<BtbN>
You can tell it to putput via an arbitrary ffmpeg output, so it supports anything ffmpeg does
<BtbN>
at least the version they bundle
<cone-790>
ffmpeg Kacper Michajłow release/7.1:03ffd4b3b365: avcodec/jpegxl_parser: check entropy_decoder_read_symbol return value
<cone-790>
ffmpeg Leo Izen release/7.1:11e8319b8ef0: avcodec/jpegxl_parser: fix reading lz77-pair as initial entropy symbol
<thardin>
"6612d8cf Move handling of ID3v2 to common utils.c code, reducing code duplication and supporting it for more formats, fixing issue 2258." here's where this ID3-on-format.c stuff comes from
<thardin>
flac and aac can do ID3?
<cone-790>
ffmpeg Kacper Michajłow release/6.1:d0852a36cf92: avcodec/jpegxl_parser: check entropy_decoder_read_symbol return value
<cone-790>
ffmpeg Leo Izen release/6.1:b45da36a2948: avcodec/jpegxl_parser: fix reading lz77-pair as initial entropy symbol
<JEEB>
ADTS AAC with id3 sounds like what HLS would do, and possibly icecast radio stations before
<ePirat>
icecast doesnt do it
<Traneptora>
do I need to backport fixes to release/6.0 and release/7.0 as well
<ePirat>
id3 is not streamable
<thardin>
let's see if I can even make such cursed files
<Traneptora>
or is release/6.1 and release/7.1 sufficient for the 6 and 7 branches
<cone-790>
ffmpeg James Almer master:66014c79abb5: avcodec/h2645_sei: move some common SEI syncing code to ff_h2645_sei_ctx_replace()
<cone-790>
ffmpeg James Almer master:2d3281b9dd04: avcodec/hevc/sei: remove unused inline function
<cone-790>
ffmpeg James Almer master:322b240cea79: avcodec/hevc/sei: remove unnecessary inline function
<thardin>
seems the only codec tag ID3v2 has is a mime type for the image attachment. nothing specifying what the audio essence is
<thardin>
in general you probably have to do what michaelni suggests on the list: seek past the ID3. or increase probe size
<thardin>
but! as things stand at the moment there seems to be no harm in assuming ID3 == MP3 because the other demuxers which deal with ID3 seem to be broken
<thardin>
if we want proper support, then we probably want to handle this further up in lavf so it's nice and orthogonal to what codec is used
<thardin>
then present the demuxer with the false reality that the ID3v2 doesn't exist
ccawley2011 has quit [Ping timeout: 272 seconds]
elChippo is now known as microchip_
<ePirat>
BtbN, "We don’t cover this here"… Why did they even bother to add this section to the docs
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<thardin>
email sent to the spotify guy to see what they think
<JEEB>
also I love it how the fftools | libbluray dec_init overlap is still a thing
<JEEB>
I'm manually renaming it to ff_dec_init in fftools when doing local builds with libbluray
jarthur has joined #ffmpeg-devel
<JEEB>
would that be an acceptable patch to send out, or was there already a patch that just requires review improving this
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
<compn>
JEEB, just send new patch :D
<JEEB>
will do :)
<JEEB>
I just recall there was some discussion on this theme on the ML but never figured out if there was a solution picked
Warcop has joined #ffmpeg-devel
<jdarnley>
What is the correct option name/kay for the qscale/quality/q:v option?
<jdarnley>
I keep getting an error returned
<JEEB>
check the `ffmpeg -h encoder=THING` output?
<JEEB>
in case it's a private option (some time in future we should make global options used by the module listable)
<jdarnley>
It's a global option, isn't it?
<jdarnley>
qscale in AVCodec
<JEEB>
not necessarily, since some encoders define stuff themselves, and "quality" is not a global option methinks
<jdarnley>
I agree to that
<jdarnley>
and I can't see it in the struct I thought it was in
<jdarnley>
ffmpeg(.exe)'s -qscale option gets passed into opt_qscale() so it can warn about ambiguity and redirect it into "-q..." but both "qscale" and "q" give me errors and that's were I lose my thread
* jdarnley
goes afk
<BtbN>
qscale is weird as hell
<BtbN>
some things also use -global_quality
<BtbN>
and qscale sometimes sets global_qualtiy with some magic factor
<Traneptora>
there's also FFQP2LAMBDA or whatever it's called
<BtbN>
That's the magic factor
<Traneptora>
I think it's just 18.0
<Traneptora>
for some reason
<Traneptora>
I don't know why
Krowl has quit [Read error: Connection reset by peer]
<Traneptora>
well if patchwork is sending an email via gmail SMTP you use that method
<Traneptora>
like, if you want ffmpegpatchwork@gmail.com to be sending emails, you have to log into that google acccount using your browser, create an app password, and then use that password with password-login in a TLS socket connecting to smtp.gmail.com
<BtbN>
I don't control either of the two gmail accounts.
<Traneptora>
what email address are you trying to send emails as then?
<Traneptora>
that's kind of the big question if you want to know how to make it send email
<BtbN>
I don't know what it ever sends mail for. But apparently it can
<BtbN>
Password Reset or something
<ePirat>
BtbN, account creation
<ePirat>
and email verification
<BtbN>
It's completely ignoring my config though. I'm trying to make it use the ffmpeg server, but it fails. Seemingly ignoring all my settings
<BtbN>
It's logging a "basic authentication is disabled" error, citing VI1PR0202CA0030.eurprd02.prod.outlook.com as the source. I have zero clue where it pulls outlook.com from.