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

[burek]

[00:10:07 CEST] <cone-754> ffmpeg 03Jun Zhao 07master:462568185b0a: kmsgrab: Fix build failure with old libdrm
[00:10:07 CEST] <cone-754> ffmpeg 03Jun Zhao 07master:197d298ab3b2: hwcontext_vaapi: Fix build failure with old libdrm
[02:47:33 CEST] <cone-754> ffmpeg 03Kaustubh Raste 07master:f692e55aab79: avcodec/mips: Improve hevc lpf msa functions
[02:47:34 CEST] <cone-754> ffmpeg 03Kaustubh Raste 07master:c6314cd750df: avcodec/mips: Improve hevc idct msa functions
[02:47:35 CEST] <cone-754> ffmpeg 03Thierry Foucu 07master:eea64ef4cfb5: vf_fps: when reading EOF, using current_pts to duplicate the last frame if needed.
[05:19:39 CEST] <kode54> nice
[05:19:55 CEST] <kode54> I made a 3 line patch to FFmpeg CAF handler to add support for Opus
[05:20:12 CEST] <kode54> verified working on High Sierra dev beta 9, will test GM seed once I have updated my primary install to that
[05:20:43 CEST] <kode54> unfortunately, Apple's own encoder appears to be limited to producing mono streams
[05:20:47 CEST] <kode54> using afconvert to encode
[05:21:06 CEST] <kode54> whereas QuickTime does manage to play back stereo streams that I've remuxed using the patched FFmpeg
[05:26:45 CEST] <jamrial> kode54: odd, someone else was able to make stereo opus caf files using afconvert i remember
[05:26:52 CEST] <kode54> strange
[05:26:57 CEST] <kode54> I don't know what settings to use for that, then
[05:27:07 CEST] <kode54> maybe I need to mess with the channel layout parameter
[05:27:24 CEST] <kode54> I do know that the OS and QuickTime accept my FFmpeg muxed file
[05:27:58 CEST] <jamrial> what did you put in the kuki chunk?
[05:28:20 CEST] <kode54> 'o','p','u','s'
[05:29:10 CEST] <kode54> afconvert lists the codec ids it supports, and requires them as the parameter for encoding
[05:29:25 CEST] <jamrial> i'm not talking about the codec tag. the kuki chunk, where most other codecs put extradata
[05:29:27 CEST] <kode54> they also support reading flac
[05:29:30 CEST] <kode54> oh
[05:29:37 CEST] <kode54> I didn't touch that
[05:29:46 CEST] <kode54> presumably it got the same extradata as the ogg stream
[05:29:59 CEST] <jamrial> it's not, i already checked that
[05:30:02 CEST] <kode54> oh
[05:30:03 CEST] <kode54> weird
[05:30:11 CEST] <kode54> I'll check what's in the file I converted with afconvert
[05:30:23 CEST] <jamrial> any opus file you're creating is not really compliant, then
[05:30:26 CEST] <jamrial> even if quicktime reads it
[05:30:43 CEST] <jamrial> it contains a bunch of values related to the stream. i was able to figure a few but not all
[05:31:09 CEST] <kode54> the file I encoded has
[05:31:11 CEST] <kode54> 00 00 08 00 00 00 BB 80 00 00 03 C0 FF FF FC 18 00 00 00 01 00 00 00 00 00 00 00 00
[05:31:53 CEST] <jamrial> things like sample rate, channel count (not layout), frames per packet, etc, are in there
[05:31:57 CEST] <kode54> not sure what the 2048 is there for, bb80 is the sample rate, 3c0 is the samples per frame, 01 is the channels
[05:32:01 CEST] <jamrial> but other values i have no idea what the represent
[05:32:42 CEST] <kode54> weird, QuickTime accepted the other file without a kuki chunk
[05:32:57 CEST] <jamrial> fffffc18 is -1000
[05:33:16 CEST] <kode54> maybe that's the start of stream delay
[05:33:53 CEST] <jamrial> it never seems to change. other files i've seen encoded with afconvert also set that exact value
[05:33:59 CEST] <kode54> huh
[05:34:47 CEST] <jamrial> until apple releases some spec, i'm going to assume it's unfinished and ignored by even their own software, as you were able to confirm with quicktime
[05:35:30 CEST] <jamrial> in any case, I'd not allow the muxer to create such files. better not spread potentially non compliant files if possible
[05:57:00 CEST] <TD-Linux> kode54, documentation of what you've found so far would still be really useful. I've wanted to make a JS side CAF remuxer for browser support.
[05:57:14 CEST] <kode54> nice
[05:57:35 CEST] <kode54> they also support FLAC files in QuickTime
[05:57:57 CEST] <kode54> I haven't tried converting to FLAC with afconvert, though
[05:58:15 CEST] <kode54> naturally, iTunes doesn't support either of these formats
[06:01:30 CEST] <TD-Linux> I wonder if you can shove CAF into MSE
[06:17:50 CEST] <jamrial> TD-Linux: https://lists.libav.org/pipermail/libav-devel/2017-July/084460.html
[06:19:21 CEST] <TD-Linux> no pre-skip is pretty obnoxious (unless that's one of the unknown values)
[06:19:59 CEST] <TD-Linux> does pre-skip work? e.g. if you use afconvert to make a caf opus and back to wav, does it get longer?
[06:55:07 CEST] <kode54> TD-Linux: pre-skip works for the afconvert-encoded CAF, if it's decoded by afconvert again
[06:55:23 CEST] <TD-Linux> and end trimming?
[06:55:43 CEST] <TD-Linux> er I guess that's part of the CAF spec itself
[06:56:08 CEST] <kode54> the lengths are identical
[06:57:07 CEST] <kode54> the CAF, according to FFmpeg, appears to be one packet longer than the source audio
[13:37:41 CEST] <cone-598> ffmpeg 03Jacek Jendrzej 07master:e2f8f14052d9: lavf/http: Reset compressed header flag, fix http 302 request
[14:17:28 CEST] <JEEB> > HEIF
[14:21:30 CEST] <cone-598> ffmpeg 03Matthieu Bouron 07master:dd8ffb191fd2: lavc/mediacodec_wrapper: fix jni vaargs types
[14:22:26 CEST] <mateo`> JEEB: ^ that might fix the issues you reported a while ago about ndk >= 15 and the ffmpeg wrapper
[14:22:41 CEST] <JEEB> oh
[14:22:46 CEST] <JEEB> I did wonder for a moment
[14:22:48 CEST] <JEEB> will test
[14:23:05 CEST] <JEEB> the 64bit file pointer stuff will make me fix stuff in mpv anyways to test it, though :)
[14:23:16 CEST] <JEEB> since one of the components in mpv utilizes the define
[14:23:23 CEST] <JEEB> which used to work (with silent 32bit pointers)
[14:25:12 CEST] <mateo`> I have an issue related to that at work, they fixed the 64bit file pointer and they broke their (unified) headers
[14:26:19 CEST] <JEEB> yea, basically if you do stuff against an old enough API version you don't have the normal file pointer stuff IFF you define the 64bit define
[14:26:33 CEST] <JEEB> too bad a lot of code/build systems expect to be able to use the "make things 64bit" define
[14:27:56 CEST] <mateo`> python defines __USE_FILE_OFFSET=64, and some C++ modules includes cstdio ...
[14:28:13 CEST] <JEEB> yup :)
[14:29:19 CEST] <mateo`> rcombs: are you still working on heif support ?
[14:29:59 CEST] <mateo`> I stopped working on it when you dropped your patch on the ml
[14:49:56 CEST] <rcombs> mateo`: planning to; haven't done much since, though
[14:50:04 CEST] <rcombs> mateo`: was hoping you'd post some comments
[15:04:05 CEST] <cone-598> ffmpeg 03Clément BSsch 07master:1a08285f05c9: build: fix coreimage filters dependency to AppKit framework
[15:09:09 CEST] <cone-598> ffmpeg 03Clément BSsch 07master:674335155800: lavf/http: fix compilation without zlib
[15:09:56 CEST] <jkqxz> Ha, I was just about to send a patch for that.
[15:10:03 CEST] <jkqxz> ubitux:  Thank you!
[15:10:25 CEST] <ubitux> np :p 
[15:10:31 CEST] <JEEB> :)
[15:10:34 CEST] <ubitux> dammit asan is stalled again
[15:10:46 CEST] <ubitux> in fate-filter-fps this time
[15:10:57 CEST] <ubitux> wth does it freeze instead of failing
[15:18:01 CEST] <BtbN> sounds like a bug in asan itself?
[15:18:09 CEST] <BtbN> like, something running it into an infinite loop
[15:18:34 CEST] <ubitux> yeah, dunno
[15:18:40 CEST] <ubitux> i disabled the instance, it's pointless anyway
[15:18:49 CEST] <ubitux> valgrind spot these errors
[15:26:05 CEST] <nevcairiel> asan is good at finding errors, it just sucks at reporting them? :p
[15:30:10 CEST] <ubitux> i'm betting on our fate script being stalled in a pipe
[15:30:18 CEST] <ubitux> but i don't know..
[16:25:55 CEST] <BBB> does asan always stall on that test? or is it flaky?
[16:26:12 CEST] <BBB> if it is consistently reproducible, that may be interesting to pursue further
[16:55:59 CEST] <ubitux> BBB: yes, consistently reproducible
[16:56:04 CEST] <ubitux> ==17774==ERROR: AddressSanitizer: SEGV on unknown address 0x7f0b73d85008 (pc 0x7f0b7a95fdea bp 0x7ffffa338500 sp 0x7ffffa338068 T0)
[16:56:07 CEST] <ubitux> ==17774==The signal is caused by a READ memory access.
[16:56:09 CEST] <ubitux> and then it reads stdin
[17:07:59 CEST] <jamrial> it's the same crash as with the previous leak
[17:08:17 CEST] <jamrial> both were lavfi leaks, but it's probably an asan bug
[17:14:28 CEST] <BBB> dont forget that asan is useful for tracking stack overflows, I dont know if valgrind supports these nowadays (it didnt find them in the past)
[17:28:15 CEST] <lotharkript> ubitux: do you still have a problem with valgrind?
[17:35:31 CEST] <BBB> lotharkript: http://fate.ffmpeg.org/report.cgi?time=20170915043055&slot=x86_64-archlinux-gcc-valgrind
[17:36:14 CEST] <BBB> ==2374== 140,630 (528 direct, 140,102 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 8
[17:36:30 CEST] <lotharkript> BBB: I just tried valgrind and it works here.. I did not run the fate test, but the ffmpeg command line and it is fine.
[17:37:46 CEST] <BBB> ==134036==    definitely lost: 528 bytes in 1 blocks
[17:37:46 CEST] <BBB> ==134036==    indirectly lost: 140,102 bytes in 7 blocks
[17:37:53 CEST] <BBB> thats not fine at all ;)
[17:38:18 CEST] <BBB> it also says: ==134036== Rerun with --leak-check=full to see details of leaked memory
[17:38:28 CEST] <BBB> --track-origins=yes may be helpful also
[17:39:15 CEST] <JEEB> `--leak-check=full --track-origins=yes` is how I usually run stuff under valgrind
[17:46:23 CEST] <lotharkript> ok.. Find the leak.. Will be sending something
[17:50:31 CEST] <lotharkript> BBB: just sent a patch for it.
[17:50:42 CEST] <BBB> cool!
[17:50:53 CEST] <lotharkript> Sorry about that.
[17:50:59 CEST] <BBB> it happens
[00:00:00 CEST] --- Sat Sep 16 2017