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
DauntlessOne has joined #ffmpeg-devel
thilo_ has quit [Ping timeout: 246 seconds]
thilo_ has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
Marth64 has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 260 seconds]
arch1t3cht4 is now known as arch1t3cht
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 245 seconds]
luna- has left #ffmpeg-devel [#ffmpeg-devel]
_av500_ is now known as av500
ngaullier has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<thardin> what's the status of 608/708 CC at the moment?
<thardin> last time I looked it looked like extracting/injecting CCs into H.264 fits poorly into ffmpeg's data model
Krowl has quit [Read error: Connection reset by peer]
ngaullie has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 252 seconds]
<thardin> this also overlaps with teletext support
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<Lynne> I both work fine
<Lynne> I even remember a BBC sample where you could see teletext
<thardin> I know mpv handles this, and there's the subcc stuff in the lavfi device
<thardin> but can for example webvtt be transcoded to suitable side data and them embedded?
<thardin> then*
<thardin> the other way around seems possible
<elenril> thardin: ffmpeg CLI architecture should now make it fairly easy for a decoder to output two streams
<elenril> I'm already doing that fo multiview
<elenril> s/two/N/
<thardin> oh? what about the other way around?
<elenril> that's not as easy
<elenril> I'm not done with encoders yet
<elenril> and there'd need to be some kind of synchronisation
<thardin> yeah
Krowl has joined #ffmpeg-devel
<cone-373> ffmpeg Anton Khirnov master:794308c61b38: doc/ffmpeg: rewrite the detailed description chapter
cone-373 has joined #ffmpeg-devel
<cone-373> ffmpeg Anton Khirnov master:7ab1ddbaf3f4: lavfi/vf_alphamerge: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:a2881814b854: doc/ffmpeg.texi: add a diagram for the loopback decoder example
<cone-373> ffmpeg Anton Khirnov master:bc418fd87228: lavfi/vf_colorspace: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:631e5bcdc7df: lavfi/vf_ciescope: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:95c9c1c2becd: lavfi/vf_boxblur: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:da8cc791e237: lavfi/vf_copy: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:a92052cb97d2: lavfi/vf_crop: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:eff406f5dd55: lavfi/vf_datascope: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:f8574da8e5a3: lavfi/vf_deband: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:9ebdaa6c7d41: lavfi/vf_detelecine: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:87a619c54924: lavfi/vf_drawtext: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:f59c1b8a0cdc: lavfi/vf_edgedetect: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:2161abaecf70: lavfi/vf_elbg: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:401130410275: lavfi/vf_fade: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:637b242ec3d2: lavfi/vf_feedback: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:4863570d49bf: lavfi/vf_fieldhint: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:977059718b68: lavfi/vf_fieldmatch: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:cfbb6e9f5d8a: lavfi/vf_fieldorder: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:eb0c9670b4a9: lavfi/vf_format: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:a81061b911b6: lavfi/vf_hwmap: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:e0eec71a13ed: lavfi/vf_geq: switch to query_func2()
<cone-373> ffmpeg Anton Khirnov master:b1247e7c1ffc: lavfi/avfilter: move AVFilterContext.ready to FFFilterContext
<cone-373> ffmpeg Anton Khirnov master:71f176e3ce75: lavfi/avfilter: move AVFilterContext.{enable,var_values} to FFFilterContext
<cone-373> ffmpeg Anton Khirnov master:4472bddb18f3: lavfi/avfilter: move AVFilterContext.command_queue to FFFilterContext
<cone-373> ffmpeg Anton Khirnov master:6647e57dcb97: lavfi/avfilter: document AVFilterContext.is_disabled as private
<cone-373> ffmpeg Anton Khirnov master:d3739dcbec29: lavfi/avfilter: make ff_inlink_evaluate_timeline_at_frame() static
<cone-373> ffmpeg Anton Khirnov master:26ae8d1891eb: lavfi/avfilter: drop ff_ prefixes from static functions
<cone-373> ffmpeg Anton Khirnov master:496b8d7a130e: fftools/ffmpeg_filter: stop setting a no-op option
<elenril> Lynne: src/libavfilter/vf_avgblur_vulkan.c:74:11: error: implicit declaration of function ‘ff_vk_spirv_init’; did you mean ‘ff_vk_shader_init’? [-Werror=implicit-function-declaration]
<Lynne> it does have a correct include at the top, make clean, just in case?
<elenril> I did
<elenril> my "full" config builds fine, this is a static-only one with just , '--enable-gpl', '--enable-version3', '--enable-nonfree', '--disable-valgrind-backtrace', '--disable-sndio'
___nick___ has joined #ffmpeg-devel
<Lynne> _deps is setup correctly, let me try to replicate just in case
<elenril> I'll try to purge the build dir
<Lynne> can replicate
derpydoo has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
<Lynne> I don't get it, vulkan is enabled, spirv_compiler is not, yet the vulkan filters get compiled anyway despite _deps
ngaullie has quit [Ping timeout: 252 seconds]
<Lynne> seems like spirv_compiler is in some weird state where it isn't enabled, but isn't disabled
<Lynne> disabling it explicitly does fix it
<Lynne> I got it, spirv_compiler isn't declared in _LIST
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Workl has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
<Lynne> patch sent
<Lynne> not sure I like this solution, but only putting it into EXTERNAL_LIBRARY_LIST made it work
<Lynne> but it does mean that users can exlpicitly enable it via --enable/--disable, and it does get reported when priting all results
<Lynne> if only there was a way to add OR() to _deps, but until then, this will work
Workl2 has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
Workl has quit [Ping timeout: 276 seconds]
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 260 seconds]
<elenril> maybe some build system guru will have a better idea
<Lynne> some gstreamer folks were interested in adding meson support
<Lynne> I told them to send a patch, but its been a while now
<wbs> it's easy to get a barebones setup working, but all the individual component enabling/disabling would be hugely clunky to reimplement
<elenril> meson was a mistake
<courmisch> how come people did not stop posting on ffmpeg-devel@ whilst I was on vacation
<courmisch> elenril: yeah, obviously build.rs is The Way
<courmisch> ooh, imagine the pent-up pressure after I could not troll for 10 days straight
derpydoo has quit [Ping timeout: 260 seconds]
Workl2 has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<thardin> seems mpeg-ts does support 608 CCs as their own thing
<thardin> rather than being embedded in the video element stream
cone-373 has quit [Quit: transmission timeout]
<JEEB> probably a mapping exists for that as well :P
<thardin> an amazing amount of overhead: four bytes of CC data in 176 bytes
<thardin> 4300% (:
<courmisch> you did not count the overhead of the DVB error correction
<thardin> the upshot is that we could potentially support 608 "subs". but there is perhaps some question of how exactly to transcode say srt subs to it, since they're signalled over multiple frames (either on odd or even fields)
<thardin> and there's also the question of reordering. or lack thereof
jamrial has joined #ffmpeg-devel
auto has joined #ffmpeg-devel
<kasper93> Lynne: gstreamer folks are maintaining meson.build transcribed from configure https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg
<Lynne> yup, that's why I told them to sent a patch
<Lynne> last I remember it doesn't support assembly, but it shouldn't be hard to add support with meson having native asm support
<auto> who want sold cacheee for 2gis store maps for me and I run it on linux my stand alone vm ?
<thardin> could this give us reasonable ./configure times?
<Lynne> according to a benchmark a few years ago, meson was slower than running dash+our configure
<kasper93> though for a nice and neat implementation of Meson, it might be better to design it from scratch. The current version is auto-transcribing the configure script, so the structure remains mostly the same.
<kasper93> Yeah, meson probably won't be faster for clean configure, but maybe after the dependencies are cached incremental would be faster
<thardin> sounds potentially nice
<thardin> less maintenance too?
cone-403 has joined #ffmpeg-devel
<cone-403> ffmpeg James Almer master:362586fcaddf: avfilter/vf_xpsnr: remove duplicated DSP infranstructure
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
<elenril> haasn: in vf_libplacebo, there is the following check
<elenril> if (!vkhwctx || vkhwctx->act_dev != s->vulkan->device)
<elenril> under what conditions would the second part be true?
<Marth64> thardin: rcwt muxer may be useful to you if you are doing 608/708 work
<Marth64> if you need to keep the cc bytes for analysis or whatever
<haasn> elenril: you could have two vulkan devices
<haasn> An API user could init a vulkan device without telling avfilter about it
<thardin> Marth64: hmm, not quite I think
<haasn> Well, maybe that’s not allowed in either case?
<thardin> but at least there is some 608 stuff
<elenril> haasn: but when vkhwctx is non-NULL, it is always given to libplacebo as the device to use
<haasn> Did you have to pass the hectx to the filter at init time to send it frames from that hwctx
<elenril> yes
<haasn> I guess if that’s UB in any case then we can skip the check
<elenril> I can make it an assert
<elenril> just wondering if it's there for an actual reason
<jamrial> wbs: if you can, please test the videotoolbox changes in my latest set
<wbs> jamrial: ok, can try to do it tonight
<jamrial> thanks
<Marth64> I have a mac if you need a second hand
<jamrial> sure
<jamrial> there's also the capture device in lavd that seems outdated by now
<jamrial> regarding mapped pixfmts
<wbs> jamrial: ok - what tests do you want me to run?
<jamrial> wbs: make sure the pixfmt works? :p
<jamrial> i mapped a bunch in hwcontext_videotoolbox
<jamrial> and made the lavc choose kCVPixelFormatType_4444AYpCbCr8 in videotoolbox_best_pixel_format() if there's alpha and is 8bit, instead of the 16bit variant
<wbs> do you have any specific samples that should trigger it?
<jamrial> no, but looks like any 8bit yuv with alpha should do it?
<wbs> provided that the videotoolbox decoder can decode such alpha formats :P
<wbs> which codecs even support alpha commonly?
<jamrial> hevc and vp9 i guess
Krowl has quit [Read error: Connection reset by peer]
<JEEB> in which cases it's essentially a second stream within the same stream :)
<JEEB> for some reason it never is a primary requirement that would make standardization want a 4th plane
<wbs> ok - vp9 support in videotoolbox may be a bit much to ask, but I guess hevc might be supported
<Marth64> i will look for samples and test also when i can
<JEEB> ye apple was one of the vendors specifyin gthe alpha stuff
<JEEB> for HEVC
<wbs> I guess we might have some hevc/alpha samples in fate-samples?
<wbs> JEEB: oh, good
<wbs> Marth64: if you can do it instead of me, it's very much appreciated :-)
<JEEB> (why is there no sample video linked on that page, lol)
<JEEB> https://trac.ffmpeg.org/ticket/7965 seems to contain a sample
<Marth64> wbs: I don't mind. may ping for help is all. thx
<Marth64> an M3 is fine here right?
<JEEB> that definitely is, it has everything up to AV1
<Marth64> ok, will fire up a build in a few
<wbs> Marth64: an M3 is as good as it gets for (released) desktop HW, so it should be fine :P
<Marth64> it is terrifyingly fast and runs cool for what it is
<Marth64> i respect it as a cpu
<Marth64> soc i guess
<wbs> yep
<wbs> but I read M4 is 25% faster :P
ccawley2011 has joined #ffmpeg-devel
<BtbN> Apple does not have a good track record with precentages
<BtbN> when they claimed M1 was two times faster than Intel, the picked a random years old Laptop CPU to compare against
vipyne has quit [Quit: Leaving.]
<Marth64> I believe that..against their own 2019 models though I remember my M1 model running circles around the poor i7 running like a loud jet
<Marth64> jamrial: the set is https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13058 ? series set /20 but only I see 4 patches (assuming the others probably already merged)
<jamrial> that's the set, and nothing is merged
<Marth64> got it.. only apply the 4 patches or am I missing another set?
<Marth64> aha
<Marth64> will just pull from that branch
<jamrial> no, you need the whole set. no idea why patchwork didn't get them all
<Marth64> thx
<Marth64> and you want to see what the vt decoder picks as the pixel format
<jamrial> yeah
<Marth64> cool
vipyne has joined #ffmpeg-devel
<Marth64> ffprobing the sample linked here https://developer.apple.com/videos/play/wwdc2019/506 (same as above),
<Marth64> Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 6006 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default)
<Marth64> but ah, i did not specify hw decoder
<Marth64> my bad. one sec
<Marth64> it's also avc ... wondering what is going on with the link on their page
<Marth64> yeah, it's a fake ... download name is "506_hd_hevc_video_with_alpha.mp4" but is clearly not hevc
Krowl has joined #ffmpeg-devel
cone-403 has quit [Quit: transmission timeout]
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<Marth64> puppets_with_alpha_hevc.mov in that zip , I can confirm is 8-bit with alpha according to QuickTime itself
<Marth64> ffmpeg output from ayuv branch: https://paste.debian.net/hidden/504c2fc1/
vipyne has quit [Quit: Leaving.]
<jamrial> Marth64: Video: hevc (Main) (hvc1 / 0x31637668), yuv420p
<jamrial> so i guess the alpha is not being taken into account
<Marth64> yeah
<Marth64> QuickTime says its there
<Marth64> Window->Movie Inspector->Video Details ===> "Bit Depth: 8-bit" & "Alpha Channel: Yes" primaries/transfer fn/matrix all bt709
<Marth64> vanilla configure on the built ffmpeg ... it auto detected videotoolbox
Krowl has quit [Read error: Connection reset by peer]
vipyne has joined #ffmpeg-devel
<Marth64> hit a snag with dvd on mac so my patchset will be delayed till i figure out why
osvein has quit [Read error: Connection reset by peer]
ngaullier has quit [Ping timeout: 252 seconds]
osvein has joined #ffmpeg-devel
sgm has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
<Marth64> does anyone have history behind h264_redundant_pps bsf ? specifically any samples you can inform me of and I can procure on my own
<Marth64> debating if i should apply it in bdmv demuxer or let user decide
cone-765 has joined #ffmpeg-devel
<cone-765> ffmpeg Niklas Haas master:bed919efaab1: avfilter/src_movie: configure correct YUV attributes
<cone-765> ffmpeg Niklas Haas master:41ce370b657f: tests/swscale: fix minor typos
<cone-765> ffmpeg Niklas Haas master:aee19ee431bf: swscale/internal: rename NB_SWS_DITHER for consistency
<cone-765> ffmpeg Niklas Haas master:61369484f62e: swscale/internal: expose ff_update_palette() internally
<cone-765> ffmpeg Niklas Haas master:286bdc9cdc6d: swscale/internal: turn cascaded_tmp into an array
<cone-765> ffmpeg Niklas Haas master:c1a0e657638f: swscale/internal: constify SwsFunc
<cone-765> ffmpeg Niklas Haas master:b90d522d2c6a: swscale/internal: forward typedef SwsContext
<cone-765> ffmpeg Niklas Haas master:20b350b28488: swscale/internal: add typedefs for input reading functions
<cone-765> ffmpeg Niklas Haas master:73b3344edd39: swscale/input: parametrize ff_sws_init_input_funcs() pointers
vipyne has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
Traneptora has joined #ffmpeg-devel
<jkqxz> Marth64: There was an encoder used on some bluray streams which would sprinkle lots of extra PPSs through the stream, varying the initial QP and whether weighted prediction was enabled.
<jkqxz> That broke things when copied into a global header container, as the starting PPS was not suitable for most of the stream - seeking would return garbage until a new PPS appeared.
<jkqxz> The h264_redundant_pps BSF undoes that, rewriting the slice headers so that the whole stream can use a single PPS which can then be placed in the global header and work.
<jkqxz> For your question, applying it could break streams where there are multiple PPSs which vary some other property, but it is benign if there is only one PPS anyway.
<jkqxz> I would suggest not applying it automatically, but if you have lots of cases which are improved by it and none which fail then it might be convenient to do so.
witchymary has quit [Ping timeout: 244 seconds]
<Marth64> thank you jkqxz that was informative. I will not apply it automatically and leave it up to the user.
<Marth64> I think I have a sample causing it, because literally when seeking seeing bunch of PPS errors which got me interested
<Marth64> over time if I see greater sample size then can revisit applying it
witchymary has joined #ffmpeg-devel
Sean_McG has joined #ffmpeg-devel
<Sean_McG> haasn: your recently swscale/ppc changes broke all the FATE nodes with Altivec enabled
<Sean_McG> s/the/the PowerPC/
<auto> flops can solve any codec solution on a wheele
Krowl has joined #ffmpeg-devel
<Marth64> jkqxz: do you mind if I add some of that additional context you shared to the docs?
<Marth64> (I will paraphrase it)
<jkqxz> Sure, go ahead.
ccawley2011 has joined #ffmpeg-devel
<Marth64> thx
___nick___ has quit [Ping timeout: 246 seconds]
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-765 has quit [Quit: transmission timeout]
Workl has joined #ffmpeg-devel
Workl6 has joined #ffmpeg-devel
Workl6 has quit [Read error: Connection reset by peer]
Krowl has quit [Ping timeout: 255 seconds]
Workl has quit [Ping timeout: 252 seconds]
<ePirat> Marth64, what issues did you have with DVD on Mac?
ccawley2011 has quit [Read error: Connection reset by peer]
<Marth64> ePirat: All good - not Mac specific. typo in a new patch I made
<ePirat> ok!
<Marth64> thank you!
<ePirat> well I didnt do anything :D
<Traneptora> *swooshes cape*
<Marth64> nah, dvdread and dvdnav are solid
<Marth64> i just typoed
<ePirat> Marth64, nice work btw, this stuff seems quite complex to figure out
wbs has quit [Ping timeout: 260 seconds]
<Marth64> thank you ePirat. yeah, it is mostly that every DVD is different and the segmentation techniques in VOB are funky
wbs has joined #ffmpeg-devel
<Marth64> so it is painful to make even one minor change, have to test a bunch of samples
<Marth64> it seems to works pretty good now just have to go through the testing all over again
<Marth64> bluray is bit more straightforward, i have provided 2 modes selectable as an option in the demuxer.
<Marth64> (1) use libbluray's bd_read() which feeds a filtered mpeg-ts stream that has timestamp corrections, enables seeking etc
<Marth64> (2) use libbluray's file reading facilities to get the m2ts segments and demux them directly with ffmpeg; this is actually necessary for some discs because libbluray's filtering is overall good but produces corrupt packets in the transport stream
<Marth64> in case (2) i handle timestamp discontinuity
<ePirat> whats the benefit of 1) then?
<Marth64> seeking
<ePirat> Ah ok
<ePirat> I wonder if it would be possible to fix libbluray regarding the corrupt packets?
<Marth64> yep otherwise for (2) i need to copy over a ton of logic from libbluray ... not worth it it imo. (2) works better for a direct extraction, but also allows for manual single segment extraction which libbluray does not have
<Marth64> i would like to yes!
<Marth64> i figured since i still want to enable (2) to allow extraction of specific segments, i can go with this then try to hunt down whats happening in libbluray with the imapcted samples
<ePirat> yeah, sounds reasonable
<ePirat> sadly the libbluray dev hasnt been around for a while
<Marth64> yeah looks quiet. i'm building knowledge on libdvd*/libbluray will be able to help out
<Marth64> might as well, i want as much bit-perfect as possible demuxer for both
<Marth64> even 1 missing frame at the end makes me anxious
<elenril> that is the objectively correct attitude
<Marth64> really I need to sit down and author a bunch of libre test ISOs and make automated tests
<Marth64> but probably cannot until later this month
<Marth64> Do I need to clean up after an av_malloc() on demuxer close if I have FF_INFMT_FLAG_INIT_CLEANUP ?
<Marth64> I do the malloc in read_header
<Marth64> av_malloc*
<Marth64> besides that, testing looks good and i'm ready to push the set
<Marth64> s/push/email
<Marth64> looks like yes according to oggdec. will fix
vipyne has quit [Quit: Leaving.]
<Marth64> v3 dvd set is up, seeking is super smooth now
<Marth64> and chapter extraction works better
<Marth64> see v00 cover letter
<ePirat> Marth64, have a branch somewhere?
<Marth64> Yeah, I'll send a github
<Marth64> its rebased from HEAD sometime yesterday ... a77365d86497ead7ba101b248cc1efec9676476c
<Marth64> so pretty up to dat
<Marth64> the diff isn't overly dramatic but i split into little patches
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (lead.libera.chat (Nickname regained by services))]
<haasn> Sean_McG: does https://0x0.st/XEEj.txt fix it?