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

[burek]

[00:42:16 CEST] <cone-124> ffmpeg 03Carl Eugen Hoyos 07master:a2317556efb7: configure: toolchain-tsan does not need -fPIE.
[03:02:19 CEST] <memeka> hi, I have an issue where an AVFrame contains 1 plane YUV420p data (concatenated), but later on an encoder expects 3 planes (3 AVBufferRef  inside the frame)
[03:02:37 CEST] <memeka> is there a way to automatically convert, or do I have to manually do it?
[03:15:54 CEST] <memeka> what i man is: is there a packed version of AV_PIX_FMT_YUV422P  ?
[03:26:38 CEST] <rcombs> memeka: make a frame with 1 buffer but 3 data pointers
[03:27:33 CEST] <memeka> rcombs: like this? https://www.irccloud.com/pastebin/A2vFWxmh/
[03:28:49 CEST] <rcombs> no, you can just have buf[0], and then fill data[0,1,2] with your planes
[03:31:28 CEST] <memeka> rcombs like this? https://www.irccloud.com/pastebin/gIFFECd7/
[03:31:43 CEST] <rcombs> yeah, that kind of thing
[03:32:08 CEST] <memeka> where will it know the length ?
[03:32:27 CEST] <memeka> do i need to set frame->linesize[0], frame->linesize[1], frame->linesize[2] as well?
[03:33:29 CEST] <rcombs> yes you need to set the linesize
[03:33:40 CEST] <rcombs> the size is implied by that and the height
[03:39:25 CEST] <memeka> rcombs: v4l2 has also sizeimage ... should i use sizeimage instead of bytesperline * height ?
[03:40:10 CEST] <rcombs> to determine how much to offset each data pointer by? yes
[03:40:32 CEST] <rcombs> since that should account for any additional padding that might be present between the planes
[03:40:56 CEST] <memeka> yes, I've seen my driver puts some padding sometimes
[03:41:58 CEST] <memeka> rcombs: actually no, cause I do it the other way around
[03:42:07 CEST] <rcombs> huh?
[03:42:07 CEST] <memeka> i have 1 plane, 1 sizeimage
[03:42:15 CEST] <memeka> i want to get 3 planes
[03:42:21 CEST] <memeka> so sizeimage i cannot use 
[03:42:47 CEST] <memeka> i would use it if I do it the other way around, from 3 planes to 1
[03:42:51 CEST] <rcombs> ahh
[03:43:08 CEST] <memeka> so it's bytesperline * height :)
[03:43:32 CEST] <rcombs> yeah, assuming it's guaranteed that there's no extra padding in between
[03:43:37 CEST] <memeka> :D
[05:21:55 CEST] <memeka> can anyone tell me what's wrong with this movie: https://transfer.sh/YdOyl/out.mkv and how I can fix it?
[11:07:27 CEST] <gagandeep> kierank: i need to ask about some stuff related to pngdec and how threading is implemented
[11:13:45 CEST] <Shibe> to do variable framerate encoding, does my codec need to support it or the container?
[11:15:19 CEST] <atomnuker> container only
[11:15:33 CEST] <nevcairiel> well
[11:15:36 CEST] <nevcairiel> sort of
[11:15:46 CEST] <nevcairiel> if you have any sense of rate control, you need to be aware of that
[11:18:05 CEST] <atomnuker> yeah, you really should set the pts of avframes rather than mess with the packets
[12:33:45 CEST] <gagandeep> kierank: ff_thread_get_buffer assigns the buffer for the thread to decode so in i frame the implementation was working out of the box in cfhd
[12:34:08 CEST] <gagandeep> but with p-frame, the ip data i think comes together in a single buffer
[12:34:24 CEST] <gagandeep> so i think each thread gets the whole 2 frame worth data
[12:34:50 CEST] <gagandeep> otherwise how does this function decide how to seperate i and p frames
[12:35:39 CEST] <gagandeep> or is it able to seperate them and can't find data for the p frame
[12:35:48 CEST] <gagandeep> just help me out with this one
[12:36:28 CEST] <gagandeep> hence segmentation fault in using threads with ip file
[12:37:47 CEST] <cone-181> ffmpeg 03Michael Niedermayer 07master:cced03dd667a: avformat/mms: Add missing chunksize check
[12:39:14 CEST] <kierank> Yes
[12:41:05 CEST] <gagandeep> so threads are getting active for just a placeholder frame with no data
[12:41:36 CEST] <gagandeep> that info must be in passing packets to decoder right?
[12:49:49 CEST] <kierank> Sorry I have limited connectivity
[12:50:03 CEST] <gagandeep> its ok
[12:50:11 CEST] <kierank> Please ask someone who knows about frame threads
[12:50:18 CEST] <gagandeep> ok
[12:51:06 CEST] <gagandeep> does a frame thread spawn right where ff_thread_get_buffer is used provided on update_context is used and also no ff_thread_finish_setup
[12:51:40 CEST] <gagandeep> *provided no update_context
[13:47:17 CEST] <gagandeep> guys i have to directly work on syncing up ip frames and correctly passing data so how should i start, regarding multithreads, anyone interested in explaining me some stuff can reply
[13:50:52 CEST] <BBB> is this libavcodec frame threading?
[13:51:02 CEST] <BBB> happy to explain, but you need to ask more detailed questions
[13:51:46 CEST] <BBB> I dont know what you mean with thread spawn, if you mean creation, then I dont see how that could possibly be anywhere near get_buffer; get_buffer is called per-frame, threads are created only once
[13:51:58 CEST] <BBB> (which should be fairly obvious)
[13:52:17 CEST] <nevcairiel> the important part is that the decoders decode function is already called on a worker thread, the thread is not spawned from it
[13:55:01 CEST] <BBB> re: your comment on finish_setup: if the codec is marked as AV_CODEC_PROP_INTRA_ONLY, you dont need to call finish_Setup
[13:55:13 CEST] <BBB> if not, you do, otherwise you effectively dont get frame-threading
[13:55:35 CEST] <gagandeep> yeah, finish setup i read in header file was when context was to be updated
[13:55:46 CEST] <BBB> the next frame starts decoding the next frame after finish_setup (if INTRA_ONLY=1) or completely independently without any sync at all (if INTRA_ONLY=1)
[13:56:42 CEST] <BBB> its probably best to read how pthread_frame.c works, so you can see the actual code directing this all; its not really well-documented, just some people happen to know how it works because they read it too :)
[13:57:22 CEST] <gagandeep> yeah, i mean i was lucky to read the right header files and was reffered to read pngdec so kinda figured some stuff
[14:03:10 CEST] <gagandeep> also, i should assume that in video packet a buffer that get_buffer gives is one where a codecContext can be independently read
[14:05:21 CEST] <gagandeep> because only then the threads can decode independently
[14:06:39 CEST] <gagandeep> i am asking this because i think in cfhd case the program doesn't create a new thread for the p frame
[14:09:31 CEST] <gagandeep> also, where to look for props
[14:09:37 CEST] <BBB> what do you mean when you say create?
[14:09:47 CEST] <BBB> there is no create per-frame
[14:09:51 CEST] <BBB> create thread is done on program init
[14:09:53 CEST] <BBB> then never again
[14:10:07 CEST] <BBB> do you mean start decoding next frame"?
[14:10:41 CEST] <gagandeep> i mean that it just doesn't have any knowledge of p frame and is decoding as intra frame file
[14:10:46 CEST] <BBB> for intraonly, look at codec_desc.c
[14:10:51 CEST] <BBB> in libavcodec/
[14:11:14 CEST] <BBB> libavcodec/codec_desc.c:        .props     = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
[14:12:32 CEST] <gagandeep> BBB: so situation with cfhd is that i will personally have to provide a thread to decode the p frame
[14:12:50 CEST] <nevcairiel> then you would be doing it wrong
[14:12:53 CEST] <BBB> o_O
[14:12:59 CEST] <BBB> yeah
[14:13:18 CEST] <BBB> sorry, I mean Im all for hacky stuff, but before you go all hacky, you really need to know what youre doing
[14:13:22 CEST] <BBB> I think youre inverting the cycle here
[14:13:31 CEST] <BBB> lets hack stuff together and understand stuff after the fact"
[14:13:47 CEST] <gagandeep> no its ok, i would love to understand the stuff first
[14:13:54 CEST] <BBB> Id highly recommend to do things the standard way, learn things as-you-go, and then hack things up in the end when youre truly an expert that can account for all weirdnesses in the system
[14:14:16 CEST] <BBB> so, dont provide a thread, libavcodec/pthread_frame.c does all that for you
[14:14:21 CEST] <BBB> no need to hack it up differently :)
[14:15:04 CEST] <nevcairiel> for our frame threading to w ork properly you would need to ensure that frames are properly split and delivered independently to the decoder
[14:15:14 CEST] <nevcairiel> if the bitstream does not offer this, there could be a bsf to split them
[14:15:17 CEST] <nevcairiel> like eg. for vp9
[14:16:37 CEST] <BBB> brb
[14:24:24 CEST] <gagandeep> ok, i will try to read the pthread_frame now, just to get a bit more familiar and then present the problems
[14:53:47 CEST] <BBB> is jamrial still here sometimes?
[14:54:11 CEST] <BBB> Im wondering why we still have a vp8/9 parser now that we have BSFs
[14:56:59 CEST] <atomnuker> yeah, he is, just not on at the same time as you are
[15:00:09 CEST] <BBB> tnx
[16:29:19 CEST] <lvlscape_2> is this channel reserved for development directly on ffmpeg, or does it include developers developing with ffmpeg?
[16:29:57 CEST] <BtbN> see topic.
[16:42:41 CEST] <DHE> I'm looking at offering a patch for my own ticket (https://trac.ffmpeg.org/ticket/7296). AAC has a fixed frame size of 1024 according to everything I've read. So it should be as simple as adding that to libavcodec/utils.c:get_audio_frame_duration right?
[16:43:00 CEST] <nevcairiel> it could be 1024 or 960, for that matter
[16:47:56 CEST] <nevcairiel> i would ratehr wonder why framesize is not set, the encoder always needs it set or it w ont work, and the muxing context is made from that, so where does it go missing
[16:55:27 CEST] <DHE> it's a codecpar issue. the encoder has it, but the muxer does not
[16:55:41 CEST] <nevcairiel> sure, but whyy?
[16:55:43 CEST] <nevcairiel> -y
[16:56:38 CEST] <DHE> codecpar doesn't have a frame_size field. so a helper function is called with as much information as available to figure out what the frame_size should be, but the result is 0
[16:57:12 CEST] <DHE> the mpegts muxer needs timing information for at least 1 stream to generate the PCR (program clock reference) values, but AAC isn't providing it
[16:57:56 CEST] <nevcairiel> but AVCodecParameters has frame_size
[16:58:07 CEST] <DHE> wait, it does?
[16:58:38 CEST] <DHE> okay.... you're right...
[16:58:41 CEST] <DHE> so why is this happening>
[16:58:49 CEST] <nevcairiel> that was my question :)
[17:02:42 CEST] <DHE> ah.. okay found it. mpegts calls av_get_audio_frame_duration2(codecpar=(struct), frame_bytes=0) with frame_bytes fixed at 0. and the frame_size field isn't examined if frame_bytes==0
[17:20:30 CEST] <KGB> [13FFV1] 15dericed opened pull request #119: Miller FFV1 review (06master...06miller-review) 02https://git.io/fNesX
[17:27:06 CEST] <BBB> so meson sounds all cool and stuff, but it seems like the port really isnt very feature-complete yet
[17:27:27 CEST] <BBB> its like me building an av1 decoder and saying it only supports dc intra prediction, and any transforms other than dct_dct arent yet implemented"
[17:27:27 CEST] <atomnuker> well, it compiles all parts of the project
[17:27:58 CEST] <BBB> it doesnt allow disabling components (on non-linux systems, disable-autodetect is really useful), it doesnt have fate
[17:27:59 CEST] <BBB> I mean
[17:28:03 CEST] <BBB> how do you develop without fate?
[17:28:05 CEST] <BBB> honest question
[17:28:12 CEST] <nevcairiel> personally i wouldnt be motiviated to work on that if i knew it would never be accepted by certain stubborn people, and as such will forever be blocked
[17:28:15 CEST] <BBB> I make change to vp9 decoder, now what?
[17:28:27 CEST] <BBB> I run meson oops and have to invoke ffmpeg directly?
[17:28:32 CEST] <atomnuker> use make fate
[17:28:59 CEST] <atomnuker> nevcairiel: those people can be shut up as long as you don't mention the word "replacement"
[17:29:02 CEST] <BBB> so its mostly political, its just like everything else
[17:29:09 CEST] <atomnuker> its not political
[17:29:18 CEST] <atomnuker> its factual that configure takes ages
[17:29:31 CEST] <nevcairiel> atomnuker: yeah because that worked so well, the next response then was "so you want double maintenance?"
[17:29:33 CEST] <BBB> it does a but not b because person 1 is not motivated, and because it doesnt do b, person 2 doesnt care
[17:29:39 CEST] <BBB> and now youre at this thing called an "impasse"
[17:30:12 CEST] <BBB> so is the idea that we all agree that we switch to meson once it has feature parity?
[17:30:33 CEST] <BBB> I beg you to please not have 2 build systems
[17:30:42 CEST] <BBB> libaom had that for a while, I dont think anyone was happy
[17:32:18 CEST] <atomnuker> nevcairiel: yes, double maintenence, let configure remain the main system but those using meson can update it
[17:32:29 CEST] <atomnuker> its the same way we have maintainers for different parts
[17:33:17 CEST] <atomnuker> BBB: otoh no one was unhappy until make was removed
[17:33:30 CEST] <nevcairiel> as long as certain developers can (and will) just block any change to the status quo with a 3 word mail, nothing will happen, why do you think the merges were done  without re-reviewing things on the ML, because nothing would ever have happened =p
[17:35:49 CEST] <BBB> but what is the goal?
[17:35:54 CEST] <BBB> what are we voting on?
[17:36:03 CEST] <BBB> will we have 2 build systems? that seems silly
[17:36:11 CEST] <BBB> lets have two prores decoders too then
[17:36:15 CEST] <BBB> oh wait we already do :(
[17:37:44 CEST] <JEEB> the goal would be to have one way of doing configuration/build that doesn't take ages to finish on various quite used systems. meson is one of those alternatives. and any change shouldn't be blocked by just likes or dislikes, it would have to be proper technical reasons that are relevant and make sense in the context of FFmpeg.
[17:41:41 CEST] <BBB> I think duplication is a good technical reason
[17:41:49 CEST] <BBB> Im not trying to be obstructionist btw
[17:41:53 CEST] <BBB> I understand if you think I am
[17:42:01 CEST] <JEEB> nah, I'm actually on your side of the opinion
[17:42:08 CEST] <BBB> but Im wondering why we dont just decide ok, well go with meson and then implement the missing features
[17:42:24 CEST] <atomnuker> I don't mind that personally
[17:42:27 CEST] <BBB> if that is somehow difficult or there is no motivation, then I highly doubt that moving to meson is a good idea because apparently nobody gives a sh1t
[17:42:52 CEST] <BBB> if you want to move a mountain, youd better be severely motivated and ready to face and solve some significant obstacles
[17:42:58 CEST] <BBB> if you cant do that, well, .. that sucks
[17:43:01 CEST] <JEEB> I think at this point it's mostly a case of testing on all the environments that are officially supported by FFmpeg
[17:43:15 CEST] <JEEB> and deciding on what the required things are to do the initial replacement
[17:43:20 CEST] <nevcairiel> i would be all for solving technical obstacles, i'm personally just bored to engage in those BS pseudo-political nonsense
[17:44:00 CEST] <atomnuker> well here's a person who's motivated - Mathieu_Du 
[17:44:18 CEST] <BBB> so if we say yes!, will he implement the missing features?
[17:45:00 CEST] <BBB> I guess its also fine to commit it as an intermediate stage while working on fisnihing stuff off, _as long as_ theres commitment that once feature-parity is accomlpished, we can deprecate configure/make and eventually remove it
[17:45:13 CEST] <BBB> again, dual build systems as a final result would be the worst conclusion imho
[17:45:22 CEST] <JEEB> and/or have a time limit at which point one gets removed
[17:45:29 CEST] <BBB> yeah exactly
[17:46:35 CEST] <BBB> reminds me of ffserver
[17:49:09 CEST] <atomnuker> BBB: well probably, its not like he has submitted a patch
[17:49:30 CEST] <atomnuker> that's why he emailed first, to get some feedback if there's something that really has to be implemented as well
[17:49:43 CEST] <atomnuker> like fate
[17:54:44 CEST] <Mathieu_Du> atomnuker, yes I've already spent quite some time on this, if there's interest upstream I'd be more than happy to continue :)
[17:55:44 CEST] <Mathieu_Du> Can't do it all on my own though, got a few other things on my plate as well
[17:59:43 CEST] <atomnuker> yeah, the fact someone took my original POC and did a ton of work on with and on meson was kinda suprising
[18:00:15 CEST] <atomnuker> anyway, for now you should probably implement fate by invoking the scripts the make system uses
[18:01:17 CEST] <Mathieu_Du> tbh I don't think there's anything left from the original work :P
[18:01:44 CEST] <Mathieu_Du> the problem with fate is that it's completely intertwined with the build systems
[18:01:51 CEST] <Mathieu_Du> system*
[18:02:44 CEST] <Mathieu_Du> (see tests/fate/*.mak)
[18:02:52 CEST] <jamrial> BBB: we in fact got rid of the second prores decoder :D
[18:03:02 CEST] <jamrial> the second encoder is still a todo, though
[18:05:15 CEST] <BBB> woohoo
[18:54:37 CEST] <bcoudurier> FRANCE!!!!!!
[19:01:12 CEST] <atomnuker> baptiste: eh?
[19:02:14 CEST] <atomnuker> its hardly much to be proud with after yesterday; it almost broke the whole internet
[19:03:38 CEST] <baptiste> yesterday ?
[19:04:35 CEST] <atomnuker> https://i.redd.it/cmnea65ud5811.png
[19:04:44 CEST] <atomnuker> on the whole article 11 and 13 vote
[19:06:27 CEST] <ubitux> you know what's worse? most of the "no" are from a fascist group
[19:07:33 CEST] <atomnuker> damn
[19:08:16 CEST] <JEEB> yea I checked who .fi sent out to the EP
[19:08:20 CEST] <JEEB> and \o/
[19:28:30 CEST] <Gramner> swedish MEPs does listen to voters occasionally. no idea wtf france is even doing
[19:29:55 CEST] Action: BradleyS always thought france was pretty cognizant of interwebs and software rights
[19:30:26 CEST] <BradleyS> then again, i reside in the US so anywhere seems more reasonable right about now...
[19:31:00 CEST] <JEEB> Gramner: it seems like at least some things were heard - or just happened to be against the wishes of some lobbyers :D
[20:06:35 CEST] <atomnuker> france is barely at the stage where they'll automatically deduct tax from your salary (starts in January)
[20:07:04 CEST] <baptiste> I like keeping my money in my brokerage :)
[20:07:59 CEST] <atomnuker> I hate doing paperwork more than anything in this world
[20:16:13 CEST] <January> atomnuker: same
[20:19:24 CEST] <atomnuker> though its not like not doing paperwork will stop the vicious and brutal bureaucratic system from plunging you into a world of pain and stress
[20:21:57 CEST] <atomnuker> the chance is lower though, and not needing to do anything but get a letter saying what you've had deducted means you get to laugh at all those that do have to keep track and file everything
[20:23:33 CEST] <atomnuker> even more so in case of americans, they've been prevented of having simpler tax calculations by a company that lobbied against so (and the company makes software that's meant to ease the task)
[22:37:27 CEST] <sfan5> has anyone encountered this error with aarch64 asm + clang? https://0x0.st/sfH7.txt
[00:00:00 CEST] --- Sat Jul  7 2018