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.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 264 seconds]
arch1t3cht0 is now known as arch1t3cht
Traneptora has quit [Quit: Quit]
thilo has quit [Ping timeout: 246 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
feiw has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
pross has quit [Ping timeout: 245 seconds]
pross has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw has quit [Remote host closed the connection]
feiw2 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
vipyne has joined #ffmpeg-devel
feiw1 has joined #ffmpeg-devel
feiw2 has quit [Ping timeout: 246 seconds]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 272 seconds]
averne has quit [Ping timeout: 245 seconds]
averne has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
rvalue has quit [Ping timeout: 260 seconds]
rvalue has joined #ffmpeg-devel
mkver has quit [Ping timeout: 246 seconds]
aljazmc has quit [Remote host closed the connection]
Guest49 has joined #ffmpeg-devel
<Guest49>
Hi anyone if sees this. I am a student and mostly have done front tend development in high level languages. but I find this project interesting . I don't have any experience in low level development but I want to learn . Could anyone from this community point to resources to get skilled enough to contribute to this project?
<termos>
there are some tasks that can be done (under bug reports) here https://trac.ffmpeg.org but most of them are quite technical
Kwiboo- has quit [Quit: .]
<Guest49>
Like in sense ? I should know about c and assembly ? I know very basics of c but never written anything professional . any resources on learning would be helpful. '=D
Kwiboo has joined #ffmpeg-devel
<JEEB>
Guest49: start with building current git master (make sure you have build essentials and nasm installed for x86_64, then `mkdir my_build && cd my_build && path/to/source/configure` - and if it succeeds `make`)
<Guest49>
thanks I'll try building .. but I still find understanding the code very difficult. there are too many components. x86_64 . I am on m1 Mac.
<JEEB>
ah
Krowl has joined #ffmpeg-devel
Krowl has quit [Client Quit]
Krowl has joined #ffmpeg-devel
Guest49 has quit [Quit: Client closed]
Krowl has quit [Read error: Connection reset by peer]
deus0ww has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 255 seconds]
rvalue- is now known as rvalue
Krowl has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 246 seconds]
ccawley2011 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
ngaullier 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
Krowl has joined #ffmpeg-devel
Workl has quit [Ping timeout: 272 seconds]
<Daemon404>
they must have known what they were doing when naming something "a55"
<wbs>
Daemon404: lol
<wbs>
Daemon404: the numbering for those cores is ... interesting, in other ways as well. Guess what's next after A76, A77 and A78? They skipped A79 though, but went to A710. :P
<wbs>
(and after that, A715 and A720)
<elenril>
fucking numbers, how do they work
<galad>
and then you got Apple with A4 to A18, just to make things clearer
<wbs>
galad: right now, the numbers are kinda disjoint, but it's not long ago since the ARM cores were on Cortex A7-A15 as well
<wbs>
that's also kinda like vanilla clang and apple clang using different version numbers. these days, vanilla clang bumps major twice a year, while apple clang bumps once a year. apple clang is recently in the range 10-16, while vanilla clang is 8-19
<Daemon404>
and yet this is still better than intel or amd
Krowl has quit [Read error: Connection reset by peer]
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
cone-035 has joined #ffmpeg-devel
<cone-035>
ffmpeg Michael Niedermayer avcodec_yuv_range_v3:HEAD: avcodec/msmpeg4dec: init dc_pred_dir
<haasn>
michaelni: accidentally pushed a branch to source.ffmpeg.org, can you delete `avcodec_yuv_range_v3` ?
<haasn>
I tried but don't have perms
<haasn>
I'm actually surprised it let me push a branch in the first place
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 276 seconds]
Krowl has joined #ffmpeg-devel
lexano has quit [Ping timeout: 246 seconds]
lexano has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 260 seconds]
<Lynne>
I've never done accidental pushes, and was always paranoid about what I push, but after I separated my ssh keys, I don't have to worry about it ever
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 276 seconds]
<Daemon404>
i run --dry-run every single time
<Daemon404>
due to paranoia
<JEEB>
that's an option I *very* often utilize
<JEEB>
also naming remotes in various ways
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
I also run --dry-run, but more frequently I enable verbose mode, which adds a single line to tell you where you're pushing to
vipyne has joined #ffmpeg-devel
<JEEB>
yea that is if the remote name is generic or otherwise non-descriptive like "origin"
<JEEB>
for me usually origin is the externally visible/public repo
<jdarnley>
haasn: I think you need to ping j-b or thresh for that
<JEEB>
then I have something like github/gitlab for my own stuff, and origin_pusher for the private end points
<Lynne>
JEEB: it shows you the final .git URL
<JEEB>
yea
<JEEB>
as I said, if the remote names are generic that indeed does help :)
<jdarnley>
Is verbose mode available as a .gitconfig option?
mkver has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 260 seconds]
vipyne has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
usually I have my working repos tracking my fork
<haasn>
just this branch for some reason was not set up with any remote
<haasn>
so just `git push` picked origin as the default remote
<haasn>
maybe I can set up git to reject `git push` without remote on untracked branches
Traneptora has quit [Quit: Quit]
<another|>
I usually track master from upstream but push default to my fork
<another|>
see remote.pushdefault
Traneptora has joined #ffmpeg-devel
cone-035 has quit [Quit: transmission timeout]
<michaelni>
haasn, this needs jb/thresh to look at it. I think a custom hook is rejecting all my attempts to delete the branch. I could disable the hook with the access i have but not knowing exactly what the hook does, it seems wiser to wait for tresh who added this hook in february last year
<haasn>
fair
<michaelni>
it also could be something else iam missing. I do have RW+ powers so i should theoretically be able to delete the branch
<BtbN>
that seems like just an anti-force-push hook that also prevents branch deletion, since it's technically a force-push
Manouchehri has joined #ffmpeg-devel
<wbs>
re git remote setups, I usually have origin as a readonly url to upstream
<JEEB>
yea
<JEEB>
upstream_pusher apparently is the writable upstream for me :D
King_DuckZ has joined #ffmpeg-devel
<King_DuckZ>
hey all, any devs around? I'm trying to fix a playback problem and I'd like to ask some questions, it's about libavformat/udp.c
<JEEB>
just ask
<King_DuckZ>
lol
<King_DuckZ>
so in udp.c:525, testing on a stream with errors, if overrun_nonfatal==1 I get loads and loads of errors and playback doesn't resume, I replaced continue with av_fifo_reset2(s->fifo) and the behaviour is better now but I still get thousands of messages logged from that if branch
<King_DuckZ>
line 523
<JEEB>
overrun_nonfatal is something that usually means that you need to improve something else
<JEEB>
either make your buffers larger or make processing go faster etc
<King_DuckZ>
I don't know if I'm clearing the buffer the right way, but what I really suspect is that the consumer is stuck trying to decode something pointless and the buffer keeps filling up
<King_DuckZ>
also idk if my git history is correct but I see the av_fifo_write(.... line is much newer than the if block and I wonder if they ever tested the broken udp stream case when they modifid that code?
<JEEB>
anyways, just saying that while 9000 places on the internet will tell you to utilize that option, it actually is meh. it usually just hides your underlying problem
<JEEB>
and yea, it's possible there is a boog in that logic
<King_DuckZ>
JEEB: I'm working on an embedded system that has to stay up even if stream is damaged, right now it just stops playing (else branch)
<ramiro>
JEEB: Lynne: I always have a "myfork" remote, and I only push to that. the repo with my ffmpeg key is in a separate computer, just to be extra sure...
<JEEB>
King_DuckZ: but that option doesn't really have much to do with damage
<ramiro>
(and I still managed to push the wrong patchset without the last few fixes :P)
<JEEB>
it is just "whatever is reading this thing is not doing it quickly enough, so we drop stuff to keep the buffer around"
<JEEB>
also, with mpegts you most definitely want to enable dropping corrupted packets
<JEEB>
since that is a feature
<JEEB>
I have no idea why that is not the default but that way such data does not enter the decoder
<King_DuckZ>
thanks for confirming my suspicions :) and would you be able to point me to the possible consumer that's currently being slow? the guy being notidied by that conditional variable?
<JEEB>
I think only AVI and MPEG-TS set that corrupt flag currently
<King_DuckZ>
a-ha, thanks, let me try again with this new info at hand
<King_DuckZ>
it is mpeg-ts that we're playing back afaict
<JEEB>
ah, I actually see that there is more stuff now if I look for AV_PKT_FLAG_CORRUPT
<JEEB>
anyways, that udp proto logic might indeed have a boog, but I just had to get it out first that while the interwebs will tell you that overrun_nonfatal is good, it generally... is not. it just means that something further down the line in an API client (such as ffmpeg cli) should be profiled first, what is the thing causing slowness down the line
<JEEB>
and since dropping data leads to corruption of input, you're not only getting any possible issues in the input, but also your own funzies
<JEEB>
generally adjusting the buffer sizes for the UDP reading etc helps with making it more stable with the post-performance possibly fluctuating
<King_DuckZ>
it seems to be a veeeery urgently needed bugfix over here, so what I'm thinking is to buy some time with the fix I described above while I research what you're describing
<King_DuckZ>
we do have a tiny buffer, from what I heard but we don't have loads of ram available either
<King_DuckZ>
I'm going to try with your flag if it's not being used yet, afterwards I'll check if the consumer is choking for no reason on stupid data
<JEEB>
yea, there's absolutely no reason to feed known invalid packets to decoders (in general)
<King_DuckZ>
it's kinda new code for me as well so trying to learn my way around
Krowl has quit [Quit: Krowl]
paulk has quit [Ping timeout: 244 seconds]
Krowl has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
ngaullier has quit [Read error: Connection reset by peer]
<King_DuckZ>
JEEB: do you know if that AV_PKT_FLAG_CORRUPT flag will cause partially recoverable frames to be discarded? apparently displaying something broken rather than black is one of our requirements
jarthur has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 252 seconds]
<JEEB>
King_DuckZ: whether it's recoverable or not is really not something you can know, and in general things do stuff like outputting the previous decoded frame etc. given that any random corruption in a UDP source can cause things to go barf long-term (I have experience in getting nightly corruption from source which would then break the H.264 decoder's internal state forever until you re-initialize it)
<JEEB>
thus I don't consider losing a single packet (which is what that stuff mostly is) a problem
<King_DuckZ>
thanks for the info! I've been looking around, I think libavformat/mpegts.c:1025 sets it automatically?
<King_DuckZ>
I am getting that PES packet size mismatch warning printed out, so it should be setting the flag too
<King_DuckZ>
I also get into libavformat/demux.c:576, it looks all good to me
MrZeus has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
MrZeus_ has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 252 seconds]
witchymary has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
jarthur has quit [Quit: jarthur]
jarthur has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
IndecisiveTurtle has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (lithium.libera.chat (Nickname regained by services))]
Krowl has quit [Read error: Connection reset by peer]