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
Everything has quit [Quit: leaving]
Everything has joined #ffmpeg-devel
cone-947 has quit [Quit: transmission timeout]
quietvoid has quit []
quietvoid has joined #ffmpeg-devel
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 244 seconds]
arch1t3cht0 is now known as arch1t3cht
mkver has quit [Ping timeout: 276 seconds]
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
Everything has quit [Quit: leaving]
iive has quit [Quit: They came for me...]
MrZeus__ has quit [Ping timeout: 245 seconds]
System_Error has quit [Remote host closed the connection]
^Neo has quit [Ping timeout: 252 seconds]
System_Error has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
jamrial has quit []
^Neo has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
LaserEyess has quit [Ping timeout: 252 seconds]
jkhsjdhjs has quit [Ping timeout: 272 seconds]
Sean_McG has quit [Quit: leaving]
compnnn has quit [Remote host closed the connection]
compnnn has joined #ffmpeg-devel
cone-484 has joined #ffmpeg-devel
<cone-484>
ffmpeg Sean McGovern master:710481806657: libavcodec: various: remove empty directories originally for legacy DSP code
<compnnn>
another|, i find that people are the same in real life as they are on the mailing list. at least all of the devs that i met have had similar to ml attitudes and behaviors
<another|>
Okay? And?
<compnnn>
i dont see it being productive to meet in real life vs over the internet. a lot of people have invited michael over the years to various events
<compnnn>
but thats just my opinion
<compnnn>
i know there are a bunch of people who say it is productive to meet in person
<another|>
Alright. I disagree.
<elenril>
compnnn: so why exactly did you come to vdd then?
<compnnn>
i met with quite a few new faces who were very nice to talk with.
<Marth64>
I think some face time is productive to team building. It doesn't have to be physical. A teleconference for example. It would be interesting to meet you all
<compnnn>
it was really interesting seeing other projects who arent calling for each others heads every other mail
MisterMinister has quit [Ping timeout: 245 seconds]
<Marth64>
Email is also a "serious" speaking platform I feel its easier to get heated and drag things out. with IM or voice you can hash thoughts out in real time
<compnnn>
you should go to some events Marth64 , you would probably enjoy it
<compnnn>
i dont know what part of the world you are in, but there are events all over europe, i saw gstreamer does an event each year too
<compnnn>
elenril, you were at vdd this year ?
<Marth64>
I am in US. I would like to. the int'l travel is hard timing wise but I will try when an opportunity arises
<Lynne>
...why do we have AVERROR_EOF and AVERROR(EOF)
<elenril>
the latter does not exist
<compnnn>
Marth64, there might be a booth at NAB in vegas in april 2025.
<Lynne>
oh... weird, doesn't fail compilation here
<elenril>
huh, there is one instance...
<elenril>
that's a bug
<compnnn>
although its not an open source event haha
<elenril>
....added by me
<elenril>
lol
<elenril>
I blame psychoactive substances
<compnnn>
the best kind of substances.
<Marth64>
compnnn: nice. i saw SCaLE as well in marh
<Marth64>
+c
<elenril>
Marth64: consider fosdem
<Marth64>
hmm...that may actually work
<Marth64>
i will see!
mcfrd has joined #ffmpeg-devel
courmisch has quit [Killed (NickServ (GHOST command used by courmisch_))]
courmisch_ has joined #ffmpeg-devel
mcfrdy has quit [Ping timeout: 260 seconds]
mcfrd is now known as mcfrdy
<JEEB>
compnnn: dunno, for me I've had cases where I've had issues with someone on the ML due to them writing in a style that feels like they are looking down at you, but IRL they were nice to discuss things with. Of course it is each person's decision whether they want to meet in meatspace, but it does have its benefits.
cone-484 has quit [Quit: transmission timeout]
<beastd>
meetings IRL might help. might not. it's not sth that can be demanded for a project with developers around the globe. so it's nice to have possibilities to meet and sometimes it helps the project, but IMHO shouldn't be the core/engine of the project.
<beastd>
it's also unfair to over value those gathering because some people do not enjoy or worse these type of encounters. especially for open source projects i do see no reason for doing so.
<beastd>
having that said i personally would be happy to meet all of you new faces and all others again. not sure my circumstances will allow for it any time soon though...
kasper93 has joined #ffmpeg-devel
<pross>
there does seems to be much discussion lately over trademark, root admin, code of conduct, workflow improvements/("gitlab"), funding bids, departed developers, and project direction.
<JEEB>
I think some of those have been going on for years now, including voice calls during IRL meetings. I think the root stuff has been more starting from the position of "OK, so what's the project infrastructure and who has access to it?". workflow improvements also has been an ongoing for a few yeas now, with people's pain points being queried and solutions proposed.
Krowl has joined #ffmpeg-devel
APic has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
ngaullier has joined #ffmpeg-devel
quietvoid has quit [Ping timeout: 260 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
quietvoid has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
quietvoid has quit [Ping timeout: 252 seconds]
quietvoid has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 248 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
APic has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<Lynne>
I really dislike how the encoding API's receive_packet callback was changed by removing send_frame
<Lynne>
I expressed this when the change was made, but as the only person who actually writes encoders, I'm feeling the pain
<Lynne>
ff_encode_get_frame() + receive_packet does not make for a convenient encoding flow
<elenril>
you can trivially emulate send_frame, no?
<elenril>
while (1) { int ret = ff_encode_get_frame(); if (ret < 0) return ....; ret = send_frame(); }
<Lynne>
I'm having trouble wrapping my head around how it should work when you have an asynchronous encoder
<elenril>
it'd be much hairier to force all receive_packet-based encoders to deal with arbitrary send+receive interleavings
<elenril>
lavc is not asynchronous
<Lynne>
I know, but my encoder is
<elenril>
so you wait
<Lynne>
no, you don't get it
<Lynne>
async as in what comes out isn't what just came in
<JEEB>
in other words, frame delay
<elenril>
you mean it has delay
<Lynne>
yes
<elenril>
that's not async then
<elenril>
if there's no reordering, use a fifo
<Lynne>
I already have all that
<elenril>
so what's the problem?
<Lynne>
my problem is I'm overengineering and I'd like to support a situation in which API users give N amount of frames before calling receive_packet and I'd like to process as many frames as there are queued
<Lynne>
what's ffmpeg.c's behaviour? does it push frames until it fills the queue up, and then call receive_packet?
<JEEB>
I think it tries to see if it can receive something from encoder, and if it cannot it will attempt to feed it more
<JEEB>
but it's been a good while since I last read that logic and I might be mixing it with the filter chain stuff
<Lynne>
get_frame() immediately returns EAGAIN when calling it a second time
<elenril>
API user is supposed to drain all available packets after every send_frame call
<Lynne>
where is the encoder-side documentation (not user side) of receive_packet
<Lynne>
I am allowed to return EAGAIN from it, right?
<elenril>
yes
<fflogger>
[newticket] madsweeney: Ticket #11322 ([undetermined] ffmpeg stops with exit code 0 during input of hls http stream) created https://trac.ffmpeg.org/ticket/11322
<elenril>
what little documentation exists is in codec_internal.h
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 276 seconds]
<Lynne>
I'm not allowed to return EAGAIN during flushing
<elenril>
what would that mean?
<elenril>
EAGAIN means "need more input"
<elenril>
during flushing you know there will be no more input
<Lynne>
call me again? it saves me a while loop
<elenril>
while loops are cheap, complex apis are expensive
<elenril>
I just saw a pile of vintage while loops in taipei
<Lynne>
me too, in shimokitazawa
<elenril>
should have bought some
<Lynne>
is it legal to access atomic_ints as regular ints if the code you're using them in is never going to be threaded?
jamrial has joined #ffmpeg-devel
<elenril>
I don't think so
System_Error has quit [Ping timeout: 260 seconds]
vjaquez has quit [Ping timeout: 246 seconds]
vjaquez has joined #ffmpeg-devel
Workl has quit [Ping timeout: 248 seconds]
Krowl has joined #ffmpeg-devel
<Lynne>
why is get_frame() so awful to use?
<Lynne>
the docs say that it'll return EAGAIN if there are no frames left
<Lynne>
but what you have to do is you have to call the function, and immediately return EAGAIN from the encoding function otherwise it'll error out with ENOMEM
keith has quit [Remote host closed the connection]
<Lynne>
so you have to make receive_packet fully restartable and get back to where you used to be
keith has joined #ffmpeg-devel
<Lynne>
err, nevermind, my fault
System_Error has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
av500 has quit [Remote host closed the connection]
vjaquez has quit [Ping timeout: 260 seconds]
vjaquez has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
av500 has joined #ffmpeg-devel
<Lynne>
well, all my experiments failed
cone-903 has joined #ffmpeg-devel
<cone-903>
ffmpeg Lynne master:7c52dda55f13: hwcontext_vulkan: add support for AV_PIX_FMT_GBRP12/14/16
<cone-903>
ffmpeg Lynne master:cf0961a52707: hwcontext_vulkan: require storage properties to claim formats as supported
<cone-903>
ffmpeg Lynne master:f65e51293aed: hwcontext_vulkan: add support for AV_PIX_FMT_GBRAP10/12/14
<cone-903>
ffmpeg Lynne master:08fb505a6663: hwcontext_vulkan: add support for AV_PIX_FMT_GRAY10/12/14
<cone-903>
ffmpeg Lynne master:d48542023725: hwcontext_vulkan: take disable_multiplane into account when checking for formats
<cone-903>
ffmpeg Lynne master:8ac49ae9e0fa: vulkan: add opaque field to execution contexts
<cone-903>
ffmpeg Lynne master:f582de8f343d: vulkan: only apply shortcut for next context selection if selection has a submission
<cone-903>
ffmpeg Lynne master:86e552506dbe: vulkan: zero out AVBufferRef in case of failure
<cone-903>
ffmpeg Lynne master:ce8a070cf39d: vulkan: only wait for fences on uninit if the context had a submission
<cone-903>
ffmpeg Lynne master:4fefc6e80c21: ffv1enc_vulkan: remove arbitrary limitation of the number of slices
<cone-903>
ffmpeg Lynne master:d8f301cdf263: ffv1enc_vulkan: switch to receive_packet
<Lynne>
yeah, that doesn't work so well since packet buffer sizes are about 4GiB for each frame, and packets get ref'd in muxing for reordering purposes
<elenril>
surely your gpu has at least 128GB of memory
<Lynne>
48GiB
<elenril>
2007 called
<Lynne>
most of that memory isn't used either, its only 4GiB because of what-if the input compresses improbably badly
<jamrial>
in 40bd6d83557 i bumped micro because i figured api users would like to know when the descriptor changed, so how to handle backporting it? (and the other commits that are part of the same fix)
<jamrial>
do i bump micro in 7.1 too, since its minor version is exclusive to the release?
<Lynne>
vulkan has a feature called sparse binding where you can glue memory together to make a single contiguous buffer
<Lynne>
wanted to try that too, but its a lot of annoyance, and at the end, you still have to memcpy each slice
<elenril>
i thought modern gpus have fullblown mmus
<elenril>
jamrial: probably?
<jamrial>
ok
<jamrial>
haasn: did you look at the memleak?
<Lynne>
elenril: yup, they do
<haasn>
jamrial: oh, not yet
<Lynne>
though AMD's software folks are still thinking they don't, but their hardware has an MMU, so what happens is a single incorrect access and you need to reboot your entire system
<haasn>
still trying to find an elegant way to do the tone mapping without three million LUTs
<elenril>
surely the kernel drivers are ensuring all accesses are correct
<elenril>
I have full confidence in the quality of amd drivers
<haasn>
jamrial: oh, I realize what's causing it
<haasn>
it's a bit stupid
<haasn>
will fix
esu has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
<fflogger>
[newticket] realies: Ticket #11323 ([avfilter] soxr resampler assertion failure with precision>=30 and specific duration values) created https://trac.ffmpeg.org/ticket/11323
<realies>
^ is this o-k, JEEB?
<realies>
actually, it's not, the minimal failing case passes... 🤦
<realies>
i'm stupid, can i edit the ticket?
<realies>
ok, fixed (i hope)
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
Kei_N has quit [Ping timeout: 244 seconds]
Kei_N has joined #ffmpeg-devel
cone-903 has quit [Quit: transmission timeout]
Kei_N has quit [Ping timeout: 252 seconds]
Kei_N has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 252 seconds]
Kei_N has joined #ffmpeg-devel
tufei has joined #ffmpeg-devel
feiw has quit [Remote host closed the connection]
feiw has joined #ffmpeg-devel
tufei has quit [Ping timeout: 260 seconds]
courmisch_ has quit [Quit: Reconnecting]
courmisch has joined #ffmpeg-devel
tufei has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 255 seconds]
beastd|2 has joined #ffmpeg-devel
beastd has quit [Ping timeout: 252 seconds]
<courmisch>
Using the authority argument against NG. Priceless.
<BBB>
hm... I really don't like these discussions anymore
<BBB>
wold it be possible for everyone to take a chill pill and pause for 24hrs on these discussions?
feiw has quit [Remote host closed the connection]
haihao_ has quit [Read error: Connection reset by peer]
feiw has joined #ffmpeg-devel
haihao has joined #ffmpeg-devel
<ePirat>
BBB, imho there should be votes organized on the topics proposed at the VDD ffmpeg meeting eventually as some of these discussion might anyway be pointless depending on their outcome…
<courmisch>
It wouldn't be fair to say that you reap what you saw because it's not your fault. But you get what you should have expected.
<courmisch>
At some point, people need to come to terms with reality.
<BBB>
I don't mind people organizing votes, or people discussing libpostproc or anything else
<courmisch>
ePirat: playing devil's advocate, but if I were Fabrice, I wouldn't redelegate away from Mini. Who would he trust instead and how? Plus it would be an admission that he would have poke the wrong person.
<BBB>
it's just that the currently active mailinglist threads are neither of these, and they are quite heated
<BBB>
I don't think they are healthy
<courmisch>
Thank you captain obvious. My point is that this was to be expected, and this is to be expected in the future.
<courmisch>
Same causes lead to same consequences and all that
<ePirat>
barely any discussion we have on the ML feels healthy at least after some number of mails it tends to go south quickly…
<ePirat>
I dont even feel like it makes sense to get involved because in the end it feels all pointless anyway and nothing ever changes here
<courmisch>
And I bet you that it will happen again in early February because surely someone will raise one of The Topics at FOSDEM
<ePirat>
Also to everyone wondering about the lack of newcomers to the project, just read a few of the ML threads and you have the answer… (If newcomers even get as far as to subscribe to the list…)
<ePirat>
why would anyone want any of this in their free time
<courmisch>
Nah. I really don't think the ML tonality affects newcomers. More like it makes people not stay than not join
tufei_ has joined #ffmpeg-devel
<Marth64>
I see it as built up historical grievences which are not my battle to get into. thus possible to mute mentally
tufei has quit [Ping timeout: 260 seconds]
___nick___ has joined #ffmpeg-devel
beastd|2 is now known as beastd
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #ffmpeg-devel
tufei_ has quit [Quit: Leaving]
tufei has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<compnnn>
BBB, i dont think anything will change after 24 hours, i hope you guys can think up a plan past that.
<compnnn>
i'm not criticizing but planning.
<compnnn>
my idea > all non code stuff goes on another mailing list.
<compnnn>
not sure its even a good idea, its just an idea
<compnnn>
or rather other people have suggested it too, so its not my idea
<compnnn>
that wont get rid of the hostilities but it will at least get them away from new developers.
tufei has quit [Quit: Leaving]
___nick___ has quit [Ping timeout: 252 seconds]
<steven-netint>
as a new developer of 1 week I already feel dread toward submitting to code maintained by some people I saw in the CoC thread haha
___nick___ has joined #ffmpeg-devel
<steven-netint>
But, as ePirat mentioned. ML was a large impediment for me too. ML and IRC are beyond my generation
<compnnn>
steven-netint, which development suite do you like best ? just asking for future options we can switch to
<steven-netint>
Discord. If i could use an upsidedown smile emoji here I would
<compnnn>
maybe dev suite is wrong word, but patch / collaboration system
<compnnn>
discord :D
<compnnn>
i think we can make a discord irc bridge
<steven-netint>
I do see benefits to older system like this. Its for lack of a better word: gatekeeping inane stuff out
<fflogger>
[editedticket] whiteboxsolutions: Ticket #11118 ([ffprobe] segfault when using ffprobe parse ts file on the host whose linux kernel is 6.8.0 and glibc is 2.39) updated https://trac.ffmpeg.org/ticket/11118#comment:2
<BBB>
compnnn: right, I think for the libpostproc thread, I suggested we curtail taht to libpostproc planning only
<steven-netint>
perhaps as some have already suggested, separating some of the topics in ML so not everyone sees the admin/political stuff will be better able to focus devs on development
<BBB>
perhaps, yes
<ePirat>
I hope we can eventually explore something like GitLab, Forgejo or similar
<ePirat>
especially with patchwork being even more unusable than it used to be
<compnnn>
BBB, i think that thread had ended. a few devs reject michael getting paid to split and maintain libpostproc and michael says fine. (i could be wrong)
<compnnn>
has already ended*
<steven-netint>
while i feel discord is preferable to irc. The ML may be better replaced with gitlab. I feel I need to read a guide on how to parse inline replies
Raz-- has joined #ffmpeg-devel
Raz- has quit [Ping timeout: 252 seconds]
<compnnn>
steven-netint, it might depend on your email client showing or hiding the previous message
<compnnn>
are you using gmail or other ?
<steven-netint>
outlook. I'm that 'corpo interest' thing
<ePirat>
I switched to a different mail client so I could easier work with MLs and also because the other one was struggling handling the 100k mails I have accumulated by now
<compnnn>
haha i forgot outlook. because its outlook 365 or whatever now.
<steven-netint>
oh, thank you. I saw that in the ffmpeg.org ML setup guide.
<JEEB>
steven-netint: as a channel based instant messaging thing that isn't based on a single company IRC more or less still works (and new people can utilize irccloud etc so they get a nice app for it etc), the ML usually is the less easy to get into part of FFmpeg
<steven-netint>
my issues are just that my brain is not used to reading the multi-indent >>> yet
<JEEB>
matrix is the other open source thing that people link with IRC nowadays, but I'm not too interested yet in running my own instance for that :D
<steven-netint>
I understand not wanting to be be beholden to Discord. IRC works. Though perhaps for younger devs it would be nice to have a IRC client preset which: connects to ffmpeg irc, presents some buttons for switching between the ffmpeg channels, setups desktop notif for user name mentions, disables the 'user disconect' messages
<ePirat>
I tried Matrix a few times over the last years and was very underwhelmed
<JEEB>
I recommend checking how irccloud looks for a more modern take on a client
<JEEB>
or if you want a locally running one, quassel maybe?
<ePirat>
oh quassel, old memories
<JEEB>
(see how I am not recommending irssi or weechat inside tmux, as that's limited to masochists who like ssh)
<steven-netint>
irccloud looks neat. Thanks
<ePirat>
JEEB, or senpai
<frankplow>
Or you can self-host a bouncer like znc
<JEEB>
ePirat: *double-blink* at that name
<BBB>
I use znc, it's ok
<ePirat>
I dont think setting up ZNC is anything trivial for people new to IRL
<ePirat>
*IRC…
<compnnn>
irc isnt required for ffmpeg development either. i hope no one claimed it to be...
<JEEB>
no-one did
<compnnn>
many developers just drop patches on the ml and bounce :D
<frankplow>
ePirat: It’s pretty easy, it’s all configured through a web interface. But yes, probably the most technical of the options.
<ePirat>
frankplow, I wouldn't really call the web interface "easy" :D
<Marth64>
Libera has a web interface
<Marth64>
I submitted a patch to fix the link in the docs
<JEEB>
yeh
System_Error has quit [Remote host closed the connection]
<ePirat>
frankplow, not saying its terrible, I am using ZNC myself.
<Marth64>
But there is an awkwardness with guests logging in through web UI. #ffmpeg has IRC mode to block users not registered with NickServ whereas thisone does not
<Marth64>
last I checked
<Marth64>
so I can see someone new to IRC being confused
<ePirat>
oh yeah might be that we still have that from when that spam wave was hitting Libera
<JEEB>
yea
<Marth64>
mode +r
<JEEB>
but I must say that personally I find IRC -devel to be a good communication space :P I generally feel that in various cases one is less likely to get a non-productive response here than on the ML, and I think across the years many people including me have helped people forwards with their first contribution here.
<iive>
BtbN, I thought firefox checks if there is a system ffmpeg/libav* and uses it for software fallback, They usually ship with their own copy with different name libmozav*
<BtbN>
For not HEVC for sure
<BtbN>
not sure about HEVC
<JEEB>
it does that for H.264
<JEEB>
and AAC I think
<BtbN>
they might just want to stay clear of the patent minefield that HEVC is
<BtbN>
and when only using hwdec, the hardware vendor already paid
<JEEB>
to my knowledge they only added hwdec related stuff
<JEEB>
on windows for H.264 swdec they utilize Media Foundation, I think. so that would have also been a possibility since it's an OS media API. but I bet it's just "simpler" in risk mitigation terms to do it similarly to Chromium and go the hwdec route
<jamrial>
they could use media founddation to get it playing if you bought the hevc decoder app from the ms store, right?
<BtbN>
You do need to buy that, or download the "HW vendor supplied" one to get FF working, yeah
<BtbN>
so it probably is MF?
<iive>
but my point is that the system ffmpeg is coming from the OS/distro. It's not distributed by Firefox. Legally it's the same as using hw decoding.
<iive>
Then the question is if the distro version has HEVC.
<BtbN>
Gotta convince lawyers and judges about that though
<JEEB>
yes/no/maybe. with H.264 they were OK with taking that chance
___nick___ has quit [Ping timeout: 276 seconds]
<iive>
iirc for h264 they decided to not enforce any patents for decoders.
<JEEB>
uhh, I don't recall that. neither from MPEG-LA nor Nokia (or any other entity that claims that they have something to license)
<JEEB>
but thankfully for H.264 we've hit 20 years since 2003 ed with main profile, so hopefully at some point soon(tm) relevant patents will be out
<JEEB>
and high profile was 2005 ed
<JEEB>
(8x8 dct etc)
<JEEB>
also 10bit profiles were 2005 ed I think?
<iive>
i think i've seen a claim that half of the h264 patents have already expired.
<JEEB>
that would not surprise me
System_Error has quit [Remote host closed the connection]
<iive>
that's what I ware remembering (Wikipedia article - Advanced Video Coding) "MPEG LA has allowed the free use of H.264 technologies for streaming Internet video that is free to end users".
<JEEB>
that usually was taken to mean that service providers don't need to pay to provide H.264 content
<JEEB>
but IANAL as usual
<JEEB>
what fedora and firefox utilize is the fact that cisco is already paying for royalties for distributing decoders and encoders, so they distribute known-signed binary builds of openh264
<JEEB>
technically it's thus cisco distributing it -> no royalties for red hat/mozilla
<JEEB>
that max royalty limit got upped a lot after H.264 so this sort of setup is highly unlikely to happen with HEVC or later
<iive>
I think that cisco codec is main profile only, but it might have encoding (for video chat).
<JEEB>
decoding wise I think high profile got contributed
<iive>
but the point of streaming exception is that if end user programs need to deal with patents, they might avoid the format altogether.
System_Error has joined #ffmpeg-devel
<iive>
so they allowed the decoding (by end user) for free and collected on the service providers (encoding)
<JEEB>
uhh, I'm pretty sure that is not the case that they waived decoder/encoder distribution. they waived service provider side of things is the interpretation I've always had of that
<iive>
Google does a lot of encoding, that's why they needed a free alternative.
<JEEB>
which is what one of the patent pools then reversed with HEVC, and that then led to creation of AOM
<JEEB>
(not that the other changes to licensing terms were nice either)
<JEEB>
the internet broadcast avc video bit is for content delivery
<JEEB>
that is why the whole "someone who already pays max binary distribution royalties distributes binaries" thing happened
<JEEB>
which is why google distributes a H.264 decoder with chrome, and why openh264 is utilized for webrtc in firefox and as a general library for fedora
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
kurufu has quit [Read error: Connection reset by peer]
kurufu has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: Did a re-rebase again on latest master, seems you fixed the byteswap bug I had nice. Now only function left that doesnt seem to work with common header is flush_put_bits()
<IndecisiveTurtle>
I'm not sure but I think there is an off-by-one error in the to_write calculation? If shader wrote exactly 16 bits before calling it, it should just write 2 bytes but it will write 3 cause it does + 1. This isn't what causes issue in my case so Im not sure if its actually a problem
mkver has quit [Ping timeout: 260 seconds]
<Lynne>
IndecisiveTurtle: its possible its wrong
<Lynne>
what happens if you check how many bits were written and not add +1 if its mod-8??