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

[burek]

[00:23:29 CEST] <cone-949> ffmpeg 03James Almer 07master:cf3d2d52b59d: avcodec/avpacket: deprecate av_copy_packet_side_data()
[02:37:51 CEST] <kode54> what's the correct way to pass the macOS min spec build switch to the build process there?
[02:38:55 CEST] <kode54> I use: --extra-cflags="-fPIC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.6"
[02:39:26 CEST] <kode54> should probably upgrade that to 10.7, but still, I see things complaining about binaries built for 10.13
[02:40:35 CEST] <BBB> I think you need extra-libs also, if youre building shared libraries
[02:41:13 CEST] <BBB> (extra-libs=-mmacosx-version-min=10.6
[02:41:15 CEST] <BBB> )
[02:41:32 CEST] <BBB> kode54: ^^
[02:41:55 CEST] <kode54> I'm building static libraries in this case
[02:42:08 CEST] <kode54> but yeah, it probably needs that
[02:45:30 CEST] <BBB> I suppose you still need it for the binaries (ffmpeg, ffplay, etc.), yes
[02:47:07 CEST] <kode54> I currently only use the libraries in a format plugin or two
[02:47:18 CEST] <kode54> GPL licensed audio player
[02:47:39 CEST] <kode54> that I have not actually tested on 10.7, so I don't know if my minspec actually makes it work there
[02:48:05 CEST] <kode54> hell, I just barely started using Sparkle correctly
[02:48:05 CEST] <jamrial> kode54: isn't -fPIC added automatically for you?
[02:48:21 CEST] <kode54> probably, I just stole someone else's script and have modified it over time
[02:48:37 CEST] <kode54> it basically just disables everything but the libraries, and selectively enables a bunch of audio codecs
[02:48:56 CEST] <kode54> I also had to selectively disable a bunch of MP4 video codecs, because enabling the mp4 parser enables them automatically
[02:49:32 CEST] <BBB> probably demuxer <> parsers, but sure, if you only need audio that should be fine
[02:49:53 CEST] <kode54> I support a couple of video related containers, but only handle audio in them
[02:50:14 CEST] <kode54> my frontend code sets the disable/skip flag on the streams so the parser doesn't try to decode them
[02:50:59 CEST] <kode54> it only decodes one audio stream at a time, as requested either by the player, or the library (FFmpeg based player plugin, and VGMStream based plugin)
[02:51:22 CEST] <kode54> sadly, the way my code is arranged, both plugins have to import their own copies of FFmpeg
[02:51:41 CEST] <kode54> I should get around to changing some of these redundant deps to dylibs so I can stuff them in a common location
[02:52:10 CEST] <kode54> I just got around to adding my DSA public key to the binary a few releases ago
[02:52:37 CEST] <kode54> for reasons unknown, Sparkle didn't used to verify the DSA signature for delta patches, only verified the code signature of the resulting output app bundle
[02:53:06 CEST] <kode54> I didn't know I needed to include the DSA public key, that should have been a big DUH moment for me, how else can it verify that crap?
[02:53:31 CEST] <kode54> I have a FATE patch to submit too
[02:53:37 CEST] <kode54> I need to finalize it though
[02:53:56 CEST] <kode54> I made a 1 second test file, when I realized there's already a 10 second test MP3 in the FATE repository
[02:54:18 CEST] <kode54> my test sample source is 7 seconds long, a simple ~128kbps MP3 should be fine from that length, right?
[08:10:35 CEST] <ubitux> kode54: i saw some patches in libav tree for that
[08:11:15 CEST] <ubitux> 81bffae368f331b6cd386a814f225a58e3f32f40
[08:11:33 CEST] <ubitux> which is then reverted
[08:11:35 CEST] <ubitux> for 0d8013b88b1cb7d65da891a8819d3beebafb9bb5
[08:11:55 CEST] <ubitux> not sure if that helps
[08:12:16 CEST] <kode54> I submitted a patch months ago, but it got held up by the need for a fate test
[10:40:29 CEST] <durandal_1707> what was at ffmpeg metting at vdd?
[10:45:04 CEST] <JEEB> not much, explaining to people why lavfi doesn't work with subtitles and stuff like that (= AVFrame doesn't yet handle subtitles)
[10:45:11 CEST] <JEEB> and discussions about VANC
[10:45:14 CEST] <JEEB> some other things
[11:01:17 CEST] <ubitux> there is a patchset for the subtitles in AVFrames, i need to honor some of wm4 comments
[11:01:31 CEST] <ubitux> (i won't be able to honor them all)
[11:03:19 CEST] <JEEB> yes, oct 2016 or so
[11:03:29 CEST] <JEEB> I remember looking at the RFC patch at one point
[11:03:53 CEST] <ubitux> the alloc is going to be different/ugly in any case
[11:04:04 CEST] <durandal_1707> JEEB: im asking about special meeting
[11:04:19 CEST] <JEEB> I don't think there was any other meeting at VDD for FFmpeg
[11:04:35 CEST] <JEEB> than the technical one on Saturday
[11:04:56 CEST] <JEEB> of course people talk in other places as well but you can't really call that a "meeting"
[11:17:10 CEST] <durandal_1707> JEEB: the one that was at same tima as libav one
[11:17:20 CEST] <JEEB> yes, that was what I was talking about
[11:18:23 CEST] <JEEB> various questions regarding things, like why lavfi doesn't support subtitles, VANC related stuff, someone wanting another library with a lot of the common client stuff in it (closer to ffms2 level than lavf/lavc)
[13:47:23 CEST] <nevcairiel> BBB: kode54: instead of --extra-libs you should really use --extra-ldflags (in addition to --extra-cflags), just for correctness sake. that flag is not a library to link to :)
[13:47:48 CEST] <BBB> <- build n00b
[13:48:09 CEST] <BBB> tnx ;)
[16:16:00 CEST] <cone-844> ffmpeg 03James Almer 07master:a22c6a4796ca: avcodec/encode: remove usage of av_dup_packet()
[16:46:30 CEST] <funman> can I specify stream specific options together with -map ?
[16:46:50 CEST] <funman> or even without -map
[16:46:56 CEST] <funman> ffmpeg -i ird.ts
[16:46:59 CEST] <funman> [mpegts @ 0x259fde0] Could not find codec parameters for stream 3 (Audio: s302m (BSSD / 0x44535342), stereo, s32 (20 bit), 2304 kb/s): unspecified sample rate
[16:47:04 CEST] <funman> ffmpeg -ar 48000 -i ird.ts
[16:47:06 CEST] <funman> Option sample_rate not found.
[16:57:29 CEST] <wm4> BtbN, philipl: again, how to update the cuvid headers? I might want to try porting libav's cuvid
[17:47:12 CEST] <nevcairiel> wm4: the two cuvid headers are mostly identical to their upstream original, only custom is the cuda one, just add functions as you need them
[17:47:46 CEST] <nevcairiel> and add new functions to dynalink_loader.h as well so they actually get loaded
[17:51:55 CEST] <wm4> ah
[19:27:37 CEST] <jamrial> so, the av_dup_packet() call in frame_thread_encoder.c
[19:28:07 CEST] <jamrial> is it really needed? can the packet it handles be non ref counted?
[19:28:36 CEST] <jamrial> coverage shows, at least as far as FATE tests, that it's currently a noop
[19:37:34 CEST] <wm4> the old encode API can give you not refcounted packets, right?
[19:37:44 CEST] <wm4> oh wait, the encoder gets AVFrames
[19:38:06 CEST] <wm4> so we're talking about output
[19:39:02 CEST] <wm4> maybe some hw codec wrappers could do it
[19:49:43 CEST] <jamrial> wm4: any idea how to replace it with av_packet_ref()? the same i did for encode.c maybe?
[19:59:47 CEST] <wm4> jamrial: yeah...
[20:00:12 CEST] <wm4> or you could av_assert0 on it being refcounted or so
[20:01:09 CEST] <wm4> tbh I don't know much about avcodec_encode_video2... there's some scary associated legacy logic with "optimized" packet allocation
[20:06:06 CEST] <cone-830> ffmpeg 03James Almer 07master:0c1ffd0aa55c: avdevice/decklink_dec: use av_packet_add_side_data()
[20:16:31 CEST] <cone-830> ffmpeg 03James Almer 07master:e91f0c4f8b3e: avdevice/decklink_dec: remove av_dup_packet() usage
[20:43:19 CEST] <cone-830> ffmpeg 03John Stebbins 07master:5d3953a5dcfd: matroskaenc: factor ts_offset into block timecode computation
[20:43:20 CEST] <cone-830> ffmpeg 03James Almer 07master:45121cbdda00: Merge commit '5d3953a5dcfd5f71391b7f34908517eb6f7e5146'
[20:44:33 CEST] <jamrial> jkqxz: i suppose libav commit 156bc0193b is unneded seeing we have similar tests?
[20:45:25 CEST] <jamrial> we don't even have the sample files in the fate suite, so yeah, gonna noop it
[20:45:55 CEST] <ubitux> shouldn't we sync them?
[20:46:30 CEST] <ubitux> that's usually what we do
[20:46:54 CEST] <jamrial> ubitux: we have like five samples and webp tests for alpha, non alpha, lossless, lossy, etc
[20:47:11 CEST] <jamrial> i don't mind syncing them, but seems superfluous in this case
[20:47:19 CEST] <ubitux> ok ok
[20:48:26 CEST] <jkqxz> Yeah, that one was just added as a generic alpha test (it's one of the google exmaple files).  There are others in ffmpeg so it isn't needed.
[20:50:52 CEST] <jamrial> ubitux: btw, coverage.ffmpeg.org suddenly stopped having src/ in the path. looks like it started after the merge moving the cli programs to a separate folder
[20:51:09 CEST] <jamrial> could it be because there are no more files being checked in the root?
[20:58:08 CEST] <cone-830> ffmpeg 03Mark Thompson 07master:156bc0193bd4: fate: Add webp alpha test
[20:58:09 CEST] <cone-830> ffmpeg 03James Almer 07master:ff29db4ebf22: Merge commit '156bc0193bd47d3f4b3adaa93be0e206e12686ab'
[21:01:47 CEST] <cone-830> ffmpeg 03John Stebbins 07master:fec3456ce188: fate: Update fate-lavf-mkv after commit 5d3953a5dc
[21:01:48 CEST] <cone-830> ffmpeg 03Luca Barbato 07master:04d2afa93b6c: mkv: Update the seek test to match 5d3953a5dc
[21:01:49 CEST] <cone-830> ffmpeg 03James Almer 07master:0451c3db4ee2: Merge commit '04d2afa93b6c6f320ac45dd99ce1226f3c3d5ac8'
[21:02:17 CEST] <ubitux> jamrial: maybe& is it causing issues?
[21:02:52 CEST] <jamrial> don't think so, just unexpected i guess
[21:05:26 CEST] <ubitux> yeah, interesting
[21:06:58 CEST] <cone-830> ffmpeg 03Diego Biurrun 07master:ed6a891c364f: Place attribute_deprecated in the right position for struct declarations
[21:06:59 CEST] <cone-830> ffmpeg 03James Almer 07master:f40cd7899188: Merge commit 'ed6a891c364f8b0850b557d9578b8920cc15a937'
[21:15:19 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:c582cb853736: arm/aarch64: vp9lpf: Keep the comparison to E within 8 bit
[21:15:21 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:3bf9c48320f2: aarch64: vp9lpf: Use dup+rev16+uzp1 instead of dup+lsr+dup+trn1
[21:15:21 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:575e31e931e4: arm: vp9lpf: Implement the mix2_44 function with one single filter pass
[21:15:22 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:402546a17233: arm: vp9itxfm: Avoid reloading the idct32 coefficients
[21:15:23 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:65aa002d5443: aarch64: vp9itxfm: Avoid reloading the idct32 coefficients
[21:15:24 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:de06bdfe6c8a: arm: vp9itxfm: Reorder the idct coefficients for better pairing
[21:15:25 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:09eb88a12e00: aarch64: vp9itxfm: Reorder the idct coefficients for better pairing
[21:15:27 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:08074c092d8c: arm: vp9itxfm: Reorder iadst16 coeffs
[21:15:28 CEST] <cone-830> ffmpeg 03Martin Storsjö 07master:b8f66c0838b4: aarch64: vp9itxfm: Reorder iadst16 coeffs
[21:15:29 CEST] <cone-830> ffmpeg 03James Almer 07master:9f5d238a66ea: Merge commit 'b8f66c0838b4c645227f23a35b4d54373da4c60a'
[21:17:25 CEST] <jamrial> ubitux: commit 8e4d4efc67 adds a test we don't have and probably could use. how do we sync the sample?
[22:41:57 CEST] <ubitux> jamrial: you should poke nevcairiel or michaelni 
[22:42:08 CEST] <jamrial> ah ok
[22:43:18 CEST] <jamrial> michaelni, nevcairiel: does the test from libav commit 8e4d4efc67 have any use for us? i don't know if we ever had that regression to begin with
[22:43:51 CEST] <jamrial> if it does, please add the sample to the fate sample suite so i may merge the commit
[22:55:22 CEST] <jamrial> michaelni, nevcairiel: https://pastebin.com/raw/9MHbLgqJ uh, guess no point adding it? we can't even decode it...
[23:00:13 CEST] <jamrial> ah, yet another edit list regression i guess
[23:00:27 CEST] <jamrial> -ignore_editlist 1 passed to the demuxer fixes it
[23:02:00 CEST] <jamrial> what then? do we add the sample and merge the test forcing that option for the time being, and report it to Sasi Inguva to look at it?
[23:03:39 CEST] <michaelni> repoting the issue to  Sasi Inguva is probably a good idea either way
[23:03:44 CEST] <JEEB> agreed
[23:04:09 CEST] <thebombzen> re: stripping issue, how does stripping at install-time affect cross-compiling? If you're thinking about /usr/bin/install -s then it might have issues with cross-compilation
[23:04:31 CEST] <JEEB> I am still kind of the opinion that the demuxer just can't handle edit lists by itself, as the spec itself notes (Since the edits can be on sample level etc)
[23:04:43 CEST] <BtbN> thebombzen, why would it be any different from stripping at build time?
[23:05:04 CEST] <BtbN> The cross compiler/stripper won't be gone by then
[23:05:10 CEST] <JEEB> you would expose the edit list from the demuxer and then the upper layer would then use the demuxer and decoder to present the edit list
[23:05:19 CEST] <thebombzen> stripping at build-time during cross-compilation can use arch-vendor-platform-strip
[23:05:26 CEST] <JEEB> but it seems like this train went past way before :)
[23:05:39 CEST] <thebombzen> stripping at install-time might use /usr/bin/install -s, which might not be able to find the right stripper
[23:05:46 CEST] <thebombzen> if it can, then ignore me. but I've had issues where it can't in the past
[23:06:06 CEST] <jamrial> thebombzen: not using -s, if you're talking about my patch
[23:06:30 CEST] <thebombzen> I'm worried more about /usr/bin/install -s during cross-compilation, not about actually stripping at install-time
[23:06:42 CEST] <thebombzen> so if your patch avoids that then I have no worries
[23:06:58 CEST] <thebombzen> my opinion doesn't exactly matter here, but I figured I'd point this out
[23:07:19 CEST] <jamrial> we never use install -s anyway, before or after the patch
[23:07:55 CEST] <thebombzen> hey, at least it's not libtool
[23:07:55 CEST] <jamrial> since the strip binary can be chosen at configure time with an option
[23:08:02 CEST] <JEEB> CROSS-PREFIX-strip I think by default?
[23:08:18 CEST] <thebombzen> alright, then I have no worries
[23:08:50 CEST] <thebombzen> I've just had to build something for another platform and had libtool relink in the cross-prefix into the rpath which really irritated me, so I'm a bit on edge right now about cross-compilation
[23:08:53 CEST] <jamrial> michaelni: yeah, probably opening a ticket to keep track of it as well. but my question is, is it worth adding the test and sample right now?
[23:09:13 CEST] <thebombzen> either way, if libraries are already stripped at compile-time then it sounds like a good idea, if nothing else for the sake of consistency
[23:09:22 CEST] <thebombzen> er, stripped at install-time
[23:13:44 CEST] <michaelni> jamrial, uploaded
[23:14:00 CEST] <jamrial> michaelni: ok, thanks
[23:32:08 CEST] <cone-830> ffmpeg 03Diego Biurrun 07master:8e4d4efc67e1: fate: Add another SVQ3 test to increase coverage
[23:32:09 CEST] <cone-830> ffmpeg 03James Almer 07master:b591329c3afe: Merge commit '8e4d4efc67e154fdffd65964a7cfeef740320827'
[00:00:00 CEST] --- Tue Oct  3 2017