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

[burek]

[00:05:15 CEST] <wbs> jamrial: don't have time right now (going to bed in a minute), but in general I think it might be necessary
[00:05:27 CEST] <jamrial> sure, no hurry
[00:05:39 CEST] <wbs> jamrial: the thing is; if you invoke clang just as "clang -c src.c -o src.o", it works like gcc
[00:05:52 CEST] <wbs> but you can also invoke it as "clang-cl" when it takes parameters in the same format as msvc's cl.exe
[00:05:58 CEST] <wbs> I don't use this mode myself at all though
[00:06:09 CEST] <wbs> I just use "clang -target <arch>-win32-msvc -c src.c -o src.o"
[00:06:28 CEST] <wbs> which is easier to interface with our buildsystem since it already works as a normal gcc-style driver
[00:06:51 CEST] <wbs> (while the compiler itself still behaves exactly like msvc when compiling)
[00:06:54 CEST] <nevcairiel> does that make a fully  functional ffmpeg/libav build these days?
[00:07:22 CEST] <nevcairiel> last I tried, which was some time ago admittedly, it still crashed and burned on many parts
[00:07:52 CEST] <wbs> nevcairiel: I have a few fate configurations with it here at least: https://fate.libav.org/aarch64-win32-clang-6.0/20180410111812
[00:08:29 CEST] <nevcairiel> might have been x86 s pecific failures because it pretends to do inline asm but not really worked
[00:09:35 CEST] <wbs> right, I'm not sure if I've tested it quite that much in x86 configurations
[00:10:10 CEST] <wbs> it's a rather special setup anyway, because it only defines _MSC_VER and generally works like msvc, but also defines __clang__, and it does support most of the normal gcc style __attribute__((foo)) as well
[00:10:31 CEST] <wbs> so I had to do a few changes to libavutil/attributes.h or so, to make it pick up a few essential ones that normally are behind __GNUC__
[00:11:23 CEST] <wbs> I should have pretty decent setups where I could try that setup for x86 as well, some other day
[00:11:38 CEST] <wbs> (but I'm generally quite uninterested in the clang-cl frontend)
[00:11:42 CEST] <wbs> anyway - good night
[00:11:50 CEST] <nevcairiel> good night
[00:55:56 CEST] <cone-100> ffmpeg 03James Almer 07master:ef06ed5b185d: libaom: remove references to yuv440p pixfmt
[00:55:57 CEST] <cone-100> ffmpeg 03James Almer 07master:b0958698ea2b: libaom: remove references to RGB pixfmts
[00:55:58 CEST] <cone-100> ffmpeg 03James Almer 07master:b13a1210a242: Merge commit 'b0958698ea2b976063cb1d683becc213040c709b'
[01:01:05 CEST] <cone-100> ffmpeg 03Zhong Li 07master:52ed83fa1a7f: lavc/qsvdec: expose frame pic_type and key_frame
[01:01:06 CEST] <cone-100> ffmpeg 03Zhong Li 07master:29a8ed766354: lavf/qsvvpp: bypass vpp if not needed.
[01:01:07 CEST] <cone-100> ffmpeg 03James Almer 07master:6f277e1f7612: Merge commit '52ed83fa1a7f5170447eff6fad0b6c57119596e9'
[01:01:08 CEST] <cone-100> ffmpeg 03James Almer 07master:ae7e66fb4b1a: Merge commit '29a8ed766354c45c9be4b8512c5b2eb25a450cdc'
[01:38:20 CEST] <cone-100> ffmpeg 03Maxym Dmytrychenko 07master:cca5e4f04097: qsv: adding Multi Frame Encode support
[01:38:21 CEST] <cone-100> ffmpeg 03James Almer 07master:f790410b6baa: Merge commit 'cca5e4f040971db6de0bfe6968f00c021d8a9c42'
[01:39:40 CEST] <cone-100> ffmpeg 03Zhong Li 07master:54307b35311e: lavc/qsvdec: set complete_frame flags for progressive picture
[01:39:41 CEST] <cone-100> ffmpeg 03James Almer 07master:bbe95ebdadff: Merge commit '54307b35311e9a871b3d8ecb2b2eecfc16de0163'
[01:42:16 CEST] <cone-100> ffmpeg 03Vittorio Giovara 07master:cc06f7bd10c2: libx265: Support tiny video sizes
[01:42:17 CEST] <cone-100> ffmpeg 03James Almer 07master:4339c94364f8: Merge commit 'cc06f7bd10c236539b4f6f87b795c459dd873770'
[01:53:05 CEST] <cone-100> ffmpeg 03Vittorio Giovara 07master:f821b2ea276e: avprobe: Support printing strings with empty keys
[01:53:06 CEST] <cone-100> ffmpeg 03Vittorio Giovara 07master:c31f6b1d6175: avprobe: Print a user-friendly version of the display matrix
[01:53:07 CEST] <cone-100> ffmpeg 03James Almer 07master:52b44e9d15c0: Merge commit 'c31f6b1d61759436ef50c094e7f4c8005e97614a'
[02:09:04 CEST] <cone-100> ffmpeg 03wm4 07master:c7ab6aff66cb: w32pthreads: always use Vista+ API, drop XP support
[02:09:05 CEST] <cone-100> ffmpeg 03Diego Biurrun 07master:8f144d9e3d5c: Drop Windows XP support remnants
[02:09:06 CEST] <cone-100> ffmpeg 03James Almer 07master:217ad40aef9e: Merge commit 'c7ab6aff66cba2f265f656ce8d56aa428d4ada76'
[02:09:07 CEST] <cone-100> ffmpeg 03James Almer 07master:b14761d1f837: Merge commit '8f144d9e3d5cb2ca92e5bdf7cc9f72effa1bd2ce'
[02:11:07 CEST] <jamrial> jkqxz: can't test the qsv stuff, but it merged (mostly) cleanly, so if you want to give it a try...
[02:20:00 CEST] <cone-100> ffmpeg 03James Almer 07master:23e994ca496c: avformat/utils: use the existing packet reference when parsing complete frames
[02:22:42 CEST] <cone-100> ffmpeg 03James Almer 07n3.3.7:HEAD: avformat/utils: use the existing packet reference when parsing complete frames
[11:20:44 CEST] <BodecsB> i am creating a fate test. I did not find a suitable reference file among files of fate-suite. I can create the reference file on the file. which the prefered way: a) send a new file into fate-suite b) create the ref file on-the-fly?
[12:40:00 CEST] <wbs> nevcairiel: at least libav built fine (almost) with clang ( >= 4.0) in msvc mode  - only one fix needed for libav, that I just sent, fwiw
[12:42:05 CEST] <nevcairiel> i should probably re-try
[12:42:11 CEST] <nevcairiel> you used the gcc interface again?
[15:33:32 CEST] <durandal_1707> wait for release until i push/fuzz dxv hq!
[15:45:41 CEST] <JEEB> you don't need to scream
[15:46:06 CEST] <JEEB> still 24-48 hours to go, and then it gets a "is this important enough" decision
[15:55:26 CEST] <cone-496> ffmpeg 03Michael Niedermayer 07master:18d6ff2b42c1: tests/checkasm/checkasm: Provide verbose failure information on float_near_abs_eps() failures
[16:36:10 CEST] <durandal_1707> JEEB: it is very, very, Very, VERY Important!
[16:46:44 CEST] <jamrial> clearly, the multimeda world depends on it being part of ffmpeg 4.0
[16:58:04 CEST] <durandal_1707> yes!
[16:58:16 CEST] <durandal_1707> its like prores RAW
[17:30:39 CEST] <FishPencil> Does FFmpeg allocate memory for a single frame, and fill it with the data of the following frames? Or is the frame deallocated and then reallocated for each frame?
[17:30:50 CEST] <durandal_1707> neither
[17:31:53 CEST] <FishPencil> Hm, how is the memory managed then or how is the frame read?
[17:49:05 CEST] <nevcairiel> frame buffer use a pool, so the memory is reused eventually, but you can have multiple active ones at a time
[17:49:19 CEST] <nevcairiel> the pool grows dynamically as needed
[17:52:06 CEST] <FishPencil> That makes sense
[17:52:26 CEST] <cone-496> ffmpeg 03Paul B Mahol 07master:2b0f821f51d1: avfilter/af_headphone: improve performance and reduce latency
[17:52:27 CEST] <cone-496> ffmpeg 03Paul B Mahol 07master:01170e9db071: avfilter/af_headphone: fix flushing
[17:59:34 CEST] <durandal_1707> atomnuker: i havent received review for last dxv, also it now use ycocg colorspace
[18:02:32 CEST] <FishPencil> nevcairiel: You say the memory is reused, does that mean it's deallocated and reallocated? Or is the old frame just overwritten with new data
[18:02:47 CEST] <JEEB> AVFrames most of the time are reference counted
[18:02:55 CEST] <nevcairiel> the data is just overwritten eventually
[18:03:04 CEST] <nevcairiel> possibly cleared in between, i dont remember
[18:03:22 CEST] <nevcairiel> and yeah it uses reference counting to keep track of which are available for use
[18:15:19 CEST] <jamrial> jkqxz: regarding your av1 cbs implementation, i'm looking at the isombff spec for av1 and i see that it defines a configuration box that stores one or more sequence header and metadata obus
[18:15:44 CEST] <jamrial> so basically, the same thing that's done for h264/5 parameter set nalus
[18:16:53 CEST] <jamrial> we should probably then make it extradata for av1 within ffmpeg
[18:20:59 CEST] <jamrial> even if it may not bring any benefit for decoding, it'll pretty much be required to remux from ivf to mov, for example
[18:21:09 CEST] <jamrial> extract_extradata_bsf will take care of it
[18:21:20 CEST] <jkqxz> Yeah, sounds fine.
[18:21:29 CEST] <jkqxz> ... as long as they don't invent another bitstream format for it.
[18:21:49 CEST] <JEEB> huh, and the webm spec said that no buffers in extradata
[18:21:50 CEST] <JEEB> funky
[18:22:14 CEST] <jamrial> JEEB: webm/mkv is afaik not finished. neither is isombff
[18:22:19 CEST] <JEEB> right
[18:22:38 CEST] <jamrial> I'd very much like webm/mkv to also put those obus in codecprivate, for that matter
[18:22:52 CEST] <JEEB> I totally don't disagree :)
[18:23:11 CEST] <jamrial> TD-Linux: ^ can we get that?
[18:23:41 CEST] <jkqxz> Require or allow?
[18:24:04 CEST] <jamrial> required, imo. much like h264/hevc
[18:25:00 CEST] <jamrial> although the av1 in isombff spec mentions zero or more obus in that configuration box, so maybe not required?
[18:25:36 CEST] <jkqxz> Hmm, does that actually work?  Since there are no SPS IDs you can only really have one.
[18:25:37 CEST] <JEEB> HEVC makes it dependant on the identifier
[18:25:51 CEST] <JEEB> some let you have in-band, others specifically say "nope"
[18:27:04 CEST] <jamrial> jkqxz: "The configOBUs field contains zero or more OBUs applicable to all the samples corresponding to the sample description entry. Multiple OBUs of the same type may be present only if they differ by their temporal_id or spatial_id value"
[18:27:20 CEST] <jamrial> if you meant how av1C handles it
[18:40:24 CEST] <cone-496> ffmpeg 03Paul B Mahol 07master:8daca7697b7d: avfilter/af_headphone: do not output invalid samples when flushing
[19:08:21 CEST] <atomnuker> jamrial: could you try to resubmit your flac coverart patch with the request from the mp4 coverart patch author? I'd really like for both to make it into 4.0
[19:08:51 CEST] <atomnuker> durandal_1707: I glanced over it when you resubmitted and it looked fine, I'll give it a better look
[19:09:10 CEST] <atomnuker> I thought dxv was kinda old, isn't it?
[19:10:42 CEST] <jamrial> atomnuker: no, using st->attached_pic to hold cover art during muxing is not a good idea. a better solution is needed
[19:11:08 CEST] <jamrial> i'll push the flac patch as is for now, then it can be adapted to whatever we end up implementing
[19:12:44 CEST] <atomnuker> sounds fine
[19:34:00 CEST] <TD-Linux> jamrial, is just matching the language of isobmff exactly ok?
[19:34:17 CEST] <TD-Linux> the other thing is the isobmff spec allows the obus to be in both the extradata and blocks
[19:37:22 CEST] <jamrial> TD-Linux: you mean it allows things like the same sequence header obu being present in av1C and in a block?
[19:37:43 CEST] <TD-Linux> yeah
[19:37:55 CEST] <jamrial> that's cool
[19:38:54 CEST] <jamrial> and yes, making codecprivate match the contents of av1C so parsing code can be reused would be nice
[19:43:13 CEST] <atomnuker> jamrial: could you also review/reply to the movenc coverart patch?
[19:45:20 CEST] <cone-496> ffmpeg 03Paul B Mahol 07master:a56580b11736: avfilter/af_headphone: fix memory leak and overread
[19:45:31 CEST] <jamrial> atomnuker: not as is. it tries to use attached_pic as temporary storage 
[20:03:25 CEST] <atomnuker> k, wrote him to not use it as temp storage
[20:04:17 CEST] <JEEB> &38
[20:04:19 CEST] <atomnuker> if he can't do it quick enough I'll resubmit it
[20:07:03 CEST] <jamrial> atomnuker: basically, we shouldn't rush a change in how a public field is used just to get cover art in mov or flac committed
[20:07:19 CEST] <jamrial> when it can be done using internal storage
[20:07:58 CEST] <jamrial> how cover art is handled in any case is incosistent, as he said it himself
[20:09:24 CEST] <jamrial> to be honest we shouldn't even apply anything right now until we can define how it shold work
[20:20:01 CEST] <durandal_1707> atomnuker: the only way to reduce switch identation is to add goto, not continue statement
[20:49:32 CEST] <atomnuker> durandal_1707: that's okay too
[20:50:11 CEST] <atomnuker> jamrial: I agree, we shouldn't use an external field as temp storage
[20:50:54 CEST] <atomnuker> but we shouldn't be holding back patches because we can't decide where to put temporary fields considering they change nothing on the external side of things
[21:03:15 CEST] <durandal_1707> atomnuker: i cant merge those 2, one needs casts and another doesnt
[21:05:56 CEST] <atomnuker> macro it out?
[00:00:00 CEST] --- Sun Apr 15 2018