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
tufei has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
tufei has quit [Ping timeout: 260 seconds]
iive has quit [Quit: They came for me...]
cone-163 has quit [Quit: transmission timeout]
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht4 is now known as arch1t3cht
System_Error has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 276 seconds]
thilo has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has quit [Ping timeout: 276 seconds]
MisterMinister has quit [Ping timeout: 265 seconds]
pross has joined #ffmpeg-devel
^Neo_ has quit [Ping timeout: 245 seconds]
jamrial_ has quit []
<fflogger> [newticket] steven1: Ticket #11326 ([ffmpeg] Null Pointer Dereference in iamf_read_header /ffmpeg/libavformat/iamfdec.c:110:54) created https://trac.ffmpeg.org/ticket/11326
System_Error has quit [Ping timeout: 260 seconds]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 248 seconds]
rvalue- is now known as rvalue
zenmov has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
cone-789 has joined #ffmpeg-devel
<cone-789> ffmpeg Zhao Zhili master:82c208b65326: avfilter/textutils: Add missing time_internal.h
<cone-789> ffmpeg Zhao Zhili master:fe2c9746dea0: avcodec/cavs: Limit align requirement to variable than type
<cone-789> ffmpeg Zhao Zhili master:57861911a34e: avutil/mem_internal: define DECLARE_ALIGNED as C11's alignas
<cone-789> ffmpeg Zhao Zhili master:59057aa807c4: avutil/mem_internal: local align should always work
bilboed has quit [Quit: The Lounge - https://thelounge.chat]
bilboed has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
cone-789 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 244 seconds]
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
King_DuckZ has joined #ffmpeg-devel
<King_DuckZ> hello, I'm seeing a difference in PTS in mpv between mainline pc version and our embedded fork and I tracked PTS to line 414 here https://ffmpeg.org/doxygen/3.4/rkmppdec_8c_source.html
jamrial has joined #ffmpeg-devel
<King_DuckZ> my video file plays with this warning: "No video PTS! Making something up. Using 25.000000 FPS." which is printed by mpv, and pc version seems to have PTS values such as 0, or the magic -9.22^18, but on rockchip I get 0.3 on the first frame and never the magic number, so mpv doesn't try to calculate the correct PTS
<King_DuckZ> so my questions: 1. am I correct the problem is in ffmpeg setting bogus PTS values? and 2. ffmpeg's pts is an int64 and mpv's is a double, what int64 magic value will make it so mpv uses its -9.whatever magic value?
<BtbN> Sounds more like questions for #mpv?
<King_DuckZ> ok
<Compn> King_DuckZ, does your file have video pts ?
<JEEB> > between mainline and embedded fork
<Compn> ehe
<thardin> TIL if you commdnt out an entry in allformats.c, configure still picks it up
<elenril> not commenting it out right
Krowl has quit [Read error: Connection reset by peer]
<Compn> King_DuckZ, if you test your file with git master ffmpeg and our rockchip mpp demuxer isnt reading the pts correctly, you can file a bug at our bug tracker, http://trac.ffmpeg.org
<Compn> or stream whatever it is
<JEEB> also they linked version 3.4... I'd say that is far behind something that we actively support
<JEEB> and yes, you mentioned master
<JEEB> good
<JEEB> (for some reason my brain didn't interpret it first)
System_Error has joined #ffmpeg-devel
Sean_McG has quit [Ping timeout: 244 seconds]
Sean_McG has joined #ffmpeg-devel
<Lynne> well, we were too slow and moronix screwed up the facts as usual
<King_DuckZ> Compn: judging by the warning I get from mpv, no it doesn't
<King_DuckZ> JEEB: sucks to be me! :(
<King_DuckZ> anyways I found a dodgy edit that was setting pts to -1 if it was AV_NOPTS_VALUE, which is 92233etcetc, which is the 9.22^18 I found in mpv, so that's one issue solved and part of our fork
<King_DuckZ> JEEB: sorry about the version, it's just some link I followed from the search engine, I don't know which version we're based on but it's a recent-ish one for sure (almost)
<JEEB> generally for doxygen it's called "trunk" how you get the current master
<JEEB> and then you also see if that no longer matches what you have
<JEEB> also if that thing is something you are interested in upstreaming and it is something that people can gain access to hardware-wise and does not make resulting binaries non-distributable, then you may possibly receive somewhat more positive reception :)
<King_DuckZ> I would love to, it's not something I get to decide unfortunately :(
<King_DuckZ> still waiting for my old compositor project from like 5 jobs ago to be released under gpl, they agreed that "yes later" and 6 years have passed
Krowl has joined #ffmpeg-devel
mateo` has quit [Quit: WeeChat 4.4.3]
<King_DuckZ> so, I'm really thinking my issue is on the ffmpeg side of things... mpv has a correct_video_pts() functions which I assume gets invoked per-frame: on the first invocation it has pts=0.0 on my pc, and 0.3something on the embedded device and ffmpeg seems to be setting it to 73800... could it be a bug in that mpp_frame_get_pts() function?
<thardin> seems the main thing to make wrapping aviocontext chooch is to add an opaque pointer to urlcontext
mateo` has joined #ffmpeg-devel
<thardin> woop, it works
mkver has quit [Ping timeout: 260 seconds]
<fflogger> [editedticket] madsweeney: Ticket #11322 ([avformat] ffmpeg stops with exit code 0 during input of hls http stream) updated https://trac.ffmpeg.org/ticket/11322#comment:6
<King_DuckZ> lucky you! I'm yawning so much I'm afraid my jaw's gonna get dislodged
<King_DuckZ> and yet it still doesn't work :(
<haasn> JEEB: what does it mean if a file is tagged as BT.2020, but the mastering display metadata contains a white point other than D65?
<JEEB> haasn: mastering display is just the display that was utilized to master it (supposedly)
<haasn> will white elements in the file be encoded as (1,1,1) or encoded as some RGB value corresponding to the mastering display white point?
<JEEB> it is just a hint for gamut and tone mapping - "the mastering person was not able to see this stuff anyways"
<JEEB> haasn: it doesn't change the encoding of the content
<haasn> right, but for that the white point is irrelevant
<JEEB> it is only display hints
<haasn> so why does the metadata contain a white point at all?
<haasn> either the mastering display is adapting to the white point, or it is irrelevant information
<haasn> I am thinking we should just ignore the mastering metadata white point completely
<haasn> if what you are saying is correct
<JEEB> yea, that metadata is not supposed to change the interpretation of the coded color, only help with adjustments afterwards
\\Mr_C\\ has joined #ffmpeg-devel
<JEEB> and I don't think ST2086 describes it at all
* JEEB double-checks
<JEEB> > This document provides a specification of the metadata defining the color volume (the color primaries, white point, and luminance range), which can be used to assist in achieving consistent results on different displays
<haasn> the only time it would be relevant maybe is for XYZ content which can be mastered to different white points
<haasn> although I think such content would be in violation of the spec anyways
<haasn> so shrug
<haasn> I'll remove it for now until such a use case arises
<JEEB> I would guess it's there just because that definition is part of the display calibration definition
<JEEB> but essentially yes, since this metadata does not affect the interpretation of the signal
<JEEB> it's rather... not-that-useful
<JEEB> unless the white point somehow changes parameters when gamut or tone mapping
<JEEB> the one thing it could be utilized for (which is a highly unlikely and definitely not automatable thing), is if you know content X is looking incorrect, you can check if just interpreting it with that white point fixes it. at which point you know that someone f'd up and didn't adjust.
wyatt8740 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<haasn> fair
wyatt8740 has joined #ffmpeg-devel
<King_DuckZ> dumb question but what are the mpp_* functions that I see being used around?
<King_DuckZ> I guess they come from here? https://github.com/rockchip-linux/mpp/tree/develop but the implementation is not in there, only the prototypes
<JEEB> rockchip's crappy self-invented hardware decoding API I presume
<JEEB> wow, they have a pkg-config thing
<JEEB> > require_pkg_config rockchip_mpp "rockchip_mpp >= 1.3.7"
<King_DuckZ> that's the same as my link
<JEEB> ah
<JEEB> and yea, that project contains the pc file
<King_DuckZ> I'm not sure what you mean, isn't rockchip_mpp it itself?
<JEEB> just that the git repo ("project") contained the pkg-config file that the FFmpeg configure checks for
<King_DuckZ> ah ok
Krowl has quit [Read error: Connection reset by peer]
<jamrial> looks like the mem_internal.h changes may have broken msvc
<jamrial> nevcairiel: can you check?
<nevcairiel> because about 1000 tests are crashing? seems like a good bet :p
<jamrial> heh
<elenril> alignas broken on msvc?
<elenril> I'd be shocked
King_DuckZ has quit [Ping timeout: 246 seconds]
av500 has quit [Quit: Konversation terminated!]
av500 has joined #ffmpeg-devel
zenmov has quit [Ping timeout: 272 seconds]
<nevcairiel> reverting the two mem changes certainly makes it pass, cant investigate much more right now as its dinner time
<thardin> just got an inquiry about dolbye
witchymary has quit [Ping timeout: 272 seconds]
<nevcairiel> gave it another short poke but couldnt find out anything useful yet. might have to look at the generated binary and/or setup a test case to see whats going on
ngaullier has quit [Ping timeout: 252 seconds]
witchymary has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 252 seconds]
SuperFashi has quit [Ping timeout: 260 seconds]
<haasn> https://0x1.st/eBYo.jpg swscale
<JEEB> nice stuff
<JEEB> that's a movie I actually ended up purchasing twice :D once for watching with SDR, and then second time when madshi posted a sample of it and I had to see WTF kind of mastering was going on
<JEEB> great to see swscale finally getting proper primaries and transfer support
<JEEB> because previously I wasn't even sure if it handled just matrix coefficients, or did it do primaries too
<haasn> all of the logic is written, now just need a bit of minor cleanup
<haasn> i'll send the series most likely on monday
<JEEB> nice
<JEEB> I wonder how slow 2160p HLG to BT.709 SDR conversion would now be
<haasn> let's try
<haasn> frame= 2000 fps= 85 q=-0.0 Lsize=N/A time=00:00:46.04 bitrate=N/A speed=1.96x # just decoding
King_DuckZ has joined #ffmpeg-devel
<haasn> uhh
<haasn> it drops to 1 fps when going through swscale rgb<->yuv conversion independent of whether color mapping is enabled or not
<haasn> must be some ungodly slow path
<haasn> I didn't yet add the ability to do color mapping directly on yuv color space
<haasn> oh
<haasn> it's reconfiguring itself per frame
<haasn> oops
<fflogger> [editedticket] MasterQuestionable: Ticket #11322 ([avformat] ffmpeg stops with exit code 0 during input of hls http stream) updated https://trac.ffmpeg.org/ticket/11322#comment:7
<another|> call it dynamic and say it's a feature
cone-617 has joined #ffmpeg-devel
<cone-617> ffmpeg Marton Balint master:06247ae7460d: avfilter/asrc_sine: factorize sampling to a separate context
<cone-617> ffmpeg Marton Balint master:6189cb47fc06: fate: adjust frequencies of the sine filter
<cone-617> ffmpeg Marton Balint master:8d6f3bcb9604: avfilter/asrc_sine: increase frequency accuracy
<cone-617> ffmpeg Marton Balint master:f5948543f4fd: fate: revert previous frequency adjustments of the sine filter
paulk has quit [Ping timeout: 276 seconds]
<cone-617> ffmpeg Marton Balint master:4100a2da297b: tests/fate/filter-audio: add aloop test
<haasn> there we go :D
<haasn> frame= 2000 fps= 43 q=-0.0 Lsize=N/A time=00:00:46.04 bitrate=N/A speed=0.987x # roundtrip through rgb48 and back, no color mapping
<haasn> frame= 2000 fps= 36 q=-0.0 Lsize=N/A time=00:00:46.04 bitrate=N/A speed=0.834x # with color mapping in C
Marth64 has quit [Quit: Leaving]
<haasn> JEEB:
<haasn> well, it could be worse
<haasn> all of the expensive logic is hidden away inside a 3DLUT
<haasn> so this is just measuring the overhead of the 3DLUT lookup
<haasn> which I wrote using just simple C
<haasn> could definitely be optimized with the right assembly love
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
<haasn> the biggest slowdown we could eliminate is the cost of going via rgb48
<haasn> which should be easy to eliminate
<haasn> if anybody has ideas about low hanging fruit to speed up the lookup further
<haasn> obviously some other ideas would be to strip the alpha channel, to try a lower input bit depth, etc
llrcombs is now known as rcombs
Everything has joined #ffmpeg-devel
<fflogger> [editedticket] Disjt: Ticket #11283 ([avfilter] "aloop" filter somehow gave misalignment in 48 KHz Stereo WAV) updated https://trac.ffmpeg.org/ticket/11283#comment:14
<JEEB> haasn: not bad, more than half of 2160p50 live encoding
<fflogger> [newticket] michael.enke: Ticket #11327 ([ffmpeg] interactive mode interferes with stats_period time) created https://trac.ffmpeg.org/ticket/11327
<fflogger> [newticket] michael.enke: Ticket #11328 ([website] Which LGPL version is right? 2.1 or 3?) created https://trac.ffmpeg.org/ticket/11328
<fflogger> [editedticket] oromit: Ticket #11328 ([website] Which LGPL version is right? 2.1 or 3?) updated https://trac.ffmpeg.org/ticket/11328#comment:1
iive has joined #ffmpeg-devel