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

[burek]

[00:01:45 CET] <rcombs> what's supposed to replace it, individual AVOptions?
[00:03:18 CET] <nevcairiel> probably, there is no uniform definition of quality that applies to all codecs equally
[00:03:26 CET] <wm4> I'm mostly just interested in passing through various nonsense from libavcodec to libavfilter
[02:51:05 CET] <jamrial> wm4: sounds like the job for frame side data?
[10:28:35 CET] <manishv> i am currently working on Decoding bug when playing some MPEG-4 ALS streams for gsoc 2018.I need help regarding how to approach the solution?
[10:31:12 CET] <durandal_1707> manishv: you compiled ffmpeg?
[10:31:46 CET] <manishv> no
[10:32:07 CET] <durandal_1707> that one is mandatory
[10:32:15 CET] <manishv> i am a beginner to this project and want to fix this bug?
[10:32:39 CET] <durandal_1707> you need to do it to be able to reproduce bug
[10:32:40 CET] <manishv> how can i compile it?
[10:33:07 CET] <durandal_1707> manishv: there is documentation for that
[10:33:50 CET] <durandal_1707> you also need git installed
[10:34:35 CET] <durandal_1707> which OS do you have/use?
[10:34:55 CET] <manishv> i am working on ubuntu.Where can i get the documentation?
[10:35:25 CET] <manishv> i have both windows 10 as well as ubuntu.
[10:35:45 CET] <durandal_1707> first grab source via git
[10:36:30 CET] <durandal_1707> do you have git installed and terminal emulator running?
[10:36:44 CET] <manishv> terminal
[10:37:36 CET] <manishv> yes
[10:37:58 CET] <manishv> is the project present on github?
[10:39:11 CET] <manishv> i have both terminal and git installed.
[10:39:18 CET] <durandal_1707> https://trac.ffmpeg.org/wiki/CompilationGuide/Generic
[10:39:45 CET] <durandal_1707> ffmpeg have mirror on github
[10:40:53 CET] <manishv> where is the link to source?
[10:42:28 CET] <durandal_1707> https://www.ffmpeg.org/git-howto.html
[10:44:33 CET] <manishv> thanks
[11:11:50 CET] <manishv> i am having error while compiling the source after i use ./configure in the source directory i get nasm/yasm not found or too old. Use --disable-x86asm for a crippled build.
[11:51:29 CET] <jdarnley> manishv: then install or update nasm
[11:55:51 CET] <manishv> thanks i fixed it
[13:07:01 CET] <cone-595> ffmpeg 03Bodecs Bela 07master:d72399444996: avfilter/avf_concat: add next command
[15:43:01 CET] <wm4> so what are the plans for FF_API_FRAME_QP
[15:43:25 CET] <wm4> it looks like something that'll probably never get removed...
[16:07:21 CET] <jamrial> wm4: add a new frame side data, dump the deprecated fields there.
[16:08:51 CET] <wm4> yeah, but that still doesn't really help, because everything around this is half-deprecated
[16:09:00 CET] <wm4> anyway, writing a patch
[16:09:15 CET] <jamrial> it's one AVBufferRef, one data pointer, two ints
[16:09:22 CET] <jamrial> dump them into a new struct in lavu
[16:09:32 CET] <jamrial> it's used by two decoders and one filter
[16:10:04 CET] <jamrial> sort of like AVMotionVector
[16:10:24 CET] <jamrial> the real pain will be to remove coded_frame, i think
[16:11:53 CET] <jkqxz> atomnuker:  Is there a reason why the added side data buffer wants to match exactly the data/size of the bufferref?
[16:12:23 CET] <jamrial> actually, used by six variants of the same kind of filter, plus another separate filter
[16:12:54 CET] <atomnuker> jkqxz: what do you mean?
[16:13:24 CET] <jkqxz> You only pass the bufferref to the new function, not the data, size and bufferref.
[16:13:51 CET] <jkqxz> So it looks like the side data has to be exactly what it covered by the buffer, it can't be a subset.
[16:14:37 CET] <wm4> I'll add 2 side data typed for QP
[16:14:47 CET] <wm4> because repacking it would make things slower and/or more complex
[16:20:03 CET] <wm4> of course merely adding new side data provokes fate failures...
[16:22:17 CET] <atomnuker> jkqxz: yep
[16:22:52 CET] <BtbN> Did xavs die or something? It's being used for the coverity builds, and it's SVN repo and website is just gone, failing the build
[16:24:01 CET] Action: wm4 complains that there's no way to resume fate at the point where it failed last time
[16:24:28 CET] <wm4> would it be so terrible if we had a python test runner or something?
[16:41:34 CET] <jkqxz> atomnuker:  Well, why?  Aren't you going to be finding side data in some other buffer (e.g. a packet), so passing a reference to that buffer with some specific pointer and size inside it would be sensible?
[16:41:58 CET] <jkqxz> Or am I missing the point somehow...
[16:42:31 CET] <wm4> according to a past discussion, AVBufferRef.data/size must match exactly to the side data .data/size fields
[16:49:31 CET] <jkqxz> Oh, ok.  Seems a bit strange to have that restriction, but sure.
[16:59:17 CET] <wm4> I hope nobody is going to ask why the exif-image-jpg ref file has whitespace changes
[16:59:20 CET] <wm4> because I don't know
[17:01:24 CET] <nevcairiel> I was just going to ask that!
[17:01:25 CET] <nevcairiel> :D
[17:12:55 CET] <jamrial> wm4: what is the point of adding this if you intend to nuke it alongside the existing qp stuff?
[17:16:45 CET] <wm4> jamrial: as stated in the commit message
[17:17:38 CET] <wm4> anyway, all codecs and filters use deprecated functions to access it (av_frame_set/get_qp_table)
[17:17:51 CET] <wm4> it's not up to me to fix this :D
[17:23:55 CET] <atomnuker> wm4: so do you want the function to ref or the api user to ref the avbufferref?
[17:25:28 CET] <wm4> atomnuker: I guess I don't really care... I'd argue the user should ref, because then you can avoid redundant refing - also providing a NULL ref should make it error, so the user doesn't need to check potentially needed av_buffer_ref calls
[17:26:29 CET] <atomnuker> makes sense
[18:25:20 CET] <jdarnley> atomnuker, iive: I forgot to say but I could find any noticable speedup testing either of your vc2enc patches.
[18:25:43 CET] <jdarnley> *I could not
[18:26:44 CET] <atomnuker> any regression?
[18:33:58 CET] <iive> michael reported that fate fails, because the encoded file differs
[18:38:23 CET] <BBB> jdarnley: is that the quant patch?
[18:38:33 CET] <jdarnley> Yes
[18:38:52 CET] <BBB> jdarnley: I mentioned that earlier, its a misconception that writing the C differrently (LUT->math) will give a noticeable speedup; the speedup comes from math being vectorizable
[18:39:03 CET] <BBB> so if you want, write some fun simd and youll actually get a speedup
[18:44:19 CET] <wm4> jesus christ, the mjpeg qp table is created with a memset
[18:44:25 CET] <wm4> makes sense I guess, but still
[18:44:35 CET] <wm4> also doesn't use a buffer pool
[18:44:49 CET] <wm4> does this have any purpose other than making decoding slower...
[18:47:13 CET] <wm4> what do we do by convention if we need to align some data within a single memory allocation?
[18:48:59 CET] <atomnuker> if you have no choice and need to add the data to another piece of data (which isn't a multiple of simd reg size)? pad it I guess
[18:49:30 CET] <wm4> any macros or just do it raw with FFALIGN and some random value
[18:53:02 CET] <wm4> so with some awkardness and making av_frame_set_qp_table() repack the qp data it could be made into a single side data
[18:55:47 CET] <wm4> vf_qp.c doesn't check whether the qp table is large enough for the current frame size, so if a filter which changes the frame size uses av_frame_copy_props(), the qp table can be too small and can make vf_qp access data out of bounds
[18:55:54 CET] <wm4> there's more wrong than right with all this stuff
[19:11:43 CET] <manishv> i need help in solving the issue - > there is a buzzing sound at the end if a mp4/als stream is played and the playback is skipped.I understand that this occurs due to fid(frame id) reset to 0 so it does not skip last extra samples.I need help how can i set fid to its correct value and what are these extra samples and why fid changes to 0 while skipping playback?
[19:13:07 CET] <manishv> I am new to ffmpeg and want to contribute for gsoc 2018.
[19:30:48 CET] <atomnuker> jamrial: "Again, just return ret, regardless of successful allocation or not." < what do you mean?
[19:31:02 CET] <atomnuker> "And I still think this change is unrelated and needs to be in a separate patch" < come on
[19:31:05 CET] <jamrial> what i mentioned in my review for the previous version of the patch
[19:32:07 CET] <atomnuker> what if I mention that it also fixes a theoretical issue where if one alloc was ok and the next wasn't memory would leak?
[19:32:13 CET] <jamrial> ret will be either a pointer on success or null on failure. simply return it always instead of adding an extra line to return null on failure
[19:33:00 CET] <jamrial> there's no leak as is. if the realloc succeeds you don't need to free it if something fails afterwards
[19:34:16 CET] <manishv> i need help in solving the issue - > there is a buzzing sound at the end if a mp4/als stream is played and the playback is skipped. The problem may  also be due to buffers not flushed properly please look into it and provide help for how it can be implemented and fixed?
[19:38:12 CET] <jamrial> manishv: you should ask the project mentors, Mohammad Umair or Thilo Borgmann
[19:38:33 CET] <jamrial> i don't think they are here right now, so send them an email
[19:39:38 CET] <manishv> i think they are not online.i have sent Mohammad Umair email but didn't got reply.
[19:42:45 CET] <atomnuker> jamrial: ah, right, because realloc is guaranteed to keep the base pointer on success
[19:52:35 CET] <iive> atomnuker, hum? this didn't sound right. afaik realloc can allocate a bigger block somewhere else and copy the content from the old block.
[19:52:45 CET] <iive> so the base pointer could change.
[19:53:08 CET] <iive> of course, it will change only on success.
[19:53:52 CET] <atomnuker> oh for fuck sake its a typo
[19:54:04 CET] <atomnuker> should be av_free(ret)
[19:58:35 CET] <atomnuker> jamrial: sent a new patch
[19:59:29 CET] <atomnuker> I didn't split the change out because I didn't want to have a still broken commit and then a separate fix for that theoretical leak and because its one line that's very clearly wrong and anyone can see that
[20:00:06 CET] <jamrial> i said there's no theoretical leak at all
[20:02:12 CET] <jamrial> leave the order of re/alloc calls as they are. just replace the goto fails with return NULLs
[20:05:51 CET] <atomnuker> there's no theoretical leak == there's a leak or there's no leak at all?
[20:06:06 CET] <atomnuker> I can't see how ret will be freed if realloc fails
[20:06:58 CET] <jamrial> no leak. and ret is allocated after realloc either fails or succeeds
[20:07:05 CET] <jamrial> you are trying to change that for some reason
[20:09:37 CET] <atomnuker> we're talking about av_frame_new_side_data_from_buf(), right?
[20:10:18 CET] <jamrial> yes
[20:10:41 CET] <atomnuker> ok, check out frame_new_side_data in current git master
[20:10:54 CET] <atomnuker> in the end: label there's return NULL
[20:11:04 CET] <atomnuker> so if realloc fails ret isn't freed
[20:12:15 CET] <jamrial> in current git master, if realloc fails, ret is never allocated to begin with
[20:13:47 CET] <jamrial> https://pastebin.com/Q6hxm0Tm
[20:13:51 CET] <jamrial> just do that
[20:13:59 CET] <jamrial> any further change is unnecessary
[20:14:27 CET] <cone-328> ffmpeg 03Maxton 07master:1be4c8579024: avcodec/wmaprodec: support decoding up to 16 channels of xma
[20:51:57 CET] <atomnuker> jamrial: sorry, I have no idea why I made that change
[20:52:01 CET] <atomnuker> does this look fine? https://0x0.st/sA7f.patch
[20:54:58 CET] <jamrial> atomnuker: yes, but remove the commit message as it's no longer relevant
[20:55:17 CET] <jamrial> and add version bump, APIChanges line
[21:00:17 CET] <atomnuker> minor bump, right?
[21:01:49 CET] <jamrial> yeah
[21:03:52 CET] <atomnuker> done - https://0x0.st/sA74.patch
[21:04:13 CET] <atomnuker> did I mess something up again or should I push?
[21:34:29 CET] <jamrial> atomnuker: micro should be reset to 100, since you bumped minor. but otherwise it's good now
[21:34:42 CET] <gagandeep> kierank: i am going to start learning wavelet theory and naturally the compression after that, so do you have some recommendations for studying that since you did the previous work on cfhd
[21:36:06 CET] <durandal_1707> gagandeep: thats not trivial, and not required
[21:36:32 CET] <durandal_1707> you are not going to develop new wavelet codec
[21:39:12 CET] <gagandeep> so do i need to manually check each variable and what it is doing
[21:40:08 CET] <durandal_1707> first which bug you gonna fix?
[21:40:44 CET] <gagandeep> the ones that are given in the qualification task, i haven't decided yet, as i was trying to understand the code first
[21:41:44 CET] <gagandeep> durandal_1707: are there some debugging techniques in the development that one needs to know?
[21:41:57 CET] <durandal_1707> hmm, well you need to understand structures used in lavc
[21:42:23 CET] <gagandeep> i was doing that in the past days like avcodeccontext avformat etc
[21:42:38 CET] <durandal_1707> gagandeep: valgrind, gdb and so on
[21:42:59 CET] <gagandeep> yeah exactly, those i need to look into, bit_stream getbit
[21:44:19 CET] <gagandeep> how did kierank reverse engineer this exactly
[21:44:30 CET] <durandal_1707> magic
[21:44:43 CET] <gagandeep> what?? name of some tool?
[21:44:45 CET] <cone-328> ffmpeg 03Rostislav Pehlivanov 07master:6731f6059896: frame: add an av_frame_new_side_data_from_buf function
[21:45:34 CET] <durandal_1707> gagandeep: he bloged about it
[21:46:02 CET] <gagandeep> yeah, need to read it, will do it
[21:46:54 CET] <atomnuker> going to try to stay away from computers for the evening in case I mess something up again
[21:47:23 CET] <gagandeep> durandal_1707: any other advice cause, wavelet transform sure as hell is not looking trivial that's why i tried asking for advice first
[21:48:06 CET] <gagandeep> durandal_1707: sorry for my lack of understanding, as this is my first big project and it sure feels overwhelming 
[21:52:14 CET] <durandal_1707> gagandeep: well, build and install ffmpeg,pick one of bugs and try to find source of bug in code relevant for the bug
[21:55:56 CET] <wm4> hm time to use the new function
[22:05:17 CET] <wm4> atomnuker, jamrial: the new function has messy semantics
[22:05:26 CET] <wm4> now "if (!av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE_DATA, av_buffer_ref(buf)))" would leak
[22:05:36 CET] <wm4> if the buffer ref works, but the function fails
[22:05:44 CET] <wm4> this is rather inconvenient for error handling
[22:05:55 CET] <jamrial> why you didn't mention it before?
[22:06:16 CET] <nevcairiel> imho such a function should add a ref to the buffer on its own
[22:06:19 CET] <nevcairiel> and not make you do it
[22:06:22 CET] <jamrial> the doxy is explicit about how things are handled, making it clear that's not a good usage
[22:06:30 CET] <wm4> jamrial: I did
[22:07:15 CET] <jamrial> It can be changed, in any case
[22:08:00 CET] <jamrial> but as i said before, it's better to leave creating a new reference to the user. less overhead in the function
[22:08:10 CET] <nevcairiel> i disagree
[22:08:14 CET] <wm4> probably better not to... it's not critical, just makes for slightly less convenience
[22:08:24 CET] <nevcairiel> any other refcounting api would behave differently
[22:08:35 CET] <wm4> nevcairiel: than what?
[22:08:45 CET] <nevcairiel> it would create its own ref, and not rely on the user making one
[22:08:50 CET] <wm4> yeah
[22:09:05 CET] <wm4> but ffmpeg refcounting is not exactly overhead free
[22:13:22 CET] <jamrial> probably why this should have been like av_packet_add_side_data() instead as i said some months ago, taking a data pointer and creating the avbufferref internally
[22:14:08 CET] <jamrial> wm4: what do you suggest?
[22:14:42 CET] <jkqxz> nevcairiel:  Care to compare some VC-1 interlaced frame hashes?
[22:14:55 CET] <nevcairiel> oh right i forgot about that
[22:15:35 CET] <wm4> jamrial: normally refcount APIs would probably create a new ref and not mess with the caller's, yeah
[22:15:51 CET] <jkqxz> VAAPI:  Intel (Coffee Lake): <https://0x0.st/sAho.log>  AMD (Polaris 11): <https://0x0.st/sAhH.log>.
[22:16:04 CET] <jkqxz> They agree about the first frame, at least.  (Though not with the software decoder at all.)
[22:16:10 CET] <wm4> it was my idea though to let the callee take over the reference
[22:16:11 CET] <nevcairiel> different ones? thats no fun
[22:16:52 CET] <nevcairiel> does fate have both kinds of interlacing samples, anyway? vc1 is weird with interlacing, has something called field and frame interlacing
[22:17:28 CET] <jkqxz> I know approximately fuck all about VC-1.
[22:17:49 CET] <nevcairiel> i implemented the original interlaced hwaccel hooks back in the day
[22:17:49 CET] <wm4> nevcairiel: is that different from the h264 interlacing modes?
[22:17:53 CET] <nevcairiel> specifically because interlacing is so weird
[22:18:03 CET] <nevcairiel> dunno
[22:18:05 CET] <nevcairiel> maybe it isnt
[22:18:13 CET] <nevcairiel> but it was because the vc1 software decoder is so incomplete
[22:18:45 CET] <JEEB> yea, vc-1 decoder had and probably still has some stuff that's not 100% kosher
[22:18:55 CET] <jamrial> wm4, nevcairiel: can you reply to the thread with these arguments? Or as part of a patch changing the function
[22:18:58 CET] <nevcairiel> i dont usually use the software decoder
[22:19:09 CET] <nevcairiel> either with hwaccel or access the microsoft decoder
[22:19:32 CET] <nevcairiel> i wonder if i can somehow make hashes out of the MS decoder
[22:19:43 CET] <wm4> jamrial: well what I wanted was the function freeing the reference if it fails (so calling the function _always_ takes away the reference), but now I'm not sure anymore whether this is a good idea
[22:23:06 CET] <jamrial> technically speaking, the current behavior is also ugly. the ownership of the avbufferref is transferred to the side data, but the reference passed to the function remains intact. so there are two avbufferref pointing to an avbuffer where the refcount is 1
[22:23:46 CET] <wm4> well the validity of the caller's reference depends on whether the function call succeeds
[22:23:54 CET] <wm4> (this is the part I don't like)
[22:24:32 CET] <jamrial> maybe the function should take AVBufferRef **buf, and do *buf = NULL at the very end in case of success
[22:24:48 CET] <gagandeep> atomnuker: seems kierank is not available right now, so how should i approach the bugs listed for qualification task in cfhd, considering this is going to be my first ever bug fix
[22:25:10 CET] <wm4> jamrial: at least that would work well in my use case
[22:25:24 CET] <wm4> but not sure, feels artificial
[22:25:36 CET] <wm4> maybe we should give up and always make it create a new ref
[22:26:14 CET] <jamrial> there's no way to "reset" an avbufferref, like you'd do with a packet or a frame by calling init() to get default values
[22:26:38 CET] <nevcairiel> jkqxz: dxva2 on nvidia https://pastebin.com/uUk24BPJ .. d3d11va somehow fails to open for vc1, not sure whats up with that shit
[22:27:21 CET] <nevcairiel> interestingly it matches more frames to your intel output, but then also diverges
[22:27:25 CET] <jkqxz> Agrees with Intel for the first four frames and then diverges.
[22:27:26 CET] <jkqxz> Wtf.
[22:27:45 CET] <nevcairiel> i should really get us hashes from the MS decoder
[22:27:51 CET] <nevcairiel> wonder how i can do that
[22:29:45 CET] <wm4> I had a mediafoundation wrapper somewhere
[22:29:59 CET] <wm4> probably supported vc1 somewhat
[22:30:32 CET] <nevcairiel> i dumped the raw yuv to a file
[22:30:38 CET] <nevcairiel> now how do i  open that
[22:31:21 CET] <nevcairiel> hey it worked
[22:31:22 CET] <wm4> you mean some magic raw video demuxing CLI?
[22:31:32 CET] <nevcairiel> ffmpeg -f rawvideo  -pixel_format nv12 -video_size 1920x1080 -i D:\dump
[22:31:33 CET] <nevcairiel> works
[22:31:56 CET] <cone-328> ffmpeg 03Marton Balint 07master:d54a04b69b8d: avformat/mxfdec: fix indentation
[22:31:57 CET] <cone-328> ffmpeg 03Marton Balint 07master:e9b0e42e773d: avformat/mxfdec: fix essence_offset calculation
[22:31:58 CET] <cone-328> ffmpeg 03Marton Balint 07master:5c2fd59700c4: avformat/mxfdec: use the first system item if available for calculating essence_offset
[22:31:59 CET] <cone-328> ffmpeg 03Marton Balint 07master:9ec3e61fc37a: avformat/mxfdec: use full UMID to resolve source package
[22:32:00 CET] <cone-328> ffmpeg 03Marton Balint 07master:9492bb58eeea: avformat/mxfdec: use both body_sid and track_number to find the track of a packet
[22:32:01 CET] <cone-328> ffmpeg 03Marton Balint 07master:c46e430c5bc7: avformat/mxfdec: fix sorting of index segments
[22:32:02 CET] <cone-328> ffmpeg 03Marton Balint 07master:5b36379eb6eb: avformat/mxfdec: set index_duration from the track using the index
[22:32:03 CET] <cone-328> ffmpeg 03Marton Balint 07master:0827c78e98da: avformat/mxfdec: use body_offset of the partitions in mxf_absolute_bodysid_offset
[22:32:04 CET] <cone-328> ffmpeg 03Marton Balint 07master:e8e1c22f21ee: avformat/mxfdec: compute sample_count after seek from index for audio streams
[22:32:05 CET] <cone-328> ffmpeg 03Marton Balint 07master:f50741147cca: avformat/mxfdec: always use a stream which matches the first index table when seeking
[22:33:02 CET] <nevcairiel> jkqxz: the nvidia dxva2 hashes match the microsoft software decoder
[22:34:11 CET] <jamrial> wm4, nevcairiel: an example usage of the function as is would be https://pastebin.com/SyVfbj3a
[22:34:52 CET] <nevcairiel> dont we have a fucntion already that can take any arbitrary memory buffer and take it over
[22:35:23 CET] <nevcairiel> maybe that was for avpacket sidedata
[22:35:31 CET] <jamrial> for packet/stream, yes
[22:36:03 CET] <jamrial> add_side_data, which takes a data pointer and size, taking ownership of them in case of success
[22:36:23 CET] <jamrial> it's what i argued should be done for frame side data as well some time ago
[22:36:33 CET] <wm4> I still wonder how we could remove the side data code duplication
[22:36:39 CET] <wm4> which is all over the place
[22:36:58 CET] <jkqxz> nevcairiel:  Ok, well, I have no idea what to do with that result.  I wonder what DXVA2 does on Intel; I could probably test that but not now.
[22:37:15 CET] <jkqxz> I guess I will put it in an email and see what the submitter wants to do with it.
[22:38:05 CET] <jkqxz> Though I think I'm happy to apply the patches anyway, assuming noone has any objection?
[22:38:08 CET] <nevcairiel> afaik it matches, but i did a lot fixing of the passed vc-1 values over the years, it was the most incomplete of the dxva2 implementations of the old codecs
[22:38:36 CET] <nevcairiel> i should be able to test that, gimme a sec
[22:41:16 CET] <nevcairiel> jkqxz: intel on dxva2 matches your intel values
[22:41:20 CET] <nevcairiel> lets just call vc1 weird
[22:41:22 CET] <jkqxz> On the subject of side data and avoiding duplication, would anyone be offended by a way to pass side data through an encoder to the output packets?
[22:41:33 CET] <nevcairiel> i dont even know if its supposed to be fully bitexact
[22:41:49 CET] <nevcairiel> like mpeg2, you cant compare those, its just not exact
[22:41:53 CET] <wm4> jkqxz: you mean AVFrame->AVPacket?
[22:42:11 CET] <jkqxz> The aim being to avoid this random SEI and similar support in every single encoder separately.
[22:42:20 CET] <jkqxz> Because you can do in postprocessing with h264_metadata.
[22:42:26 CET] <jkqxz> wm4:  Yes, exactly that.
[22:42:51 CET] <wm4> jkqxz: probably an ok idea? though also a lot of things that could go wrong
[22:43:05 CET] <wm4> how do you associate input frames and output packets in the first place?
[22:43:18 CET] <nevcairiel> with external encoders thats going to be hard
[22:43:35 CET] <nevcairiel> unless you make a dumb fifo, but that has its own corner cases
[22:44:39 CET] <wm4> you have the same problem with external decoders
[22:44:41 CET] <wm4> qsv I guess
[22:44:44 CET] <jkqxz> The encoder does need some intelligence to do it, yeah.  Not sure how you can do that in opaque encoders, maybe you can match timestamps?
[22:44:46 CET] <wm4> and mediacodec
[22:45:00 CET] <nevcairiel> timestamp based anything is always iffy
[22:45:14 CET] <jkqxz> I have a set to use it to do A/53 in VAAPI.
[22:47:29 CET] <jkqxz> That does have exact matching of input frames to packets, though.
[22:55:15 CET] <cone-328> ffmpeg 03Xiaohan Wang 07master:f5f2209d689c: ffmpeg: Fix memset size on ctts_data in mov_read_trun() (round 2)
[23:06:04 CET] <atomnuker> jamrial / wm4: so what do you think we should do? make the function ref the buffer?
[23:06:20 CET] <atomnuker> or leave things as they are?
[23:10:04 CET] <jamrial> i prefer it taking ownership of the passed reference as it currently does, but i agree it's not 100% clean
[23:11:25 CET] <jkqxz> wm4:  Like this <https://0x0.st/sAhB.diff> ('-bsf:v h264_metadata=a53_cc=insert' after an encoder to add A/53 SEI, for example.)
[23:12:45 CET] <wm4> jkqxz: yeah I guess that works for vaapi
[23:13:26 CET] <wm4> should the bsf remove the side data if it merges it into the bitstream?
[23:13:55 CET] <wm4> (also when can we get the reverse - CC extraction with correct frame reordering in a BSF)
[23:14:10 CET] <jkqxz> I don't really know, maybe.
[23:14:20 CET] <jkqxz> That does the extraction without the reordering.
[23:15:22 CET] <jkqxz> Enough to work if you can pass the side data references through an external decoder properly, though.
[23:16:17 CET] <wm4> most POS external decoders pass through only the PTS (but often enough corrupt or change even that)
[00:00:00 CET] --- Fri Mar  2 2018