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

[burek]

[01:50:31 CET] <cone-901> ffmpeg 03Carl Eugen Hoyos 07master:9bcd40c29804: lavc/decode: Initialize return value for get_format() failure.
[02:20:19 CET] <cone-901> ffmpeg 03Carl Eugen Hoyos 07master:de441ad52a4d: lavc/cbs_vp9: Make variable prob unsigned.
[04:25:04 CET] <cone-901> ffmpeg 03Linjie Fu 07master:1c96d2e3998b: lavc/qsvenc: replace assert with error return
[07:20:44 CET] <cone-901> ffmpeg 03Karthick J 07master:56503a692534: avformat/hlsenc: Handled error from ff_http_do_new_request() function
[07:20:45 CET] <cone-901> ffmpeg 03Karthick J 07master:234926033097: avformat/hlsenc : Added an option to ignore IO errors
[08:28:08 CET] <cone-901> ffmpeg 03Jun Zhao 07master:a27102521552: lavfi/vf_scale_vaapi: add scaling mode setting support.
[11:37:53 CET] <cone-064> ffmpeg 03Paul B Mahol 07master:8f66d46ce5f4: avcodec: add gif parser
[11:37:53 CET] <cone-064> ffmpeg 03Paul B Mahol 07master:eade85bbbd93: avformat: add gif pipe demuxer
[12:02:43 CET] <thardin> looking at fate, are there no tests for encoders/muxers?
[12:06:29 CET] <thardin> acodec.mak has some
[12:29:24 CET] <thardin> there we go
[17:35:09 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:49d792fff62e: avcodec/proresdec2: allow changing resolution
[17:35:09 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:5e0d54a031e3: avformat/mxfenc: allow muxing prores
[17:38:17 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:14156e607d49: avformat/mxfenc: calculate and store DAR from user SAR
[17:47:29 CET] <durandal_1707> why mxf muxer hardcodes aspect ratio for some codecs?
[17:58:48 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:8affd753c86d: avcodec/gifdec: truncate too big width/height for invalid gif files
[18:45:33 CET] <durandal_1707> ubitux: are you working on gif transparency patch?
[18:52:57 CET] <ubitux> durandal_1707: n
[18:52:59 CET] <ubitux> no
[19:01:10 CET] <gnafu> The saga continues.
[19:04:49 CET] <durandal_1707> ubitux: i want to fix muxer & encoder so -c copy works, mainly allowing encoder to write extension and muxer to modify only delay in it, is this sane to you?
[19:06:41 CET] <ubitux> durandal_1707: you mean moving part of the header from the muxer to the encoder?
[19:08:41 CET] <durandal_1707> ubitux: yea, demuxer (and parser) only split gif stream, and extension comes with image block, while muxer extracts stuff breaking -c copy
[19:09:24 CET] <ubitux> what happens to let's say, the loop option?
[19:09:34 CET] <ubitux> does it stays on muxer side or does it end up in the encoder?
[19:09:46 CET] <ubitux> what about the palette?
[19:10:04 CET] <durandal_1707> loop option is overwritten by muxer
[19:10:43 CET] <durandal_1707> local palette do not need to be exported any more ...
[19:11:18 CET] <ubitux> ok well it sounds good on the paper
[19:11:46 CET] <ubitux> i remember thinking about this but gave up due to packet format change between libs, requiring to bump everything
[19:12:00 CET] <ubitux> or make extra random check for synchronicity
[19:12:12 CET] <ubitux> the usual pita coming from multiple libs with different versions
[19:12:32 CET] <durandal_1707> that was never supported
[19:13:29 CET] <durandal_1707> main reason is to make -c copy working and to not need disposal exported from encoder as side data to muxer
[19:14:15 CET] <ubitux> well if this politic wrt lib async is official, i can probably dig a lot of shit to submit
[19:14:37 CET] <durandal_1707> what shit?
[19:14:49 CET] <ubitux> iirc i had that issue with at least some subtitles
[19:15:03 CET] <ubitux> iirc it was applied with random workaround
[19:15:18 CET] <ubitux> like trying to detect which format it was reading the payload
[19:15:28 CET] <ubitux> and take different codepath according to it
[19:15:40 CET] <ubitux> i had to do that several times in the past
[19:15:49 CET] <ubitux> not sure if i pushed everything
[19:16:41 CET] <durandal_1707> nothing test async versions and claiming async should be supported and reason for not cleaning stuff is very bad and ugly
[19:19:17 CET] <durandal_1707> what means "comply retroactively to terms of GPL" ? to send complete source code?
[19:20:09 CET] <JEEB> yes. the whole binary and everything it is dependant on ("derivative work" of)
[19:25:36 CET] <kierank> as if he's going to do that
[19:27:08 CET] <JEEB> if that was part of his reply then in his mind it was mostly about just releasing the FFmpeg etc OSS software's code for his binary, and hope that it passes through
[20:00:18 CET] <atomnuker> "We also use #Slack and host VAAPI Media Slack Team. You can signup by submitting your email address to our Slack Team invite page."
[20:00:44 CET] <atomnuker> wow, I didn't expect to see that in any readme yet, even on an intel open source project
[20:02:11 CET] <durandal_1707> atomnuker: answer me!
[20:08:24 CET] <atomnuker> yeah, I'm not playing anything atm.
[20:09:16 CET] <durandal_1707> you should (cos)play spiderman, kierank says its assom
[20:09:34 CET] <JEEB> the new spider-man seemed alright
[20:59:51 CET] <cone-156> ffmpeg 03Carl Eugen Hoyos 07master:fe300b2ab5d1: lavc/xpmdec: Allow more colours per character.
[21:41:25 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:6a20876b6203: avformat/gif: simplify signature writing
[21:41:26 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:00502370f6be: avcodec/xpmdec: fix small artifacts
[21:41:27 CET] <cone-156> ffmpeg 03Paul B Mahol 07master:03beac5b97e8: avcodec/xpmdec: define constants
[00:00:00 CET] --- Tue Dec 11 2018