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
<BtbN>
And we can also see which part it hated: the -tag:s:s:0 part
<BtbN>
There are no tags linking to tickets in the database. All tags in there reference wiki pages
<beastd>
yes, but the tractags plugin uses both the tags linked to wiki pages and the keywords in the ticket attributes
<BtbN>
possible, but unrelated to the issue anyway
<BtbN>
it was simply trying to parse wiki-formating in an ffmpeg output log, found it saying tag:, and then exploded
<beastd>
BtbN: alright, then it's true but unrelated *shrug*
<beastd>
"it was simply trying to parse wiki-formating in an ffmpeg output log, found it saying tag:, and then exploded" ← wow! that sounds bogus, but i sure believe you it was the case.
abdo_ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
<BtbN>
jamrial: yeah, the next_track label needs to move up a bit, since there can be more Multichannel-Info in the same packet
<HonestLeader>
which next decoder to do?
ccawley2011_ has joined #ffmpeg-devel
<jamrial>
alpha support in hevc
<HonestLeader>
patch for that already exist
<BtbN>
jamrial: I think in the end, initializing ret to 0 is correct
<BtbN>
there is simply nothing in that entire code path that'd set it
<BtbN>
and nothing setting it to error should equate success here
<HonestLeader>
ldac ? bink2 ? something else?
<BtbN>
Also just randomly found that muxing mpeg4 into flv only works cause ff_isom_write_avcc just writes the raw extradata to the avio context if it doesn't find a startcode.
cone-874 has joined #ffmpeg-devel
<cone-874>
ffmpeg Timo Rothenpieler master:4c2b769e5332: avformat/flvdec: clean up variable initialization spacing
<cone-874>
ffmpeg Timo Rothenpieler master:0ed34467382a: avformat/flvdec: fix potential premature return on audio MultichannelConfig
<cone-874>
ffmpeg Timo Rothenpieler master:e9de794d7fb0: avformat/flvdec: add missing track_size decrement
<jamrial>
err, one mistake in the last line, but you get the idea
<BtbN>
flv->mt_extradata is also never freed, is it?
<BtbN>
So that pointer is just a clean leak
<BtbN>
Only mt_extradata_sz is
<jamrial>
yeah
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
<jamrial>
also http://pastie.org/p/0YJuKKv7g27DjKzJtSN6yX this should ensure future changes that introduce a goto leave; with no ret being set don't silently return 0 when they might have meant to return something else
___nick___ has joined #ffmpeg-devel
<BtbN>
hm, using av_reallocp_array is not good. It'd leak all the extradata already in there on failure.
<BtbN>
same for av_realloc_f
<HonestLeader>
wt?
<HonestLeader>
realloc_f never leaks!
<HonestLeader>
read header docs
<BtbN>
It's an array to more allocations
<BtbN>
and realloc_f will free the array on failure, so no chance to iterate it to free those
<HonestLeader>
off course
<HonestLeader>
if array already have pointers. you need to do manual house keeping
<HonestLeader>
switch to C++/Rust
<HonestLeader>
can AI already rewrite all FFmpeg code (except asm) to Rust?
mkver has quit [Ping timeout: 252 seconds]
<cone-874>
ffmpeg Timo Rothenpieler master:9201f872b1c4: avformat/flvdec: properly free mt_extradata
<cone-874>
ffmpeg Timo Rothenpieler master:af74fe7139f4: avformat/flvdec: don't leak extradata pointer on realloc failure
<BtbN>
That should fix both leaks. I think valgrind actually saw the simple one, and not the realloc-special-case
courmisch has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<BtbN>
jamrial: feel free to push the patch for the AVERROR_BUG, it looks sensible to me and passes fate. Or I can just push it if you prefer
<HonestLeader>
ffmpeg become political entity
<thardin>
it has been for quite a while
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
bencoh has quit [Ping timeout: 246 seconds]
<cone-874>
ffmpeg James Almer master:692ce2503e80: avformat/flvdec: initialize ret in flv_read_packet() to AVERROR_BUG
<cone-874>
ffmpeg Bin Peng release/7.1:89bc70ddd81b: lavc/aarch64: Fix ff_pred8x8_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/7.1:54331d430590: lavc/aarch64: Fix ff_pred16x16_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/7.0:50c4fad6c8bd: lavc/aarch64: Fix ff_pred8x8_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/7.0:e2a60e532f3f: lavc/aarch64: Fix ff_pred16x16_plane_neon_10
<BBB>
Traneptora: I believe so, yes
<cone-874>
ffmpeg Bin Peng release/6.1:d0c887017a57: lavc/aarch64: Fix ff_pred8x8_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/6.1:ac60bc2bb0f6: lavc/aarch64: Fix ff_pred16x16_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/5.1:941b05ab56e0: lavc/aarch64: Fix ff_pred8x8_plane_neon_10
<cone-874>
ffmpeg Bin Peng release/5.1:6e63e4949619: lavc/aarch64: Fix ff_pred16x16_plane_neon_10
<wbs>
there, backported that one as far back as the bug existed (using the same list of branches as for other recent backports)
pross has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<beastd>
wbs: Nice!
<beastd>
It's kind of cool that back ports all in all seem to work so good in ffmpeg across a broad range of releases. At least that's my impression of it.
abdu91 has quit [Ping timeout: 240 seconds]
<fflogger>
[newticket] superded: Ticket #11403 ([undetermined] Recording with kmsgrab can't be stopped properly) created https://trac.ffmpeg.org/ticket/11403
<beastd>
Traneptora, BBB: That's also my understanding. If it's unclear. We should maybe improve the doc?
<beastd>
"A flag to mark frames which were encoded losslessly from the input." <-- i would assume "encoded" makes it clear what is meant, but maybe it is too subtle?
abdu has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<frankplow>
Anyone happen to know a workaround for "geninfo: ERROR: (inconsistent) mismatched end line for..." when trying to produce a coverage report for a templated .c file?
HonestLeader has quit [Quit: Client closed]
<Traneptora>
ye, since frames are generally decoded from packets, not encoded
<Traneptora>
perhaps "a flag to mark frames that a decoder has determined were originally encoded losslessly"
<Traneptora>
or something
<beastd>
Sounds good to me. Being more explicit, it's less easy to read and interprete it the wrong way.
<BBB>
frankplow: is that on windows?
<frankplow>
BBB: No, Linux
<beastd>
Traneptora: Think the term input in the current version is also what can lead to a wrong conclusion. So thumbs up for omiting it in your suggestion.
<BBB>
frankplow: hm, ok. strange. I've done coverage and haven't seen that before
<Traneptora>
thanks. I can send a patch to update the documentation
<Traneptora>
unless someone else wishes to
<frankplow>
BBB: I ended up working around it by inserting some —ignore-errors in a Makefile as required, but obviously that’s not ideal.
<beastd>
Traneptora: Yes, please send a patch. Could also do it, but it would probably take longer because I have a little of queue already and not so much time to process it.