[Ffmpeg-devel-irc] ffmpeg-devel.log.20190816

[burek]

[00:04:03 CEST] <Compnn> Lynne, i ask because its strange to just have some new dev show up and insult other developers within the same project
[00:17:26 CEST] <tmm1> is there any place ffmpeg does runtime checking to see if NEON is available
[00:21:40 CEST] <mkver> tmm1: ff_h264dsp_init_arm
[00:22:11 CEST] <mkver> git grep have_neon turns up lots of matches.
[00:23:36 CEST] <tmm1> ah cool, i missed the lowercase define
[00:23:36 CEST] <tmm1> thank you
[00:33:52 CEST] <nevcairiel> jamrial: the special thing about truehd is that frames are sub 1ms in length, which can screw players up if they are careless with their timings
[00:34:03 CEST] <nevcairiel> (they typically are 0.8333ms)
[00:45:39 CEST] <Lynne> Compnn: what, you too want to question my amount of git commits?
[00:47:48 CEST] <durandal_1707> ah, i always forget that mplayer dev...
[00:49:44 CEST] <durandal_1707> bunch of mplayer devs, doing nothing but complains
[01:38:22 CEST] <jamrial> nevcairiel: could be that. i'm getting a lot of stutter with ffplay, but not with other players like mpc-hc
[06:34:09 CEST] <Kevin43> Hi...is this just like a chatroom?  I'm interested in potentially contributing.  Got here from the trac page for GSoC
[06:39:57 CEST] <BradleyS> Kevin43: yes, but most people are probably sleeping now
[06:40:27 CEST] <BradleyS> europe will be awake in 5-6 hours roughly
[06:41:14 CEST] <philipl> BtbN: I don't think h.263 works with nvdec, even now.
[06:41:25 CEST] <BradleyS> if you're interested in submitting patches, see the mailing list http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[06:41:36 CEST] <philipl> I get some weird errors with the samples I have (generated by an old nokia 10+ years ago)
[06:47:12 CEST] <Kevin43> thanks BradleyS, I will check that out.  You got any other tips for getting familiar with ffmpeg besides working through the code?
[06:47:54 CEST] <BradleyS> i'm probably the wrong person to ask but when people are around, i'm sure someone can help you
[06:50:14 CEST] <Kevin43> (y)  thanks!
[07:06:14 CEST] <Compnn> Lynne,  just curious who you are. dont care about your commits
[07:07:05 CEST] <Compnn> Kevin43, what part of ffmpeg are you interested in?
[07:07:53 CEST] <Compnn> Kevin43,  most people just work on what interests them the most. some people like audio tech so they work on codecs. other people like to optimize code. others enjoy reverse engineering
[07:09:07 CEST] <Compnn> Kevin43,  what are you doing awake at 4am heh
[07:11:02 CEST] <Kevin43> Compnn I've pretty much only used ffmpeg for cutting video.  I was having issues cutting video at timestamps between keyframs without reencoding, and I saw a comment somewhere saying that it wasn't possible?  got me thinking about working on it if it's really not implemented
[07:11:24 CEST] <Kevin43> Compnn also, it's only 1 am where I am :P
[07:11:47 CEST] <Compnn> oh :D
[07:13:37 CEST] <TheAMM> Cuts have to be at keyframes though
[07:15:14 CEST] <TheAMM> Unless you're thinking of implementing something that reencodes only the part before the next keyframe and copies the rest
[07:15:35 CEST] <TheAMM> (which sounds a bit messy and afaik you could do without adjustments, although that's a bit messy too)
[07:15:44 CEST] <Kevin43> TheAMM ^This is what I was thinking.  Not sure if that's possible / would even save much time...
[07:17:59 CEST] <TheAMM> It won't be impossible but imo it's fairly niche and it's going to touch the... user experience code in many places for a small thing
[07:18:23 CEST] <TheAMM> Though I'm no expert ffmpeg dev, I only have some local changes
[07:18:56 CEST] <TheAMM> It's worth to take a look at ffmpeg, then you'll know what it looks like and might get other ideas to implement or fix
[07:19:52 CEST] <TheAMM> but if I had to make a partical copy like that, I'd rather experiment with running two commands and then concatenating the encoded new and old data together
[07:21:08 CEST] <TheAMM> AFAIK there's no ffmpeg development primer, if you're working on some new thing look at existing things on how they do the thing (codecs, formats, devices) and read the ffmpeg headers for structs and stuff
[07:22:07 CEST] <Compnn> Kevin43,  what format codec are you cutting
[07:23:47 CEST] <Kevin43> Ah gotcha, TheAMM. Yeah I suppose playing with two commands would probably save a lot of development time...I have been sorta looking for an excuse to get into some sort of open source project so thought I'd at least poke my head around haha
[07:23:52 CEST] <Kevin43> Compnn mp4
[07:24:30 CEST] <Compnn> h264 then ?
[07:25:42 CEST] <Compnn> probably not possible unless its all iframes
[07:26:07 CEST] <Kevin43> sorry, yes h264
[07:32:50 CEST] <Kevin43> hmm...given my limited understanding (wiki just now...), wouldn't iframes = inter frames meaning they're "diff" frames from a recent keyframe?  Wouldn't that mean having all iframes (and 1 keyframe at the beginning?) be the worst case scenario?
[07:33:30 CEST] <JEEB> i is intra usually
[07:36:05 CEST] <JEEB> p/b are inter in classic mpegnspeak
[07:40:45 CEST] <Kevin43> ah, gotcha.  Thanks JEEB.  so doing 'diff' frames for intra uses spatial redundancy instead of temportal.  Hmm. with spatial redundancy, I'm starting to think this isn't possible without reencoding
[07:58:00 CEST] <Compnn> Kevin43, so a h264 frame usually goes ibpbpbpbpppibpbppbpbpi etc
[07:58:03 CEST] <Compnn> the iframe is the keyframe
[08:03:08 CEST] <Compnn> the pbpbpb are all fragments of the keyframe
[08:03:12 CEST] <Compnn> only the motion changes
[08:19:05 CEST] <Compnn> not a problem when keyframes are per 30 frames but maybe 250 between frames, almost 10 secs
[08:28:16 CEST] <Compnn> so you want to cut between keyframes, you have to rebuild the frame from the keyframe ... without reencoding
[08:28:19 CEST] <Compnn> very complicated
[08:28:33 CEST] <Compnn> some would say ... impossible
[08:28:51 CEST] <Compnn> and mp4 is a terrible format :D
[09:39:25 CEST] <kurosu> Kevin43: in >=h264, the coding order of the pictures may differ a lot from the display order. It's doable to cut on a particular frame, but the trailing pictures can cause quite a mess (concatenation of bitstreams/VBV stuff/display)
[09:41:47 CEST] <kurosu> tl;dr: hardly doable, often breaks
[11:34:00 CEST] <_bluez> Hello! I am facing an issue where I have allocated a new frame, called av_image_alloc() on it passing width, height, format and such, and then called av_image_fill_black() on it... but I keep getting a seg fault inside av_image_fill_black :(
[11:34:35 CEST] <_bluez> Does anyone have any idea what the problem could be?
[11:35:22 CEST] <_bluez> I've been at it for 2 days now...
[11:35:37 CEST] <durandal_1707> Lynne: michaelni put transcript on ml, he is good citizen
[11:38:24 CEST] <_bluez> It faults somewhere while accessing the frame->data...
[11:48:59 CEST] <durandal_1707> which pixel format you use?
[11:49:22 CEST] <_bluez> Its YUVJ420p I guess
[11:51:10 CEST] <durandal_1707> whatever you do, you allocate stuff wrong way iirc
[11:51:34 CEST] <_bluez> How to allocate correctly then?
[11:52:06 CEST] <J_Darnley> What does your debugger say?  Is it a null dereference?  Or just out of bounds?  Have you tried asan?
[11:52:25 CEST] <J_Darnley> or valgrind
[11:52:28 CEST] <_bluez> It says cannot access memory at that location
[11:53:54 CEST] <_bluez> i guess its out of bounds
[11:55:03 CEST] <_bluez> no i have never used asan or valgrind
[11:56:30 CEST] <_bluez> my debugger says the fault happens inside __memset_avx2_erms, inside memset_bytes, inside av_image_fill_black
[11:58:33 CEST] <durandal_1707> it should work if you use normal pointers to image alloc
[11:58:54 CEST] <durandal_1707> not sure if you pass avframe ones
[11:59:19 CEST] <durandal_1707> avframe data is reference counted
[11:59:39 CEST] <durandal_1707> at least inside libs
[12:01:08 CEST] <_bluez> how do i allocate avframe data then? I tried also using av_frame_get_buffer, same issue
[12:03:00 CEST] <durandal_1707> can you show actual codr?
[12:08:02 CEST] <durandal_1707> make sure Avframe is pointer on stack and not full on stack
[12:08:28 CEST] <_bluez> https://pastebin.com/NLdvRKaU
[12:08:39 CEST] <_bluez> Here is a portion of the code
[12:09:15 CEST] <_bluez> durandal_1707: what do you mean by not "full on stack".. can u explain a bit?
[12:13:41 CEST] <durandal_1707> you can not cast int to ptrdiff
[12:14:26 CEST] <_bluez> but it says incompatible pointers
[12:14:30 CEST] <durandal_1707> at least not on 64bit
[12:14:42 CEST] <_bluez> should i cast it to const long * ??
[12:14:58 CEST] <durandal_1707> cadt can not fix incompatible pointers
[12:15:10 CEST] <durandal_1707> *cast
[12:15:28 CEST] <durandal_1707> this is basic programming
[12:16:49 CEST] <_bluez> oh sry.. but the avframe linesize is int* i guess...how do i get around it then?
[12:16:52 CEST] <nevcairiel> you cant really cast arrays like that, you'll need to make a new one in the proper type and copy the values over
[12:17:10 CEST] <durandal_1707> yes what nev said
[12:18:37 CEST] <_bluez> isn't there a function I can use to simply allocate frame buffers and then fill black??
[12:19:15 CEST] <durandal_1707> yes what you already use
[12:19:45 CEST] <durandal_1707> and i think stuff is initialized already upon allocation
[12:20:20 CEST] <durandal_1707> so no need for fill black, assuming you will copy other data over
[12:20:49 CEST] <_bluez> oh.. okay then
[12:21:03 CEST] <J_Darnley> Isn't filling with black usually an extra step the user must take?waste
[12:22:31 CEST] <durandal_1707> not any more, its zeroed iirc, but that may not be same as black
[12:22:33 CEST] <_bluez> also if you can look at the code... even removing the fill black... i get segfault while copying data from tiles into the frame after certain amount of iterations... it led me to think if there was some fault in frame buffer allocation
[12:23:21 CEST] <_bluez> Cuz the code seems to be correct...
[12:25:56 CEST] <_bluez> Can you please look into it once?
[12:28:07 CEST] <durandal_1707> make sure you use same format for copy
[12:28:36 CEST] <_bluez> yes i am using the same format
[12:29:17 CEST] <_bluez> I did, frame->format = tile->format
[12:33:05 CEST] <durandal_1707> same  issue for linesize like for copy?
[12:33:21 CEST] <durandal_1707> you used cast again?
[12:33:45 CEST] <_bluez> no no I did not have to cast it
[12:34:11 CEST] <_bluez> You can look at the loop where I copy data from tiles into the frame
[12:34:55 CEST] <J_Darnley> If it's 420, you need different widths and heights per plane
[12:36:21 CEST] <J_Darnley> currently it looks like one fixed value for all planes
[12:36:31 CEST] <_bluez> oh i see... will the widht be same as tile->linesize[plane]?
[12:37:43 CEST] <durandal_1707> no
[12:37:55 CEST] <J_Darnley> That is the stride, not the width.  It will include padding.
[12:38:34 CEST] <_bluez> ohh.. how do i get the variable width and height for each plane then?
[12:39:05 CEST] <_bluez> I saw similar code in the vf_tile, and it wasn't done there i guess...
[12:39:15 CEST] <J_Darnley> The pixel format will give you all the details of the planes.
[12:41:27 CEST] <J_Darnley> Sorry that should be "AVPixFmtDescriptor":vs
[12:41:59 CEST] <J_Darnley> Use av_pix_fmt_desc_get() to get it from the enum AVPixelFormat
[12:43:15 CEST] <_bluez> sorry i am a bit confused... what info do i get from the fmtdescriptor? And where in the loop should i make the changes?
[12:43:49 CEST] <J_Darnley> In the paste, line 81, the height needs to be half for 420
[12:44:12 CEST] <J_Darnley> line 82, the width
[12:44:25 CEST] <J_Darnley> The chroma planes are half height and half width
[12:44:32 CEST] <_bluez> oh i get it
[12:45:01 CEST] <_bluez> so those values only for plane 1 and 2 right? Plane 0 has full height and width?
[12:45:33 CEST] <J_Darnley> The format descriptor has log2_chroma_w and log2_chroma_h fields
[12:45:49 CEST] <J_Darnley> yes
[12:46:19 CEST] <_bluez> okay... thanx a lot!!!
[12:46:41 CEST] <_bluez> how do i use log2_chroma_w/h ?
[12:48:27 CEST] <J_Darnley> Read libavutil/pixdesc.h "Amount to shift the luma width right to find the chroma width."
[12:52:29 CEST] <_bluez> okay i will.. thanks again!
[14:30:47 CEST] <durandal_1707> michaelni: subscribe me to security ml
[14:36:07 CEST] <thardin> is porting the mxf imx patch to 4.1 and 4.2 ok?
[14:36:15 CEST] <thardin> ping michaelni I guess
[14:36:17 CEST] <durandal_1707> no
[14:36:42 CEST] <durandal_1707> features are never backported
[14:37:06 CEST] <durandal_1707> only fixes for already available features
[14:40:29 CEST] <durandal_1707> write this somewhere so you do not ask again same questions, this is also developer policy
[14:53:34 CEST] <thardin> I know, but this is more a case of a feature having stopped working. or wait.. it's only broken i master
[14:53:41 CEST] <thardin> in
[14:54:07 CEST] <BtbN> regression fixes are backported, but yeah, only if the regression is actually in the release
[15:00:01 CEST] <thardin> after that I'm going to investigate if the legacy cinepak decoders are fine with some simple but effective optimizations I have in mind
[15:00:15 CEST] <thardin> for that ~cutting edge~ performance
[15:24:36 CEST] <Lynne> michaelni: you're an asshole
[15:25:41 CEST] <Lynne> I did provide criticism, and yet your default response is that I am aggressive and doing an ad hominem attack
[15:27:21 CEST] <Lynne> you haven't paid a single piece of attention to anything I've ever said and are always looking around to dodge facts and twist the discussion
[15:27:34 CEST] <Lynne> like bringing up undefined behaviour in timeouts
[15:27:59 CEST] <Lynne> and you always go with your bullshit rhetoric of "why can't all of us cooperate"
[15:28:25 CEST] <Lynne> how do you expect anyone to cooperate when you and nicolas refuse to listen?
[15:29:17 CEST] <Lynne> your behaviour in the first place is what I find most insulting and aggressive
[15:34:01 CEST] <jamrial> Lynne: your first line invalidates anything after it
[15:38:09 CEST] <kierank> something something code of conduct
[15:39:19 CEST] <jamrial> yes, just with the stuff michaelni quoted in this morning's email plus the above he should be kicked
[15:42:49 CEST] <jamrial> none of this stuff is justified. a bunch of one-line patches shouldn't devolve into this
[15:43:41 CEST] <thardin> durandal_1707: just confirmed that they are regressions in 4.1 and 4.2 compared to 4.0.1
[15:46:05 CEST] <durandal_1707> no, if you kick him i go to
[15:46:49 CEST] <durandal_1707> than you must comply with agpl code of all around codebase
[15:48:01 CEST] <jamrial> durandal_1707: you're ok with people throwing insults around?
[15:48:32 CEST] <kierank> like carl does?
[15:48:37 CEST] <kierank> is it ok when carl does it?
[15:49:03 CEST] <jamrial> kierank: i'm sure you remember i was one of the people that supported the vote to ban carl
[15:49:30 CEST] <kierank> I don't blame durandal_1707 and Lynne, they are clearly at the end of their tether
[15:50:16 CEST] <jamrial> and as i sadi, there's zero justification for it
[15:50:33 CEST] <kierank> not true, their objections to patches are just ignored
[15:50:37 CEST] <kierank> and changes are bullied through
[15:51:24 CEST] <jamrial> you don't insult people when you think they are not looking because you think you're being ignored
[15:51:46 CEST] <kierank> I don't agree with it but it has been months and months of this
[15:51:49 CEST] <kierank> they are human
[15:52:35 CEST] <durandal_1707> they have obviously unlimited time and resources to do their work and ignore others
[15:54:56 CEST] <jamrial> i am also human, this project has given me a fair share of stress and still does, yet you don't see me throw spite and insults around
[15:55:03 CEST] <durandal_1707> there is no need for insults at all, they appears to just easy up their situation
[15:55:24 CEST] <jamrial> and for someone that joined a few months ago, he sure ran out of patience fast
[15:55:41 CEST] <jamrial> durandal_1707: at least we agree that insults only make things worse
[15:56:40 CEST] <kierank> durandal_1707: I think we should ban fuzz patches unless agreed via technical committe
[15:56:48 CEST] <BradleyS> is there any current effort toward a formal governance model with a voting council
[15:57:08 CEST] <durandal_1707> it is one big chaos
[15:58:24 CEST] <durandal_1707> some obvious patches are ok
[15:59:01 CEST] <durandal_1707> but you need to pick them between less useful ones
[15:59:19 CEST] <BtbN> fuzzing simply should not go to the security ML
[15:59:25 CEST] <BtbN> most of that stuff is not critical
[15:59:34 CEST] <BtbN> Make a dedicated, public ML for it
[16:01:00 CEST] <durandal_1707> and what about decoders  and  skip frames- making something vfr when it is cfr
[16:01:39 CEST] <BradleyS> thefuzz at ffmpeg.org
[16:01:53 CEST] <durandal_1707> justification that it allows easy DOS is unrealistic to me
[16:02:21 CEST] <jamrial> durandal_1707: suggest an user settable option/flag to choose between the two
[16:02:43 CEST] <jamrial> default to vfr since it's faster and the output will be the same, but can be changed to cfr behavior
[16:03:38 CEST] <durandal_1707> no, that contradicts with decoder specification and compatibility
[16:03:43 CEST] <BtbN> I'm also still confused about the -safe 0 of the concat demuxer
[16:03:46 CEST] <thardin> DOS is already an issue with any kind of thing that takes random files from the internets
[16:03:53 CEST] <kierank> 15:03:47 <thardin> DOS is already an issue with any kind of thing that takes random files from the internets
[16:03:54 CEST] <kierank> this
[16:04:01 CEST] <durandal_1707> i think this was discussed on one of meetings
[16:04:08 CEST] <thardin> just set the resolution really high, possibly using resolution updates so ffprobe doesn't catch it
[16:04:34 CEST] <thardin> nothing stops me from uploading a 100x100 .ts file to youtube that has a change to 30000x30000 in it (I think)
[16:04:54 CEST] <thardin> and if it's all black it compresses really well too
[16:05:04 CEST] <BtbN> You can probably also build compression-bombs with hand-crafted h264. Tiny bitstream, expands to enormous images
[16:05:32 CEST] <thardin> it's possible with a lot of game codecs without even trying
[16:05:58 CEST] <thardin> you can also do a lot of nasty crap with all formats that (a) use length fields or (b) use pointers
[16:06:25 CEST] <thardin> that and other things make me very nervous about basically anything having to do with parsing
[16:08:05 CEST] <thardin> RE: fuzz stuff, separating crashes from slowdowns makes sense. I don't think we should rely on just michael to fix every performance issue, that's terrible bus factor
[16:09:04 CEST] <thardin> sweet, I got win3.1 rolling
[16:09:25 CEST] <BtbN> I'm also confused why a 2s hang is a major issue now
[16:11:16 CEST] <thardin> I have a few fixes I intend to submit that I've been pondering this exact thing about
[16:11:17 CEST] <jamrial> not major, but why a fuzzer cares to report something taking 2 seconds to finish is a good question
[16:11:31 CEST] <kierank> i think the fuzzers have contention as well
[16:11:47 CEST] <thardin> jamrial: something taking unexpectedly long time to decode is possibly an issue, depending
[16:12:12 CEST] <thardin> I fuzzed gzip a while back with afl-fuzz and thought I'd found a bug
[16:12:31 CEST] <thardin> turns out afl just figured out it can generate output that expands a lot, meaning suspiciously longer runtime
[16:13:47 CEST] <thardin> since no one uses any tooling for complexity analysis, this tends always to be an issue
[16:35:56 CEST] <thardin> heck yeah, got vfw, audio and video set up
[16:40:23 CEST] <J_Darnley> Any particular reason you're doingthat?  Or just for shits and giggles?
[16:46:33 CEST] <thardin> fun!
[16:53:00 CEST] <thardin> gotta have something to take the edge off dealing with mxf
[18:01:53 CEST] <BBB> kierank: so I've been watching BBC while in London, and boy, the banding on their heads is pretty awful, is that a known issue?
[18:02:27 CEST] <kierank> BBB: hd?
[18:02:30 CEST] <BBB> yes
[18:02:36 CEST] <kierank> BBB: which channel
[18:02:41 CEST] <BBB> bbc 1 one hd
[18:02:53 CEST] <BBB> morning show (around 9am)
[18:02:53 CEST] <kierank> do you know what it came from (OTA or satellite?)
[18:02:57 CEST] <BBB> no idea
[18:03:01 CEST] <kierank> because the OTA looks like complete crap they do some strong lowpass on it
[18:03:03 CEST] <BBB> i turned on the tv
[18:03:14 CEST] <kierank> satellite looks a bit better but it's h.264 at 4-5meg interlaced
[18:04:00 CEST] <kierank> the biggest problem is the bbc are obsessed with psnr
[18:04:08 CEST] <kierank> so probably psnr is bloody brilliant
[18:04:12 CEST] <kierank> but it looks like crap
[18:06:30 CEST] <kierank> BBB: I was going to say are you doing the "American tourist in London" thing but then I remembered you are not American :)
[18:07:29 CEST] <BBB> ah that would explain the banding yes
[18:09:00 CEST] <kierank> BBB: http://a.files.bbci.co.uk/media/live/manifesto/audio_video/webcast/dash/uk/full/llnw/uhd_stream_05.mpd
[18:09:04 CEST] <kierank> that should work if you are in the uk
[18:09:07 CEST] <kierank> 35mbit 4k
[18:09:34 CEST] <BBB> why would I want that? :-p
[18:09:45 CEST] <kierank> to see how bad hevc encoders are
[18:10:07 CEST] <BBB> someone told me to not badmouth competitors if they suck
[18:10:08 CEST] <BBB> oops
[18:10:52 CEST] <nevcairiel> is it badmouthing if its factual
[18:11:29 CEST] <BBB> ikr
[18:11:37 CEST] <BBB> anyway
[18:11:41 CEST] <BBB> how do I play that file?
[18:11:44 CEST] <BBB> ffplay doesn't like it
[18:11:46 CEST] <BBB> vlc doesn't play it
[18:11:49 CEST] <BBB> mplayer?
[18:12:29 CEST] <nevcairiel> its dash, most browsers would  probably be able to
[18:12:45 CEST] <jamrial> BBB: you need libavformat compiled with libxml2 support for ffplay to read it
[18:12:52 CEST] <nevcairiel> well, with a proper website around it
[18:14:00 CEST] <kierank> BBB: vlc plays it here
[18:14:42 CEST] <BBB> I suck :(
[18:15:01 CEST] <BBB> let's try to update
[18:15:09 CEST] <durandal_1707> compile with libxml2
[18:16:03 CEST] <durandal_1707> write native xml parser while you at it
[18:17:17 CEST] <BBB> the grass is kind of blur
[18:17:20 CEST] <BBB> otherwise it looks ok
[18:17:28 CEST] <BBB> but I am on a laptop so no 4k scree
[18:17:46 CEST] <BtbN> Tell that to Lenovo, who put 4K screen in 14" Laptops
[18:17:52 CEST] <BtbN> With a GPU barely able to drive it
[18:17:54 CEST] <kierank> it uses very few hevc features
[18:18:01 CEST] <durandal_1707> grass is always blur in RL
[18:18:54 CEST] <BBB> i would've looked at feature usage if my analyzer opened it
[18:18:59 CEST] <BBB> but it doesn't support xml as a container
[18:19:00 CEST] <BBB> :-p
[18:19:38 CEST] <durandal_1707> isnt it xml with links to partial files?
[18:20:26 CEST] <BBB> dunno
[18:22:07 CEST] <jamrial> sure is. just download the init.mp4 file (moov atom) plus any segment, concatenate them, and you have a readable mp4 file
[18:23:06 CEST] <durandal_1707> can youtubedl do that?
[18:26:48 CEST] <jamrial> for supported websites at least. not sure if it will if you just tell it to get a random mpd
[18:26:50 CEST] <jamrial> never tried
[18:29:12 CEST] <BtbN> It might invoke ffmpeg to do that
[18:54:12 CEST] <philipl> BtbN: So I don't see how h.263 hwaccel works. The initialisation for h.263 follows a path where it ends up doing hwaccel in (from ff_get_format) before avctx->codec_[width|height] is set, so this always fails with 0x0 dimensions.
[18:54:38 CEST] <BtbN> So it's just broken in itself, entirely, no matter what hardware?
[18:54:55 CEST] <philipl> That's my impression - I don't understand how the nvidia guy tested his change.
[18:55:27 CEST] <BtbN> neat
[18:55:37 CEST] <philipl> It looks fixable, and I will try.
[18:59:40 CEST] <durandal_1707> should we do new ff meeting?
[19:11:49 CEST] <jamrial> durandal_1707: imo, not with the current animosity
[19:12:49 CEST] <durandal_1707> it will be even worse if nothing changes
[19:28:19 CEST] <durandal_1707> current state is unbearable
[19:47:22 CEST] <lotharkript> durandal_1707: btw, regarding oss-fuzz, it seems we can set the view_restrictions to "security" to have only the bugs mark as security closed, the rest will be open, which should include timeout bugs.
[20:04:36 CEST] <durandal_1707> that still doest explain why some entities like carl and reimar have security access
[20:06:42 CEST] <lotharkript> I was trying to find a solution where all the timeout bug will be open, so any one could look at them and maybe reproduce them, but keep the security to a strict amount of people. Now, the people who will have access to it, i will let the community to decide about it.
[21:13:15 CEST] <lotharkript> I confirm with the oss fuzz that it should be possible to have all the NON security bugs to be open to every one. Is this what the community wants?
[21:17:09 CEST] <lotharkript> in this case, i twill think that any one will be able to reproduce the problem..
[23:18:19 CEST] <mkver> nevcairiel: Is there really consensus that sizeof(AVPacket) should eventually be removed from the public API?
[23:19:12 CEST] <nevcairiel> any such struct with its size as part of the ABI is very limiting
[23:19:32 CEST] <nevcairiel> we cant even add a new field
[23:21:05 CEST] <nevcairiel> and yeah this was definitely discussed before
[23:25:03 CEST] <jamrial> we should start doing some cleaning in that regard, then. i see AVPacket used in stack and heap in a lot of lavf files
[23:29:16 CEST] <nevcairiel> well in lavf its "fine"
[23:29:21 CEST] <nevcairiel> oh wait
[23:29:27 CEST] <nevcairiel> no it would be fine in lavc :D
[23:29:35 CEST] <nevcairiel> i still think its weird its defined in lavc
[23:29:39 CEST] <nevcairiel> but anyway, yeah.
[23:41:35 CEST] <mkver> Ok, and how would the need for temporary packets outside of lavc be fulfilled in this scenario?
[23:41:59 CEST] <nevcairiel> how do temporary frames work?
[23:42:02 CEST] <nevcairiel> you allocate them.
[23:42:30 CEST] <mkver> But that's way more expensive than what is currently done.
[23:42:37 CEST] <nevcairiel> irrelevant cost, though
[23:43:34 CEST] <nevcairiel> if its a commonly called function it could also keep one temp packet that it reuses
[23:45:05 CEST] <mkver> And these temp packets would be stored in AVFormatInternal/AVStreamInternal?
[23:46:43 CEST] <nevcairiel> thats an impossible to answer question since there could be thousand different uses
[23:46:53 CEST] <nevcairiel> with different applicable contexts
[23:48:02 CEST] <nevcairiel> but its really quite an obvious solution, if its a hot code path and it has a context it has control  over, then thats where it can store temporary resources, not sure whats unclear about that
[23:49:30 CEST] <mkver> Your "it [a commonly called function] could also keep one temp packet that it reuses" sounded like you wanted to have a static pointer in a hot function to a packet that is allocated once.
[23:50:38 CEST] <nevcairiel> in what world does static anything make sense? please.
[23:52:04 CEST] <mkver> That's why I was confused. It didn't really made sense.
[00:00:00 CEST] --- Sat Aug 17 2019