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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo_ has quit [Ping timeout: 268 seconds]
thilo_ has joined #ffmpeg-devel
Sean_McG has joined #ffmpeg-devel
<Sean_McG>
does LOCAL_ALIGNED_16() allocate more memory than is requested?
<Lynne>
it doesn't allocate memory, and that's not how alignment works
<Sean_McG>
I'm not sure why the checkasm test (at least for flacdsp) isn't triggering AddressSanitizer for even the C code
<Lynne>
asan can't get injected into code that the compiler doesn't touch
<Lynne>
you should run under an emulator, like valgrind
<Lynne>
memory alignment aligns the start address to the alignment you specify, it doesn't touch the size though, so a 753-byte allocation is still a 753-byte allocation, even if alignment is 32768 bytes
<BtbN>
I'd imagine that if you declare an alignment for something on the stack, the compiler will do its best to shuffle stuff around to not waste space
* Sean_McG
facedesks
lexano has quit [Ping timeout: 268 seconds]
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 268 seconds]
arch1t3cht5 is now known as arch1t3cht
<Sean_McG>
in my freestanding code I was using the heap, not the stack -- via posix_memalign()
<Sean_McG>
so I am assuming I was fence-posting.
<mkver>
Lynne: The size of a type is always a multiple of the alignment of said type (otherwise one could not form arrays of said type, because two consecutive elements can't be properly aligned). So when you specify an alignment of 32768 bytes for a type, your structure will likely contain a lot of padding. (E.g. ASVDecContext contains 20 bytes of trailing padding that is completely unnecessary.)
<mkver>
Sean_McG: Some implementations of LOCAL_ALIGNED work by increasing the size of the array and aligning the pointer at runtime; other implementations use compiler magic.
<mkver>
Sean_McG: What makes you think that flacdsp should trigger out-of-bounds reads/writes for the C code?
<mkver>
What test specifically?
<Sean_McG>
I think I just showed how little I understand about how this works, and maybe not sure if I want to continue with what I was doing
<nevcairiel>
The problem is that resync identifies the wrong 0x47 right? so wouldnt a hardcoded check to specifically check the first byte after the header not avoid that?
<nevcairiel>
without needing to change the reading logic at all otherwise
wellsakus has joined #ffmpeg-devel
<llyyr>
in read_packet, we only break out of the resync loop if data[0] is 0x47, but this data is constant and avio_skip(pb, 4) doesn't change it
<llyyr>
so even if we handle it in mpegts_resync, this will need to change regardless
<nevcairiel>
why?
<nevcairiel>
resync is supposed to sync the bitstream to have 0x47 at 0
<nevcairiel>
all you would fix is make it sync to the right 0x47, rather then the wrong one
<llyyr>
hmm I'm misunderstanding something then
<llyyr>
I'll respond later after looking at it again
<nevcairiel>
untested since i also dont have a breaking sample, but my suggestion for the entire fix:
Krowl has quit [Read error: Connection reset by peer]
cone-749 has joined #ffmpeg-devel
<cone-749>
ffmpeg Ramiro Polla master:5939f7228a23: libswscale/x86/yuv_2_rgb: fix some comments
Krowl has joined #ffmpeg-devel
<ramiro>
wbs: thank you for the review. regarding the right shifts without rounding, that's what the C code does, so I just follow that to get the same results.
<courmisch>
well if checkasm checks out, then you're probably correct
<ramiro>
the clipping in the c code seems wrong though, since it only checks the upper bound of the range and not the lower bound. but... one thing at a time.
Livio has joined #ffmpeg-devel
<courmisch>
anyway, if the reference C code needs to add a value that is not fixed point 0.5, then there is typically no point in rounding
<courmisch>
(since you can fold the rounding 0.5 into the addend)
<cone-749>
ffmpeg Rémi Denis-Courmont master:c3dbbb316ee4: lavc/flacdsp: fix sign extension in R-V V wasted33
<cone-749>
ffmpeg Rémi Denis-Courmont master:04397a29decc: lavc/vc1dsp: R-V V vc1_inv_trans_8x8
<cone-749>
ffmpeg Rémi Denis-Courmont master:a169f3bca593: lavc/vc1dsp: R-V V vc1_inv_trans_8x4
<cone-749>
ffmpeg Rémi Denis-Courmont master:6ffa639c8aa6: lavc/vc1dsp: R-V V vc1_inv_trans_4x8
<cone-749>
ffmpeg Rémi Denis-Courmont master:3152c684cb59: lavc/vc1dsp: R-V V vc1_inv_trans_4x4
<courmisch>
oh so range conversion was a LoongArch exclusive
Livio has quit [Ping timeout: 264 seconds]
<ramiro>
courmisch: and until a few months ago it was c exclusive
<ramiro>
it ranks very low in perf report anyways. but I'm trying to reduce the latency in mjpeg webcam input in sbcs, so this helps a tiny little bit.
<Lynne>
they don't have mjpeg decoders?
Krowl has quit [Read error: Connection reset by peer]
<ramiro>
Lynne: probably, but I think they still return jpeg range yuv.
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
<courmisch>
what was the minimum GCC version now? 4.4 ?
Krowl has joined #ffmpeg-devel
<jamrial>
4.9 i think
<jamrial>
because c11
<courmisch>
there's FATE instance compiling ARMv5TE with GCC 4.4.5
<courmisch>
>> ARMv5
<jamrial>
courmisch: those are old branch releases
<courmisch>
oh
<courmisch>
still ARMv5, lulz
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 272 seconds]
Livio has quit [Ping timeout: 268 seconds]
AbleBacon has joined #ffmpeg-devel
mateo` has quit [Ping timeout: 256 seconds]
ccawley2011 has quit [Ping timeout: 264 seconds]
mateo` has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
Livio has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
cone-749 has quit [Quit: transmission timeout]
<courmisch>
so... December 2011, mru removes the inline bswap assembler for x86 and arm because GCC can optimise them
Krowl has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 256 seconds]
Livio has joined #ffmpeg-devel
<pal>
Fate with --toolchain=valgrind-memcheck fails at tests/data/fate/lavf-asf with "Conditional jump or move depends on uninitialised value" and "Uninitialised value was created by a stack allocation"
<pal>
... is this a known issue?
<pal>
... any workaround?
<mkver>
pal: The test works fine here when using valgrind (but not the valgrind-toolchain).
<mkver>
Did you test --expensive-definedness-checks=yes?
<mkver>
And can you provide the full log for this?
* Sean_McG
peeks in
cone-821 has joined #ffmpeg-devel
<cone-821>
ffmpeg Michael Niedermayer master:9b76e49061a3: avcodec/vp8: Check cond init
<cone-821>
ffmpeg Michael Niedermayer master:4ac7405aafb8: avcodec/vp8: Check mutex init
<cone-821>
ffmpeg Michael Niedermayer master:8a64a003b5d5: avcodec/ilbcdec: Remove dead code
<mkver>
You can get <cmd> by running the test with V=1
System_Error has quit [Remote host closed the connection]
<pal>
I am running ` ./configure --toolchain=valgrind-memcheck; make -j 12 fate-lavf-asf SAMPLES=../fate-suite/"
<Sean_McG>
if you add V=1 to the end of that, you can get the ffmpeg command that make is running and use that directly with valgrind, as mkver points out
System_Error has joined #ffmpeg-devel
<pal>
ok... but why? Is `./configure --toolchain=valgrind-memcheck` supposed to fail?
<Sean_McG>
more than likely you are getting a false positive from valgrind.
<Sean_McG>
it's notorious for that
<pal>
maybe... certainly seen that before... but that also makes `./configure --toolchain=valgrind-memcheck` not useful :)
<mkver>
pal: Logs from stripped binaries are useless. Rerurn with ffmpeg_g.
<Sean_McG>
I doubt it, otherwise we would see that on FATE
<pal>
mkver: how does one run fate with ffmpeg_g?
<pal>
... actually had that question on my todo for a while :)
<mkver>
You run it manually as explained above, but with ffmpeg_g instead of ffmpeg.
<mkver>
(There is also a --disable-stripping configure option, but I never used that.)
IndecisiveTurtle has joined #ffmpeg-devel
<Sean_McG>
speaking of which, is there any desire for an Apple M3 fate node? my dad bought an iMac recently and it occurred to me that I could run a few overnight
<Sean_McG>
hmmm, that might actually be a valid concern -- looking at asfdec_f.c:576, 'name' *can* be uninitalized.
<mkver>
pal: And with expensive-definedness checks?
<pal>
no error
<mkver>
pal: As expected. avio_get_str16le() also zero-terminates the buffer and given that the compiler can see that name is always big enough, it can simply inline the strcmp checks (it could e.g. check the first eight bytes in one go).
<pal>
... so include --expensive-definedness-checks=yes when --toolchain=valgrind-memcheck is set?
<mkver>
pal: That should be left to every user. After all, it is expensive.
System_Error has quit [Ping timeout: 260 seconds]
<pal>
well the doc mentions ` --toolchain=valgrind-memcheck` without every mentioning `--expensive-definedness-checks=yes`
<pal>
... the doc should at least mention that the option is required to pass fate
<mkver>
Whether it is required or not depends upon your compiler (and the other compiler settings).
<Sean_McG>
well, no.... expensive-definedness would make the valgrind checks slow.
<pal>
(and how would you set --expensive-definedness-checks=yes across all of fate?)
<pal>
ok. just trying to save you time in the future. I know now, the next person will not :)
Krowl has quit [Read error: Connection reset by peer]
<mkver>
Seems like toolchain=valgrind is already supposed to be slower than ordinary valgrind (it defaults to track-origins), so expensive definedness checks should be ok.
<mkver>
So you may send a patch to modify configure line 4574.
<pal>
k
<mkver>
Anyway, the valgrind-toolchain uses TARGET_EXEC internally, so you could also use valgrind for one fate run via TARGET_EXEC="valgrind --error-exitcode=1" (which is what I do sometimes).
<Sean_McG>
aye
<mkver>
And if a test fails, you can add more expensive stuff.
<Sean_McG>
anyways, it's after 5PM and I'm hungry. Going out for dinner tonight despite thunderstorm warning. Have a good weekend folks!
<pal>
(thanks for the help btw)
<pal>
... and yes --toolchain=valgrind-memcheck is already brutally slow, which makes it even more annoying when it fails before the end
System_Error has joined #ffmpeg-devel
<pal>
running fate now and will send patch if it works
<Sean_McG>
hey, are patchwork login/password removed if unused for a time? I created mine in February and it seems I can't log in now.
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<cone-821>
ffmpeg Lynne master:8a2fe8a5b964: mpeg4audio: rename AOT_USAC_NOSBR to AOT_USAC
<cone-821>
ffmpeg Lynne master:ee419804da2a: mpeg4audio: explicitly define each AOT
<cone-821>
ffmpeg Lynne master:1c066867df5b: aac: define a new profile for USAC
<cone-821>
ffmpeg Lynne master:91fd6ca000cb: lavc: bump minor and add APIchanges entry for new USAC profile
<cone-821>
ffmpeg Lynne master:5c328e6c1e56: aacdec: increase MAX_ELEM_ID to 64
<cone-821>
ffmpeg Lynne master:62cd6d9e596f: aacdec_usac: clean up nb_elems on error
<cone-821>
ffmpeg Lynne master:91ab17e2fe57: aacdec_usac: tag LFE channels as such in the channel map
<cone-821>
ffmpeg Lynne master:ae495b56ffc9: aacdec_usac: remove fallback for custom maps with invalid position
<cone-821>
ffmpeg Lynne master:25b848a0bd08: aacdec_usac: correctly set and use the layout map
<cone-821>
ffmpeg Lynne master:8ecaa64b9bce: aacdec_usac: respect tns_on_lr flag
<cone-821>
ffmpeg Lynne master:c0fdb0cdfdbd: aacdec_usac: do not continue parsing bitstream on core_mode == 1
<cone-821>
ffmpeg Lynne master:1ad9a4008bbb: aacdec_usac: decouple TNS active from TNS data present flag
<cone-821>
ffmpeg Lynne master:a18d0659f403: aacdec_usac: skip coeff decoding if the number to be decoded is 0
<cone-821>
ffmpeg Lynne master:9b41cc04300e: aacdec_usac: do not round noise amplitude values
<cone-821>
ffmpeg Lynne master:722352333524: aacdec_usac: use correct TNS values