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
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
thilo_ has quit [Ping timeout: 268 seconds]
thilo_ has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
System_Error has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
cone-344 has quit [Quit: transmission timeout]
HarshK23 has joined #ffmpeg-devel
mkver has quit [Ping timeout: 246 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
cone-416 has joined #ffmpeg-devel
<cone-416>
ffmpeg Rémi Denis-Courmont master:6c6bec04f3fc: lavc/vc1dsp: fix R-V V avg_mspel_pixels
kurosu has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
<beastd>
haasn: Do you have by chance any recommendations for a monitor that is good for video and not too expensive? Want to use it for everything as a single screen on my desk.
<tr4nq_>
ls
<tr4nq_>
whoops wrong term
<JEEB>
&33
mkver has quit [Ping timeout: 264 seconds]
Livio has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
cone-416 has quit [Quit: transmission timeout]
ccawley2011 has joined #ffmpeg-devel
<haasn>
beastd: I'm reasonably happy with my Samsung Odyssey G8 OLED
<haasn>
don't know if I have specific recommendations
<haasn>
OLED is pretty hard to beat
<haasn>
I'll likely never get an LCD again
<jdarnley>
What size is that display?
<BtbN>
OLED is still too immature imo. Though I'm sure "the industry" loves displays that naturally expire within a couple years.
<BtbN>
I'm still using some over 10 yeard old screens, that's likely impossible with OLED
<haasn>
jdarnley: 34" 21:9
<nevcairiel>
i have the alienware in the same dimensions, also pretty happy. uses the same panel.
MetaNova has quit [Quit: quit]
jamrial has joined #ffmpeg-devel
MetaNova has joined #ffmpeg-devel
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
<jdarnley>
large and wide
<beastd>
haasn, nevcairiel: Thanks for sharing!
<beastd>
These panels are only available as curved, right? My brief experience with curved was that it looked to me like unnecesarrily warped. Was it the same experience for you in the beginning?
<llyyr>
BtbN: aren't LCDs like that as well? I've never had a LCD screen (TV or monitor) last more than 4-5 years
<BtbN>
I'm still using a 12 year old LCD TV, and am sitting on front of two LCD screens that are also pushing 10 years
<BtbN>
No sign of any aging
<BtbN>
While OLED's just burn out
<BtbN>
If an LCD screen breaks, it's usually dried out caps in the power supply, which is easily fixable. But even that hasn't happend in 10 years now
<beastd>
I have an old Toshiba TV in daily use that is now 17 years old. No repairs and I see no signs of wear regarding the display quality. Partially looks even better than some newer TVs, but of course it's not so big and doesn't have the new features.
<llyyr>
had a TV and a monitor (both about 18 months old) have vertical/horizontal lines, which I'm told usually means loose connections somewhere
<llyyr>
perhaps it's related to what environment they're used in
<beastd>
Though I'm ready to give OLED a try. The direct impression especially with dark'ish scenes is pretty impressive on those.
<BtbN>
The main issue of oled is burn-in.
<BtbN>
Likely fine for movies, but as a PC screen, which always shows a task bar or window bar... you will ruin the screen
<beastd>
Question is probably not if but when. If when is sufficiently far away I guess it would be OK.
<BtbN>
Within hours or a few days usually
<beastd>
I assume haasn and nevcairiel would have noticed already!
<nevcairiel>
sounds like you have zero first hand experience with a modern OLED if you belive it burns in after hours
<kasper93>
any plans for n6.1.2?
<BtbN>
If you make it show a static image for a full day, or even just parts of the screen, that will burn in
<nevcairiel>
but believe what you like, not those that actually use such screens 24/7 on a developer workload :D
<nevcairiel>
the rtings thing is obviously an extreme stress test, and it shows most issues with the W-OLED panels
<kasper93>
correct, but it is the only trustworthy source of information of the topic. Else you get hearsay
<kasper93>
on*
<haasn>
beastd: I didn't notice anything from it being curved
<haasn>
actually it looks more natural due to the ultra wide dimensions
<haasn>
otoh I noticed the pixel shifting quite prominently in the beginning
<haasn>
but after a month or two my brain filtered it out fully
<haasn>
the main issue of OLED is that you can't tell if the screen is turned on or off
<nevcairiel>
i never really noticed the particular subpixel layout on text that some people complain about, maybe on the first day? but quickly adapted
<haasn>
I sometimes accidentally turn it on when I want to turn it off
<haasn>
only to have to then turn it off again
<haasn>
yeah I just disabled all rgb subpixel hinting
<haasn>
ppi is high enough to not care anyway
<beastd>
sounds great. aspect and size also seem fitting for my use case
<haasn>
the G8 looks like it has the least burn-in out of all of the panels on that extreme test
<nevcairiel>
of course this is a 2022 panel, and there is probably newer ones by now that offer more everything, but probably also cost more :D
<haasn>
on a side note, I had worse panel uniformity from an LCD panel after a couple of years
<beastd>
nevcairiel, haasn: thanks againg. the alienware one seems to have the better housing/peripherals etc. do i understand it correctly that the samsung one has external psu and the alienware has internal. also can the lights on the rear side be turned off?
<haasn>
either mine doesn't have rear lighting or I turned it off and forgot it exists
<nevcairiel>
seems like you can turn it off in the OSD on the AW
<nevcairiel>
it doesnt really bother me so i never touched it, its pretty tame
<haasn>
FYI my OSD settings are Brightness 0 (min), Contrast 50 (max), Sharpness 10 (mid), Colour 25 (mid) and Tint 0 (mid) which seems to be true neutral
<haasn>
on the G8
<haasn>
huh apparently I do have an ambient light
<rajivharlalka>
Is there a flag to build ffmpeg with specific filters only?
<sdc>
I think --disable-filters --enable-filter=NAME works
<rajivharlalka>
Nope, that returns error , make: unrecognized option '--disable-filters' , and the same for enable-filters
<kasper93>
works for me
<kepstin>
those are configure options, not make options. Note that this channel is for developing ffmpeg itself, usage questions are better directed to #ffmpeg
<sdc>
rajivharlalka: ah yeah under ./configure --help you can find configuration options
<rajivharlalka>
oh sorry, my bad on that. looks this would work. Thanks
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Livio has quit [Ping timeout: 246 seconds]
rvalue has quit [Read error: Connection reset by peer]
<cone-767>
ffmpeg Lynne master:39b8d84b53f1: aacdec: move from scalefactor ranged arrays to flat arrays
<cone-767>
ffmpeg Lynne master:caeb27509245: channel_layout: add new channel positions supported by xHE-AAC
<cone-767>
ffmpeg Lynne master:0f2303f62907: aacdec: expose channel layout related functions
<cone-767>
ffmpeg Lynne master:0513c5cd25ca: aacdec_dsp: implement 768-point transform and windowing
<cone-767>
ffmpeg Lynne master:7cd8a3f50950: aactab: add deemphasis tables for USAC
<cone-767>
ffmpeg Lynne master:a300ec3569f9: aactab: add tables for the new USAC arithmetic coder
<cone-767>
ffmpeg Lynne master:23b45d7e20b0: aactab: add new scalefactor offset tables for 96/768pt windows
<cone-767>
ffmpeg Lynne master:eee5fa08083c: aacdec: add a decoder for AAC USAC (xHE-AAC)
<cone-767>
ffmpeg Lynne master:b3212797ae58: fate: add tests for xHE-AAC
<cone-767>
ffmpeg Lynne master:7852d9e604f1: libavcodec: bump minor version for xHE-AAC
<cone-767>
ffmpeg Lynne master:24d3291f7c82: changelog: add entry for xHE-AAC
<jamrial>
Lynne: you did not bump minor or add APIChanges entry, leaving instead the todo in the commit message
Livio has joined #ffmpeg-devel
<jamrial>
and did you confirm with JEEB the new channels are correct?
<Lynne>
err, I did bump minor
<Lynne>
I don't think apichanges are needed, no api was added
<mkver>
Lynne: You also did not change AAC's codec descriptor. It still claims intra_only.
<jamrial>
Lynne: no, you bumped lavc minor (despite no api changes happening there), but not lavu for the new channels
<Lynne>
last I heard everyone was happy with the channel layouts, JEEB gave an okay, he had some concerns with the TTL/TTR text IDs, but I responded and he didn't say anything more
<Lynne>
we bump lavc minor for new decoders
<jamrial>
you didn't add a new AVCodec, you extended an existing one
<Lynne>
details
<Lynne>
do I bump minor or micro for lavu? it's only enum entries I added
<jamrial>
minor, since it's new defines in a public header
<jamrial>
send patches for that and the APIChanges entry
<Lynne>
yup, I was planning to
lexano has joined #ffmpeg-devel
<Lynne>
do I list both AV_CH_TOP_SURROUND_LEFT and AV_CHAN_SIDE_SURROUND_LEFT, or only AV_CHAN_SIDE_SURROUND_LEFT?
<Lynne>
the former is just a #define of the latter as a bitmask
<jamrial>
mention both defines and enum values, in separate lines
<cone-767>
ffmpeg Lynne master:63e166d8028b: lavu: bump minor and add APIchanges entries for the new channel positions
<mkver>
Lynne: This does not even come close to what is required.
<mkver>
You need to change the encoders (they will need to set the key frame flag explicitly) as well as the parser (which now also needs to set it). Even the ordinary AAC decoder will probably have to be adapted.
<mkver>
IIRC several AAC containers support only a subset of AAC (but I've forgotten the details). Is this a problem wit xhe?
<Lynne>
LATM supports it, ADTS, I think it isn't supported, but the muxer limits what it can accept
<Lynne>
there are some compatibility issues with extended streams, but what comes out of exhale works perfectly
<Lynne>
mkver: until we get actual reports of this being an issue, I think it should be fine
<Lynne>
if it's not possible to produce such files, do we need it?
<kasper93>
aacdec_usac.c:1422 to be specific, crashes on av_free
Livio has joined #ffmpeg-devel
<kasper93>
s/realloc/av_realloc/ at 1399
<kasper93>
(it tries to _aligned_free, normal malloc returned ptr, just in case it is not obvious)
<Lynne>
oof, good catch
<cone-767>
ffmpeg James Almer master:d8ffd65bfd07: avcodec/aac/aacdec_usac: remove call to realloc
<Lynne>
was going to send a patch, but thanks
<BtbN>
I'm actually surprised we don't have a way to malloc aligned memory
<BtbN>
as in, with passing in the desired alignment
<jamrial>
someone sent a patch to add a new function like that
<BtbN>
Yes, but as a buffer
<BtbN>
which seems odd. We should have a lower level malloc function for it, and the buffer should just use that
<jamrial>
but is it useful? av_malloc will always use the adequate alignment for simd based on host
<BtbN>
Well, there's always edge cases. Like in this case, a weird driver needing much bigger alignment
<BtbN>
But not sure what to do with that whole tegra patch-set... I'm definitely not a fan of creeping that kind of stuff into nv-codec-headers, let alone ffmpeg
<BtbN>
Why does ffmpeg have to deal with clocking the card? That just sounds wrong
<mkver>
jamrial: SIMD is not everything. Avoiding false sharing typically entails allocating to the cacheline size and av_malloc does not align enough for that purpose.
<jamrial>
kasper93: that sample wont decode even after the realloc fix
<kasper93>
cool, I know that now
<kasper93>
but at least it doesn't crash, doesn't it
<mkver>
The problematic thing is that av_malloc() has a codepath in which it resorts to plain malloc which does not support arbitrary alignments. So in this case we would need to align the pointer on our own and this would be incompatible with av_free.
<jamrial>
not if av_free is made aware of such allocations
<jamrial>
which i think was what the old memalign hack thing did
<BtbN>
The correct solution there would imo be to just not support that
<BtbN>
i.e. it becomes a configure dependency to have working aligned alloc, and if the platform does not, the code can't be built
b50d has joined #ffmpeg-devel
<mkver>
What platforms actually use the malloc codepath?
<jamrial>
Lynne: "src/libavcodec/aac/aacdec_lpd.c:134:48: runtime error: index 9 out of bounds for type 'uint32_t [8][8]'" ubsan output from that sample above
Livio has quit [Ping timeout: 264 seconds]
Livio has joined #ffmpeg-devel
<Lynne>
I'll take a look
<cone-767>
ffmpeg Lynne master:18757b26bd4c: aacdec_usac: fix typo in fac_length
<cone-767>
ffmpeg Michael Niedermayer master:348c3a7ffe0c: avformat/fwse: Remove always false expression
<cone-767>
ffmpeg Michael Niedermayer master:847a53f264db: avcodec/tests/jpeg2000dwt: Use 64bit in err2 computation
<cone-767>
ffmpeg Michael Niedermayer master:12391b732f81: avcodec/tests/jpeg2000dwt: Use 64bit in comparission
<cone-767>
ffmpeg Michael Niedermayer master:2e5433dc1209: avcodec/vvc/mvs: Initialize mvf
<cone-767>
ffmpeg Michael Niedermayer master:30f2bac9f7a0: avcodec/wavpack: Remove dead assignments
<cone-767>
ffmpeg Michael Niedermayer master:6f976db25186: avcodec/wavpackenc: Use unsigned for potential 31bit shift
<cone-767>
ffmpeg Michael Niedermayer master:e5098589b0ca: avcodec/rv34: assert that size is not 0 in rv34_gen_vlc_ext()
<cone-767>
ffmpeg Michael Niedermayer master:d741638042d8: avcodec/scpr3: Check add_dec() for failure
<cone-767>
ffmpeg Michael Niedermayer master:161d0aa2a8d1: avcodec/tests/dct: Use 64bit in intermediate for error computation
<cone-767>
ffmpeg Michael Niedermayer master:19db9636c52c: avcodec/notchlc: Check init_get_bits8() for failure
<cone-767>
ffmpeg Michael Niedermayer master:160b81ce2a87: avcodec/pcm-dvdenc: 64bit pkt-size
<cone-767>
ffmpeg Michael Niedermayer master:6106177ad66a: avcodec/proresenc_anatoliy: Assert that AV_PROFILE_UNKNOWN is replaced
kekePower has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
<kasper93>
Lynne: I get also "aacdec_usac.c:411:13: runtime error: index 64 out of bounds for type 'uint8_t[64][3]' (aka 'unsigned char[64][3]')"
<mkver>
Sean_McG: make fate-rsync
<Lynne>
kasper93: on it
Livio has quit [Ping timeout: 260 seconds]
<Lynne>
patches sent
dionisis has quit [Quit: WeeChat 3.8]
dionisis has joined #ffmpeg-devel
dionisis has quit [Client Quit]
dionisis has joined #ffmpeg-devel
dionisis has quit [Client Quit]
dionisis has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
<kasper93>
Lynne: thanks, do you want one more? :) aacdec.c:594:16: runtime error: index 16 out of bounds for type 'ChannelElement *[16]' (aka 'struct ChannelElement *[16]') (from ff_aac_usac_reset_state aacdec_usac.c:284)