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

[burek]

[00:00:16 CEST] <nevcairiel> i'm not sure how the exact origin of mkv came to be, but haali sure drove a lot of those features, for a long time his implementation was the only that supported any of those advanced things
[00:00:32 CEST] <atomnuker> S_TEXT/ASCII Plain text subtitles in system default character encoding <- lol
[00:00:54 CEST] <atomnuker> might as well be called S_TEXT/UTF16
[00:01:06 CEST] <nevcairiel> that wouldnt be very ascii would it
[00:01:25 CEST] <nevcairiel> unfortunately codec mapping in matroska has not improved much since the days of that pdf
[00:01:50 CEST] <nevcairiel> its the last part noone really dared to touch yet in their standardization efforts
[00:02:09 CEST] <atomnuker> isn't the vfw mode basically wrapping avi in matroska?
[00:02:51 CEST] <nevcairiel> its just a generic code for any format with a fourcc, nothing avi about it
[00:03:15 CEST] <atomnuker> I thought vfw demanded some specific order of frames or something, oh well
[00:03:44 CEST] <atomnuker> "S_TEXT/USF XML fragment containing style" <- those were a thing?
[00:03:56 CEST] <nevcairiel> i dont think i've ever seen one
[00:05:48 CEST] <wm4> they wanted it, just like DVD menus in mkv
[00:06:00 CEST] <wm4> it's lucky that some things don't happen
[00:06:04 CEST] <nevcairiel> there is still people asking for that
[00:06:06 CEST] <wm4> *luck
[00:06:14 CEST] <nevcairiel> (menus)
[00:06:15 CEST] <wm4> who? slap them
[00:06:17 CEST] <TD-Linux> they finally got ripped out of vlc 3.0
[00:06:23 CEST] <wm4> TD-Linux: ?
[00:06:25 CEST] <nevcairiel> i do that everytime its brought up
[00:06:31 CEST] <TD-Linux> dvd menu support in mkv
[00:06:52 CEST] <atomnuker> "When both lossy and correction data are muxed into the same track, correction data is stored in BlockAdditional Matroska elements and is sent in DirectShow samples with Stream ID set to 1 in sample properties" <- this exists because I hate you
[00:07:02 CEST] <wm4> TD-Linux: they had that implemented? ...
[00:07:12 CEST] <TD-Linux> wm4, yup. there was also dvd ripper software that wrote it.
[00:07:19 CEST] <nevcairiel> is that the wavpack shit? not sure that was ever done that way
[00:07:56 CEST] <atomnuker> "V_SNOW Opaque codec init data" <- SNOW!!!
[00:08:15 CEST] <TD-Linux> atomnuker, you can't escape it
[00:10:49 CEST] <jamrial> wm4: well, if you wanted the lavf matroska demuxer to be faster i did just that last night
[00:10:59 CEST] <jamrial> check the patchset if you're interested
[00:11:37 CEST] <wm4> jamrial: yeah I wanted to compare the speed once that was done
[00:12:02 CEST] <wm4> for what it's worth, mpv's demuxer also has zero-copy from the read() syscall to the decoder, but that didn't make it much faster
[00:12:12 CEST] <jamrial> and would derek's timeline wip address the missing ordered chapter stuff?
[00:12:15 CEST] <wm4> (only if there's no parsing)
[00:12:19 CEST] <nevcairiel> demuxing speed is rarely a huge concern
[00:12:34 CEST] <wm4> jamrial: as far as mpv is concerned, probably yes
[00:12:37 CEST] <jamrial> well, it was doing a lot of memcpy for no reason
[00:13:00 CEST] <jamrial> as i stated in the patch, mastroska_parse_frame() is 10x faster by removing said memcpys
[00:13:07 CEST] <nevcairiel> I apply the timeline in the demuxer because anything else would be insanity for directshow, so probably not - also, it works, so why change
[00:13:09 CEST] <wm4> here's a slightly outdated list of things https://github.com/mpv-player/mpv/wiki/libavformat-mkv-checklist
[00:13:48 CEST] <nevcairiel> mkv is also extra-troublesome because the timeline can  contain multiple files
[00:14:38 CEST] <wm4> yes, we'd need to export the per timeline segment UUIDs
[00:22:22 CEST] <cone-031> ffmpeg 03Carl Eugen Hoyos 07master:233f52fd2534: lavf/amr: Stricter heuristic for auto-detection.
[01:02:05 CEST] <atomnuker> jdarnley: forgot you were a republican
[01:10:21 CEST] <daddesio> is what I'm doing with avpkt->duration okay? https://pastebin.mozilla.org/9082401
[01:10:27 CEST] <daddesio> see line 370
[01:10:41 CEST] <daddesio> and 387
[01:28:46 CEST] <kierank> atomnuker: sorry but you shouldn't criticise people for their licence choice, this is exactly what libav did and pissed people off.
[01:29:54 CEST] <atomnuker> I know, I know, just joking
[01:30:10 CEST] <atomnuker> GPL is a perfectly sane choice for an encoder
[01:32:45 CEST] <wm4> libav did?
[02:26:42 CEST] <cone-031> ffmpeg 03Bela Bodecs 07master:e54679b6c1de: doc/filters: some more details and modified example to zmq/azmq
[03:58:43 CEST] <kierank> wm4: yes but I won't drag up history
[05:44:14 CEST] <rcombs> how fast is vf_colorspace anyway
[05:46:43 CEST] <rcombs> wondering how hard it would be to incorporate integer HDR->SDR tone mapping, looks like the hardest part is probably the multi-variable-sensitive division
[06:08:49 CEST] <jamrial> rcombs: shouldn't be too slow, seeing BBB wrote asm for it
[07:57:12 CEST] <mistym> Chloe: The Cinepak encoder is really slow, yeah. IIRC the submitter commented to that effect; there doesn't seem to have been much attempt at focusing on performance
[07:57:19 CEST] <mistym> Speed does improve if you set it to single-strip mode though
[09:37:32 CEST] <durandal_1707> wtf, this cargo building for rust projects is piece of shit, it can not resume it at all
[09:44:00 CEST] <durandal_1707> i builded it , gonna insall it - it recompile from stratch again, PoS
[13:55:47 CEST] <kierank> jdarnley: if you are bored you can look at https://trac.ffmpeg.org/ticket/6815#comment:9
[13:56:13 CEST] <kierank> as usual a libav merge breaks h264
[13:58:33 CEST] <jdarnley> fun!
[13:58:54 CEST] <jdarnley> sorry 
[13:59:01 CEST] <jdarnley> I mean...
[13:59:05 CEST] <jdarnley> fun(!)
[14:26:34 CEST] <nevcairiel> chunk mode should just be deprecated and removed
[14:28:53 CEST] <wm4> I think kierank is interested in it, for reasons
[14:29:05 CEST] <kierank> low latency
[14:29:17 CEST] <nevcairiel> you need to wait for the full frame anyway, dont you
[14:29:27 CEST] <kierank> no
[14:29:34 CEST] <kierank> you can start decoding slices as they arrive
[14:29:47 CEST] <wm4> that assumes multiple slices, right
[14:29:56 CEST] <kierank> sure
[14:30:00 CEST] <wm4> (so still waiting for full slices)
[14:30:35 CEST] <nevcairiel> that is a extremely minimal latency difference, since that just allows you to start decoding sooner, it doesnt reduce decode delay or anything like that
[14:30:35 CEST] <kierank> predicated on having slices just like sliced threads decoding, yes
[14:30:42 CEST] <kierank> nevcairiel: yes it does
[14:30:50 CEST] <kierank> the frame is done during the 40ms arrival
[14:31:08 CEST] <kierank> whereas normal mode you need to wait 40ms for frame to arrive then ~40ms for the frame to decode
[14:31:26 CEST] <nevcairiel> why is your decoder so slow that it takes 40ms
[14:31:33 CEST] <wm4> also reequires using that draw slice callback
[14:31:34 CEST] <kierank> you have to wait for the upper bound
[14:31:47 CEST] <kierank> 20ms then if you want
[14:32:23 CEST] <nevcairiel> at best you can save most of that decode time, the time to wait for arrival is practically the same
[14:32:35 CEST] <kierank> eh? you save 20ms
[14:32:59 CEST] <kierank> and you can start rendering your slices into their output buffer
[14:33:29 CEST] <kierank> so in fact I can cut latency down to 1 slice duration
[16:02:03 CEST] <durandal_1707> Compn: you hadn't commented on vivo siren codec at all, i'm very sad now
[16:36:23 CEST] <Compn> durandal_1707 : nice
[17:10:59 CEST] <durandal_1707> atomnuker: what's status of nonpower of 2 even fft?
[18:19:29 CEST] <jamrial> michaelni: could you force the usage of yasm in your freebsd fate clients?
[18:19:35 CEST] <jamrial> whatever nasm is present in that system is clearly broken, because that same version in other targets is working fine
[18:21:36 CEST] <jamrial> the x86_64 freebsd ones, i mean. the x86_32 (kfreebsd/debian) are working fine
[18:32:11 CEST] <michaelni> that freebsd box has NASM version 2.11.06 compiled on Oct 23 2014, kfreebsd one is NASM version 2.10.01 compiled on Jun 14 2012
[18:32:15 CEST] <michaelni> so they arent the same
[18:36:38 CEST] <michaelni> ill try to build ffmpeg outside fate on that box to see what happens
[18:43:27 CEST] <michaelni> libavutil/x86/x86inc.asm:45: error: symbol `HAVE_ALIGNED_STACK' not defined before use
[18:47:03 CEST] <jamrial> michaelni: i mean that i tried 2.11.06 on a different machine some time ago and it didn't behave like this
[18:47:53 CEST] <jamrial> and that looks different. the error in the fate client logs says something like libavutil/x86/x86inc.asm can't be found
[18:52:55 CEST] <michaelni> i guess then theres something wrong with that nasm on freebsd.
[18:53:12 CEST] <michaelni> configure probably should detect this unless its just my box
[18:54:04 CEST] <jamrial> config.asm (which defines that symbol among others) should be included as part of the nasm command line
[18:54:27 CEST] <jamrial> try to run with V=0 to see what arguments are being passed to nasm
[18:54:31 CEST] <michaelni> yes, there was a -Pconfig.asm
[18:54:44 CEST] <michaelni> i already tried -p -P with and without space
[18:54:57 CEST] <michaelni> and also tried placing it at different positions
[18:55:01 CEST] <michaelni> no luck
[18:55:43 CEST] <jamrial> :/
[18:56:01 CEST] <michaelni> libavcodec/h264_slice.c:2765:36: error: incompatible types when assigning to type 'atomic_int' from type 'int'
[18:56:28 CEST] <michaelni> yasm builds that asm though
[18:56:52 CEST] <michaelni> also nasm gave a different error if the file doesnt exist so it does not totally ignore it
[19:00:50 CEST] <jamrial> wth is with that atomic_int error? for this system, the wrapper literally makes it "typedef int atomic_int"
[19:01:40 CEST] <jamrial> unless that was in the 4.9 one?
[19:02:52 CEST] <jamrial> in which case it's not the wrapper, and the native atomics in that compiler may be pedantic about the line being "sl->er.error_count = 0;" instead of using atomic_store(), i don't know
[19:04:42 CEST] <wm4> no, C11 atomics allow direct access to atomics (and they will be atomic)
[19:04:49 CEST] <wm4> another C11 misdesign
[19:04:56 CEST] <wm4> making them opaque would be better
[19:06:54 CEST] <michaelni> jamrial, i used 4.8 in that attempt
[19:07:47 CEST] <michaelni> btw failing nasm command for reference: nasm -f elf64 -g -F dwarf -I./ -I.// -Ilibavfilter/x86/ -Pconfig.asm -MD libavfilter/x86/af_afir.d  -o libavfilter/x86/af_afir.o libavfilter/x86/af_afir.asm
[19:13:44 CEST] <jamrial> in tree build?
[19:17:01 CEST] <jamrial> if this command line was made using tests/fate.sh then it should be an out of tree build, which would mean something may be wrong in the build system
[19:21:48 CEST] <michaelni> in tree build
[19:22:37 CEST] <jamrial> then that nasm is probably broken
[19:22:46 CEST] <michaelni> yes it appears so
[19:22:51 CEST] <jamrial> did any of the configure tests for x86 extensions succeed?
[19:22:59 CEST] <jamrial> avx2, xop, etc
[19:23:25 CEST] <michaelni> iam still trying to find something that works, gcc 46 47 48 fail the atomics, trying 49 now
[19:23:59 CEST] <nevcairiel> those old gccs should not have the atomics header, should they?
[19:24:10 CEST] <jamrial> no, but we have the wrapper
[19:24:32 CEST] <jamrial> and for some reason it's complaining that atomic_int is not int, even if we typedef'd it as such
[19:24:34 CEST] <michaelni> the wraper seemed not enabled where i looked
[19:26:52 CEST] <michaelni> also the compiler maybe doesnt have the header but that doesnt mean that no such header would be on the system
[19:34:33 CEST] <jamrial> according to https://gcc.gnu.org/wiki/C11Status stdatomic.h should be present only from 4.9 onwards
[19:34:59 CEST] <michaelni> jamrial, gcc49 suceeded building with yasm
[19:35:07 CEST] <jamrial> if configure finds a header named like that when using 4.8 then that environment is dirty...
[19:35:12 CEST] <jamrial> cool
[19:35:56 CEST] <michaelni> there is /usr/include/stdatomic.h on the freebsd box
[19:38:19 CEST] <jamrial> and i guess it's complete enough that the configure check considers it valid...
[19:43:15 CEST] <nevcairiel> yeah those headers should be in a compiler folder, who knows what bsd does there
[19:59:46 CEST] <jamrial> michaelni: does https://pastebin.com/qt6wBHG8 make configure reject that header?
[20:01:11 CEST] <michaelni> jamrial, iam atm testing "check_builtin stdatomic stdatomic.h "atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); foo += bar"
[20:01:22 CEST] <michaelni> dunno if = 0 is enough
[20:01:42 CEST] <jamrial> michaelni: bar is also atomic_int, and the error above complained about using an int (a 0)
[20:09:09 CEST] <michaelni> foo += bar makes it build with gcc48
[20:09:12 CEST] <michaelni> ill try = 0
[20:11:38 CEST] <michaelni> config.mak output looks good so it should work too
[20:12:48 CEST] <jamrial> both made the native stdatomic configure check fail? so it doesn't like direct access of any kind
[20:13:51 CEST] <jamrial> in any case, commit whichever you prefer (and that works as expected in other systems, too :p)
[21:37:39 CEST] <jamrial> rcombs: btw, can you look at Timo Tera's comment in the flac coverart patch?
[21:50:26 CEST] <rcombs> jamrial: it's kind of along the lines of the muxer setting AVStream::codecpar::extradata
[21:50:48 CEST] <rcombs> I think it's probably fine, and it simplifies things a bit, but some people have conceptual problems with it
[21:51:44 CEST] <jamrial> yeah, i don't like it. using it as temporary store is wrong
[21:51:52 CEST] <jamrial> that's why muxers have their own private contexts
[21:52:40 CEST] <rcombs> does AVStream have a field a muxer can use for a private store?
[21:52:55 CEST] <rcombs> rather than having its own internal array
[21:53:36 CEST] <JEEB> right, I have had that question pop up in my mind as well
[21:53:51 CEST] <JEEB> for example if a muxer can name streams, I would like to define those per-stream
[21:54:00 CEST] <JEEB> instead of how f.ex. hls muxer does the multiple versions
[21:54:18 CEST] <rcombs> I always worry a little bit about these arrays, particularly around what happens if the user adds a stream mid-mux
[21:54:51 CEST] <jamrial> there seems to be AVStream->priv_data
[21:54:58 CEST] <rcombs> is that for the user or the muxer?
[21:55:42 CEST] <jamrial> i don't know. i'm not sure if it's used at all
[21:55:59 CEST] <jamrial> maybe by the generic code, because i can't find it used directly by demuxers and muxers
[21:57:07 CEST] <jamrial> avformat_new_stream() doesn't even do anything with it
[22:06:06 CEST] <jamrial> rcombs: seems to be used by a couple demuxers, like avi
[22:08:23 CEST] <jamrial> so if avformatcontext->priv_data for per stream private fields is disliked, there's always that
[22:08:45 CEST] <durandal_1707> one dude from vlc, nacked every single patch on ml
[22:09:44 CEST] <jamrial> durandal_1707: ?
[22:13:03 CEST] <kurosu> I read that as naked and... I'll stop here.
[22:13:49 CEST] <rcombs> jamrial: cool, good to know
[22:15:45 CEST] <fabled_> jamrial, rcombs : i was not aware that AVStream could not be used by muxer. there are some other fields that are used like that but not many. and since it's named like that, it made sense to reuse attached_pic as temporary store.
[22:16:09 CEST] <jamrial> uh, it can
[22:16:10 CEST] <fabled_> it also would've allowed shared code for easily. happy to rework my patch if needed.
[22:16:27 CEST] <rcombs> jamrial: written to, specifically
[22:16:30 CEST] <jamrial> but using a field like attached_pic as temporary store is not a good idea
[22:16:40 CEST] <jamrial> that's why muxers have private contexts
[22:17:49 CEST] <fabled> jamrial, is it visibility user issue? or just some convention on what AVStream should contain?
[22:18:30 CEST] <JEEB> generally muxer-specific things go into the muxer where it can have its own data storage
[22:18:54 CEST] <fabled> attached_pic sort of applies to several other muxers too
[22:19:09 CEST] <jamrial> it's mostly that muxers should not modify input, like codecpar
[22:19:32 CEST] <fabled> that's why i was even suggesting to have mux.c stuff the picture to AVStream by default or by some flag
[22:19:57 CEST] <fabled> on demux path it's technically also used for temporary store
[22:21:29 CEST] <fabled> i understand not changing codecpar or any other field that is input parameter
[22:21:41 CEST] <fabled> but attached_pic is in neither in muxing or demuxing set by caller
[22:22:12 CEST] <jamrial> mmh, making the generic code (mux.c) write to attached_pic sounds better than having muxers do it, yes
[22:22:51 CEST] <fabled> i guess that would need to be muxer specific flag or similar; some muxers can injecting it any place in the output, where as the .mp4 one always puts it to the end
[22:23:40 CEST] <fabled> but both flac and mp4 now would benefit from it. having mux.c ref it in AVStream + pass it to write func
[22:24:09 CEST] <jamrial> to be honest, the way some muxers take any kind of video and try to shove that as cover art is pretty ugly
[22:24:23 CEST] <fabled> i was looking hard for muxers that even do it
[22:24:29 CEST] <fabled> seems it was .mp3 so far
[22:24:44 CEST] <fabled> so i don't think most muxers even handle attached_pic disposition
[22:24:57 CEST] <fabled> and often end up dumping them as separate main video tracks instead of cover art
[22:25:14 CEST] <fabled> mkv does it different
[22:25:18 CEST] <jamrial> audio muxers, like mp3, try to dump any video you throw at it as cover art
[22:25:23 CEST] <jamrial> which is kinda ugly
[22:25:33 CEST] <fabled> mkv uses the attachment streams and require mime type
[22:25:36 CEST] <fabled> so it's asymmetric
[22:26:18 CEST] <fabled> mkv demux gives attached_pic out, and mkv mux ignores and makes it video track. mkv mux takes only attachments as cover art...
[22:27:39 CEST] <JEEB> yup
[22:27:44 CEST] <JEEB> lovely
[22:28:03 CEST] <JEEB> reminds one of how organically this thing's been growing :)
[22:28:06 CEST] <JEEB> in both good and bad
[22:28:11 CEST] <fabled> yeah
[22:28:35 CEST] <fabled> so my patch followed the contributor principle: make it as small and unintrusive as you can :)
[22:29:03 CEST] <jamrial> the matroska muxer doesn't even consider cover art, just attachments
[22:29:24 CEST] <fabled> yup. but demux checks attachment mime type
[22:29:31 CEST] <fabled> if it's image, it considers it cover art
[22:29:51 CEST] <fabled> iirc, only mp3enc was looking at attached_pic
[22:30:07 CEST] <fabled> but now i submitted the mp4 one, and flac patch came along too
[22:30:13 CEST] <jamrial> different developers doing different things, yeah. the matroska spec is even kinda vague about cover art
[22:30:16 CEST] <fabled> might be good time to review how we want it architecturally done
[22:30:49 CEST] <fabled> anyways. i need to go sleep. if you can comment the patches on ML, that'd be great. happy to rework after receiving direction how it should be done.
[22:31:03 CEST] <fabled> i'll try to read backlog here too later
[22:31:29 CEST] <fabled> ttyl
[22:31:32 CEST] <jamrial> later
[23:25:38 CEST] <cone-797> ffmpeg 03Lou Logan 07master:2f1963eedc0c: doc/developer: remove merge request method of contributing
[00:00:00 CEST] --- Sat Apr  7 2018