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

[burek]

[00:57:54 CEST] <mkver> @BBB: My patchset intended to fix the error that the Matroska demuxer emits when it reaches EOF that you talked about earlier just arrived at the ML.
[01:21:50 CEST] <BBB> tnx
[01:24:10 CEST] <Lynne> I did once attempt to implement CRC checking for matroskadec but everything was so abstracted it was impossible
[01:24:48 CEST] <mkver> Yeah, I don't see a way to implement this either.
[01:38:13 CEST] <cone-646> ffmpeg 03Steven Liu 07master:14c58c6acaa1: Revert "doc/filters: update URL for sr filter script repository"
[01:38:15 CEST] <cone-646> ffmpeg 03Steven Liu 07master:81acc9adbfef: doc/filters: update URL for sr filter script repository
[06:11:00 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:359d4e10a07d: avformat/dashenc: use 64bit for handling the return of avio_tell()
[06:32:05 CEST] <cawk> ffmpeg -f lavfi -i "movie=test.mkv[out+subcc]" -map 0:1 output.srt    extracts all the text but timing is all wrong:   should i report this as a bug?
[09:39:03 CEST] <cone-757> ffmpeg 03Gyan Doshi 07master:c3458f06f406: doc/scaler: indicate some options as API only.
[11:49:07 CEST] <nevcairiel> whats going on with steven liu and his constant reverts in the history
[11:51:07 CEST] <durandal11707> raise question on ML
[15:53:44 CEST] <cone-702> ffmpeg 03Jun Zhao 07master:206f72d0f2a9: libavdevice/gdigrab: fix ffmpeg -devices doesn't show gdigrab
[16:09:04 CEST] <dlevin> Hi, could I get some input on https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244101.html ? That would be great :)
[16:09:39 CEST] <dlevin> The AVCodecParameters codec_tag is documented as an AV fourcc and mpegts.c is (IMO) breaking that contract by populating it with a PES stream_type
[16:23:27 CEST] <durandal11707> dlevin: there is already input for that patch
[16:25:30 CEST] <nevcairiel> even if what mpegts sets there is "wrong", setting mov tags is even mroe wrong and will never be accepted
[16:25:48 CEST] <nevcairiel> those are entirely unrelated
[16:37:08 CEST] <cehoyos> nevcairiel: Concerning ticket 7891 (too much seeking in badly inleaved mp4 files) - isn't it possible to increase a buffer to avoid the seeking?
[16:41:01 CEST] <nevcairiel> theoretically increasing the avio buffer can help
[16:41:06 CEST] <nevcairiel> not sure if it also does in practice
[16:42:41 CEST] <nevcairiel> but i dont think we have any expose command line options to modify it
[16:52:03 CEST] <cehoyos> I was wondering where in the code I can test if increasing the buffer could help - do you know where?
[16:55:44 CEST] <nevcairiel> look f or the IO_BUFFER_SIZE define, i guess
[16:56:07 CEST] <nevcairiel> in aviobuf.c
[16:56:46 CEST] <dlevin> @nevcairiel Wouldn't it be reasonable to have a mapping in mpegts where we map stream_type to a fourcc and set it in the codec_tag ?
[16:57:00 CEST] <nevcairiel> Why?
[16:57:11 CEST] <nevcairiel> This should be container provided information, not something we invented.
[16:57:26 CEST] <nevcairiel> It sounds to me like you are trying to fix something unrelated to mpegts, and just shoe-horning it in there
[17:02:15 CEST] <dlevin> I don't see why we couldn't have a fourcc in there. If you look at the HLS spec for instance, they use RFC6381 for declaring codecs for a given renditions.
[17:02:45 CEST] <dlevin> HLS is using MPEG2TS a lot, and RFC6381 depends on the fourcc
[17:03:26 CEST] <dlevin> So if ffmpeg tells me I can use this field to generate a RFC6381 string, I would expect it to give me the right value
[17:04:05 CEST] <dlevin> And right now it's not.
[17:10:22 CEST] <dlevin> If there is a desire to have container specific info, then perhaps it would be worth introducing a new field for it.
[17:17:17 CEST] <nevcairiel> There is numerous fourcc-style standards, which are all incompatible to a degree, so trying to expect that these are compatible with any particular standard is just not going to happen
[17:17:30 CEST] <nevcairiel> As such, the field is simply filled with container-provided information and not anything else
[17:23:52 CEST] <cone-702> ffmpeg 03Werner Robitza 07master:b99c73abf4b9: doc/scaler: explain values for src_range, dst_range
[17:42:33 CEST] <dlevin> @nevcairiel then there should probably be a container enum so it can be interpreted by a library client
[17:43:53 CEST] <dlevin> @durandal11707 I know, I was simply looking for someone else perspective.
[17:49:32 CEST] <cone-702> ffmpeg 03James Almer 07master:3f31726994f6: avcodec/options: remove dead test code
[17:54:27 CEST] <Lynne> vgatherdpd is 59% slower for 128bit regs and 10% slower for 256bit regs than doing manual loads
[17:55:33 CEST] <Lynne> at least vgatherdps is faster than doing individual 32 bit loads but duplicating indices to emulate vgatherdpd is still slower than vgatherdpd
[17:57:40 CEST] <Lynne> however for very large lookups (4096x64 bits) vgatherdpd is faster than individual loads, but that's in a tight loop with nothing but looking up and storing
[19:10:28 CEST] <cone-702> ffmpeg 03Paul B Mahol 07master:96c79d4e1fd8: avfilter/vf_ocr: also export confidence of result
[20:10:31 CEST] <cawk> ffmpeg -f lavfi -i "movie=test.mkv[out+subcc]" -map 0:1 output.srt    extracts all the text but timing is all wrong:   should i report this as a bug?
[21:27:13 CEST] <BBB> durandal11707: stop this
[21:28:19 CEST] <durandal11707> only if N.G. stops
[23:37:18 CEST] <Lynne> the avx fft is not as optimized as people think it is, and it shows after not being touched since it was merged in 2011
[23:38:10 CEST] <Lynne> 10/21 instructions are shuffles when you really only need 6, and I think I can get rid of 1 more as well
[23:38:50 CEST] <Lynne> 2 of them are cross-lane vpermps which are unnecessary since you only need cross-lane interaction at the last stage when outputting
[23:39:36 CEST] <Lynne> and then its just a vextractf128
[23:40:14 CEST] <Lynne> this is for an 8-point one so the basis for all higher transforms
[00:00:00 CEST] --- Sat May 18 2019