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

[burek]

[00:08:53 CEST] <BtbN> with the h264 
[00:09:18 CEST] <BtbN> parser being somewhat external now, would it be possible to use it to extract ac53cc closed captions in for example cuvid?
[00:09:29 CEST] <BtbN> or is that still part of the decoder itself?
[00:09:45 CEST] <nevcairiel> you need to re-order for that to work, which is not something anything but teh decoder does
[00:09:46 CEST] <nevcairiel> so no
[00:10:40 CEST] <BtbN> hm, cuvid would have to pass some payload along
[00:11:29 CEST] <nevcairiel> personally I dont think these are important enough to warrant some evil hackery  to get external hw apis to behave, just use a hwaccel if you want these extracted
[00:11:49 CEST] <BtbN> could have some kind of ring buffer of those, and use the timestamps to look it up.
[00:12:23 CEST] <BtbN> that would also be usefull for other things, not only cc
[01:08:39 CEST] <wm4_> nevcairiel, BtbN: I think somehow having the reorder logic available without full decoding would be pretty useful for many things
[07:55:30 CEST] <nevcairiel> wm4_: the re-order logic of h264 is super complex though, and somehow ripping that out would be extremely complex
[12:20:50 CEST] <kierank> nevcairiel: you can use poc
[12:20:55 CEST] <kierank> That's guaranteed to work
[12:34:15 CEST] <nevcairiel> getting h264 pocs is not entirely trivial either, although that info may actually be something the parser has
[13:12:30 CEST] <cone-336> ffmpeg 03Xiaolei Yu 07master:5a70e56f2f11: avcodec: fix vc1dsp dependencies
[14:02:37 CEST] <Chloe> ubitux: can you have aliases for the --enable stuff?
[14:03:00 CEST] <ubitux> probably not in a clean way
[14:06:22 CEST] <Chloe> it's actually a real pain to put it back to sdl, because of how the check-pkg-config stuff works
[14:07:12 CEST] <Chloe> it'll set sdl2 stuff if it's check_pkg_config sdl2, but the lib name need to be sdl for the --enable flags
[14:15:21 CEST] <Chloe> ubitux: do you maybe know of a solution?
[14:15:23 CEST] <Chloe> I guess I could rename the device entirely
[14:15:51 CEST] <ubitux> i think it's fine as sdl2 tbh
[14:17:25 CEST] <nevcairiel> i tend to agree, its not like any version change of other libraries, its significantly different and incomaptible to the old one
[14:18:30 CEST] <Chloe> I'll still add the alias for the device though
[14:48:09 CEST] <Chloe> carl says rename it :/
[15:21:46 CEST] <BtbN> Is there some way to generate an endless stream of frames with side data somehow, without a very large input file which has such data?
[15:24:17 CEST] <rcombs> BtbN: what type of side data?
[15:24:28 CEST] <BtbN> doesn't matter, any side data will do.
[15:24:34 CEST] <BtbN> see ticket #5799
[15:24:49 CEST] <rcombs> filter_complex color=black,mestimate?
[15:25:45 CEST] <BtbN> I'll try that
[15:35:57 CEST] <BtbN> rcombs, yeah "./ffmpeg -f lavfi -i testsrc2 -vf mestimate -c:v mpeg2video -f null -" works fine.
[15:36:01 CEST] <BtbN> endless memory hog
[15:37:35 CEST] <rcombs> "fine"
[15:37:48 CEST] <BtbN> well, I was looking for a way to reproduce the leak
[15:37:53 CEST] <rcombs> :P
[15:48:07 CEST] <Chloe> BtbN: ffmpeg hit 500MB pretty quickly with that command, testing fix for it now.
[15:53:46 CEST] <atana> Compn: I had dropped a mail to ffpmeg-devel mailing list regarding the idea.
[15:54:06 CEST] <Chloe> atana: looks like an interesting idea
[16:12:21 CEST] <atana> Chloe: glad you find it interesting :)
[16:53:23 CEST] <JEEB> so does the current decoder cropping just base on the fact that width and height are set accordingly?
[16:54:18 CEST] <JEEB> trying to look at how it's currently implemented and if similar ways can be reused
[17:08:07 CEST] <Chloe> I'm going to push the transparent re=addition of --enable-sdl and alias of sdl without changing the documentation tonight if no one else objects (carl wanted it soon). The change is insignificant, and the library *is* sdl2 not sdl. 
[17:10:41 CEST] <omerjerk_> Hey
[17:10:55 CEST] <omerjerk_> So, I fell into some issues in my encoder patch.
[17:11:46 CEST] <omerjerk_> First one which I want to fix is that the reference decoder treat the original format as RAW instead of WAV.
[17:11:56 CEST] <omerjerk_> Is there some API to fix this?
[17:13:14 CEST] <omerjerk_> If I encode a file with ref encoder and decode with ref decoder, it treats the orig. format as WAV only.
[17:15:40 CEST] <omerjerk_> If I decode the .mp4 file (created by ffmpeg) using ref decoder, the ref decoder treats the original format as RAW.
[17:15:48 CEST] <omerjerk_> Any idea what could be done?
[17:16:00 CEST] <omerjerk_> I'm sure there must be some option in FFmpeg to fix this.
[17:16:53 CEST] <omerjerk_> @durandal_1707: if you could help. :)
[17:19:53 CEST] <durandal_1707> omerjerk_: either write code that reference code understands
[17:20:53 CEST] <durandal_1707> or improve ref code
[17:21:02 CEST] <omerjerk_> I did some rigorous testing, and turns there are quite a few issues with the encoder. Even the ALS mixer is not producing proper .als file which the ref decoder understands. 
[17:21:21 CEST] <durandal_1707> looks like you want raw als muxer?
[17:22:31 CEST] <omerjerk_> @durandal_1707: No. there's an ALS muxer in my patch already. But it doesn't produce correct ALS file. Ref decoder gives error when I run it over this .als file.
[17:22:45 CEST] <omerjerk_> so there are quite a few issues as of now.
[17:23:17 CEST] <durandal_1707> what error?
[17:23:26 CEST] <omerjerk_> Also, there's some issue in the encoder algorithm as well. Which I'm not sure if I'll be able to fix.
[17:23:43 CEST] <omerjerk_> I'm listing them down
[17:24:26 CEST] <omerjerk_> 1. An issue in the encoding algorithm.
[17:24:52 CEST] <omerjerk_> 2. An issue in the ALS muxer.
[17:25:18 CEST] <omerjerk_> 3. Ref decoder considers the orig format of .mp4 file is RAW instead of WAV.
[17:25:33 CEST] <omerjerk_> I'll first tackle 2 and 3
[18:47:46 CEST] <noobe1> hi, where is the source code is the MP4 container create code?
[18:47:58 CEST] <JEEB> libavformat/movenc.c
[18:48:01 CEST] <noobe1> to write to mp4 file as output
[18:50:30 CEST] <noobe1> Thanks!
[18:54:16 CEST] <Chloe> ubitux: do I need to revert the documentation according to carl's request? I don't think this is the right approach
[18:55:15 CEST] <ubitux> what doc?
[18:55:49 CEST] <Chloe> the enable-sdl2 --help string
[18:56:22 CEST] <Chloe> The patch re-adds --enable-sdl but I suggested to do it silently so that scripts arent broken, but it's not explicitly encouraged
[18:56:36 CEST] <RiCON> on one side, it'll fail for old scripts because they'll except ffmpeg to look for sdl1, not sdl2
[18:57:34 CEST] <Chloe> yeah this was kinda my other point, re-adding --enable-sdl isnt a good idea because it's not the same dependency
[18:59:44 CEST] <RiCON> allowing --disable-sdl would make sense, --enable-sdl not so much
[19:00:13 CEST] <Chloe> err, I meant disable sdl sorry
[19:00:28 CEST] <Chloe> --enable-sdl will have no effect
[19:00:49 CEST] <RiCON> for the disabling it makes sense to also disable sdl2, it means the user doesn't want sdl
[19:00:55 CEST] <RiCON> imo.
[19:01:33 CEST] <Chloe> yep. and what about changing the help text?
[19:01:46 CEST] <Chloe> keep it as --disable-sdl2?
[19:02:11 CEST] <noobe1> hi, I'm trying to understand mp4 file format. Can I in theory create a mp4 file using AVIOContext and AVFormatContext? 
[19:03:15 CEST] <noobe1> I'm going through ffmpeg examples, but if there is one good example please let me know. Thanks!
[19:03:36 CEST] <RiCON> Chloe: i also think it should stay as --disable-sdl2 and make no mention of sdl1, in the help text
[19:04:41 CEST] <Chloe> sure. I think this is what ubitux said earlier as well, but I'd just like to confirm.
[19:05:38 CEST] <ubitux> Chloe: no opinion
[19:05:54 CEST] <Chloe> ;_;
[19:05:56 CEST] <RiCON> people that used --enable-sdl are the sort that would like to know about different dependencies, i'd assume
[19:06:12 CEST] <RiCON> like distros
[19:06:21 CEST] <Chloe> it's mentioned in the news as well
[19:07:40 CEST] <cone-041> ffmpeg 03Michael Niedermayer 07master:9083e044f11b: ffmpeg: Fix bistream typos
[19:07:40 CEST] <cone-041> ffmpeg 03Michael Niedermayer 07master:b98dafe04564: avformat/avidec: Fix memleak with dv in avi
[19:07:48 CEST] <RiCON> ultimately it could go to vote, but that's kinda overkill
[19:07:59 CEST] <Chloe> pls no
[19:08:40 CEST] <RiCON> it's a different dependency, so it makes more sense for the option to be different
[19:09:33 CEST] <Chloe> Yes. I'm just gonna push it, carl can kick up a fuss if he so wishes.
[19:09:42 CEST] <cone-041> ffmpeg 03Josh de Kock 07master:fbb1fcd4d0b4: lavd/sdl2: remove unused code
[19:09:43 CEST] <cone-041> ffmpeg 03Josh de Kock 07master:21344991c0d2: lavd/sdl2: add sdl alias
[19:10:09 CEST] <ubitux> omg the horror of dv in avi
[19:10:19 CEST] <ubitux> the shit is this fuck
[19:11:00 CEST] <Chloe> rip 
[19:13:03 CEST] <wm4> ubitux: dv and avi are horrors on their own, so combining them...
[19:16:29 CEST] <cone-041> ffmpeg 03Anton Khirnov 07master:1e93c1e30ff0: avconv: do not set encoder options when streamcopy is used
[19:16:30 CEST] <cone-041> ffmpeg 03Clément BSsch 07master:99dfa55d5a5a: Merge commit '1e93c1e30ff0e8bf6094a426ca60f005e9cdaed3'
[19:16:39 CEST] <jamrial> why is the avi demuxer freeing all those contexts?
[19:17:48 CEST] <cone-041> ffmpeg 03Clément BSsch 07master:485f75b2786a: doc: remove codecpar mention in libav-merge.txt
[19:18:17 CEST] <ubitux> 330 libav commits to merge
[19:18:20 CEST] <ubitux> i feel lazy
[19:18:28 CEST] <ubitux> anyone wants to give it a go?
[19:18:46 CEST] <Chloe> what's involved?
[19:18:57 CEST] <JEEB> see the merge doc
[19:19:16 CEST] <Chloe> on the wiki?
[19:19:21 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/libav-merge.txt;h=2011ae580c5ad0ef9e702b52cc7e304b8fb790ac;hb=HEAD
[19:19:58 CEST] <ubitux> Chloe: http://sprunge.us/deiT
[19:20:05 CEST] <ubitux> from top to bottom
[19:20:24 CEST] <ubitux> current TODO in addition to the HEVC stuff
[19:25:00 CEST] <Chloe> hevc stuff :D
[19:28:28 CEST] <cone-041> ffmpeg 03Clément BSsch 07master:95a7cbb09de1: doc: move out merge script to tools
[19:29:35 CEST] <ubitux> Chloe: yeah, see bottom of libav-merge.txt
[19:29:55 CEST] <Chloe> 'No subtopics Nothing found - bye'
[19:29:57 CEST] <ubitux> i wonder if we should add stuff like the hevc parser crap
[19:30:13 CEST] <ubitux> and prores etc
[19:30:58 CEST] <Chloe> libav is still many commits behind ffmpeg's hevc stuff in some places
[19:31:43 CEST] <jamrial> they didn't implement a lot of the openhevc changes
[19:32:12 CEST] <Chloe> I had a list of what they dont have somewhere
[19:32:15 CEST] <jamrial> and decided to go ahead without them, so things like incompatible hevc mc x86 happened
[19:35:45 CEST] <jamrial> most of those ~300 commits are probably easy, like int -> ptrdiff_t, K&R and such. others are noops since they change stuff we already changed
[19:36:03 CEST] <ubitux> those are the worse
[19:36:07 CEST] <jamrial> the potentially hard ones are those changing avconv.c/ffmpeg.c,
[19:36:19 CEST] <ubitux> they might be "easy" but they're the most annoying
[19:36:51 CEST] <ubitux> because you actually have to carefully check the slight differences (for stuff we already have), and for K&R space randomization you basically have to redo them completely
[19:37:06 CEST] <jamrial> i can handle those if you want
[19:38:33 CEST] <cone-041> ffmpeg 03Clément BSsch 07master:bd9e4254595e: doc/libav-merge: change gmane link to a ffmpeg.org one
[19:40:09 CEST] <ubitux> jamrial: the less i do about these merge the happier i am
[19:44:27 CEST] <Chloe> ubitux: is there maybe a collaborative checklist we can use? (do the merges have to be done in order?)
[19:46:26 CEST] <ubitux> yeah it's much better in order
[19:46:35 CEST] <ubitux> because you can actually "merge" them for real
[19:46:38 CEST] <ubitux> and not cherry-picj
[19:47:35 CEST] <Chloe> ah :/ and the checklist q?
[19:51:35 CEST] <jamrial> Chloe: look at libav-merge.txt and the script currently in tools. with it (or the git commands it uses) you can merge the commits in order
[19:52:29 CEST] <Chloe> yeah I got the script, I've added libav as a remote but im getting 'fatal: ambiguous argument 'libav/master': unknown revision or path not in the working tree.'
[19:54:03 CEST] <ubitux> git fetch libav
[19:59:48 CEST] <jamrial> ubitux: alright, i'll handle the annoying k&r and such commits for you
[19:59:57 CEST] <jamrial> we finally left codecpar/bsf behind, so the faster we get rid of this queue the better
[20:04:43 CEST] <ubitux> if we can be ready for the next evil plan with 0 merge behind that would be great
[20:05:01 CEST] <ubitux> i'm assuming the next evil plan will be parser related
[20:05:36 CEST] <jamrial> probably
[20:06:05 CEST] <jamrial> but they left it for after libav12, which is being postponed a lot for some reason
[20:07:10 CEST] <jamrial> this new bsf api is great, seeing it fixed things like keyframes not being marked, or even extradata in mpeg4_unpack_bframes not being propagated
[20:07:16 CEST] <jamrial> so their "evil plans" are not all so evil :p
[20:07:20 CEST] <philipl> nevcairiel: I have no idea how much you care, but I came across this: https://devtalk.nvidia.com/default/topic/965840
[20:07:33 CEST] <philipl> presumably if you updated to the new SDK headers you could enable it.
[20:09:40 CEST] <nevcairiel> I will never personally enable or advocate a mode that decodes in subpar quality, ie. truncated to 8-bit
[20:09:56 CEST] <jamrial> then again, maybe those bugs weren't from the old api but rather the compat stuff that was put in place
[20:09:58 CEST] <wm4> dithered, not truncated
[20:10:10 CEST] <wm4> but yeah, that kind of sucks
[20:10:31 CEST] <wm4> still better than "doesn't play", though
[20:10:52 CEST] <nevcairiel> falls back to software, so what do i care
[20:11:19 CEST] <nevcairiel> personally i wouldnt use cuvid for anything anymore
[20:13:14 CEST] <philipl> Can you get proper 10bit surfaces out of the decoder using one of the dxva flavours?
[20:13:52 CEST] <JEEB> yes
[20:13:59 CEST] <JEEB> DXVA2 gives you P010 HEVC
[20:15:30 CEST] <philipl> yeah, cuvid makes little sense on windows, given that fact and that vp8/9 is also supported by dxva.
[20:15:40 CEST] <jkqxz> How do the reference frames work when it does that?  Does the output just accumulate error, or is it holding the real surfaces somewhere else that you aren't allowed to see?
[20:16:01 CEST] <philipl> jkqxz: The later.
[20:16:14 CEST] <wm4> jkqxz: can vaapi do 10 bit now?
[20:16:16 CEST] <philipl> The limitation is that the API definition says returned frames must be NV12 (in this particular case)
[20:17:14 CEST] <jkqxz> philipl:  Well, can't you get the real surface out of it by doing mmap /dev/mem somemthing something then?
[20:17:26 CEST] <jkqxz> wm4:  Probably.  I don't have any hardware yet, though.
[20:17:35 CEST] <philipl> jkqxz: The real surface is in GPU-side memory, I'm sure.
[20:17:53 CEST] <philipl> and not mapped into the CPU's address space
[20:18:37 CEST] <wm4> uh, /dev/mem, are we qualcomm or what
[20:18:52 CEST] <wm4> (or whatever mobile gpu vendor did that)
[20:19:09 CEST] <philipl> I am reasonably confident that nvidia will add this ability at some point. Maybe even cuda 8, although that's now overdue release and the RC has garbage cuvid headers.
[20:21:13 CEST] <jkqxz> wm4:  Everyone embedded does that.  Once you have a SoC with one memory space and a well-defined memory map which can see everything on the chip it's the easiest way of doing all sorts of things.
[20:22:31 CEST] <wm4> so you're saying mobile is really terrible?
[20:22:45 CEST] <philipl> A universal truth.
[20:32:33 CEST] <philipl> Just for fun, I tried instantiating a cuvid decoder in a loop with output enum values > 0. No luck. There's no undocumented P010 in there. :-P
[21:06:20 CEST] <cone-041> ffmpeg 03James Almer 07master:aa0dc698dba8: avformat/avidec: remove warning about deprecated declarations
[21:13:26 CEST] <cone-041> ffmpeg 03James Almer 07master:e3842e87f2f0: avcodec/Makefile: Fix mlpenc dependencies
[21:19:49 CEST] <cone-041> ffmpeg 03James Almer 07master:3ac76d761851: ffmpeg: fix memleak of encoder options AVDictionary on failure
[21:19:50 CEST] <cone-041> ffmpeg 03James Almer 07master:449dc25f56fa: ffmpeg: fix memleak of bitstream filter context on failure
[21:28:21 CEST] <Chloe> oh wow, how *do* you merge the avconv changes? 
[21:28:36 CEST] <Chloe> it's creating the 'avconv.c' file
[21:32:39 CEST] <nevcairiel> carefully
[21:32:43 CEST] <nevcairiel> those are a bit more tricky
[21:32:47 CEST] <JEEB> also gonna re-run the question, but is bitstream cropping currently only working from bottom upwards / from right border leftwards (because it's just setting the width/height values in the avcodeccontext)
[21:32:51 CEST] <JEEB> ?
[21:33:14 CEST] <JEEB> quickly tried to git grep the code base but didn't find more than that
[21:34:22 CEST] <nevcairiel> with h264 it should work, but if you use it from API you might need to set a new flag
[21:34:29 CEST] <nevcairiel> not sure if ffmpeg.c sets it
[21:35:21 CEST] <JEEB> just wondered if that could be extended to handling container cropping (as I stuck my face into MXF)
[21:36:34 CEST] <JEEB> basically, if it's something else than just setting width/height, similar things could be used for container cropping
[21:37:02 CEST] <DHE> is that for use when the image size doesn't match the codec requirements? (eg; h264 requires multiple of 16x16)
[21:37:52 CEST] <JEEB> yes, decoder cropping is that.
[21:38:19 CEST] <JEEB> then container cropping is when some person decides that they want to duplicate the non-active-picture lines of analog stuff in digital form
[21:38:36 CEST] <JEEB> so you need to do additional crop after the decoder cropping
[21:38:58 CEST] <nevcairiel> container cropping is evil and there are no easy solutions =p
[21:40:06 CEST] <JEEB> well, yeah. I guessed that would pop up. so in the short term I thought I could at least stick storage_width/height and display_width/height + display_x/y_offset into metadata so I could at least get them through some way later in the chain :D
[21:42:59 CEST] <BtbN> calling av_frame_unref should allways be safe, should it?
[21:43:07 CEST] <DHE> it's thread-safe, yes
[21:43:25 CEST] <DHE> assuming buffer-based frames
[21:43:25 CEST] <BtbN> more wondering about frame contents
[21:43:55 CEST] <BtbN> Wondering of the leak fix for the mpegvideo enc is actually correct
[21:44:08 CEST] <DHE> oh, I filed that. Yes it is
[21:44:24 CEST] <DHE> oh you mean the actual patch suggested. haven't checked it yet
[21:45:03 CEST] <BtbN> it works for me, but I'm not 100% sure if it's the right approach
[21:45:16 CEST] <BtbN> or if copy_props just shouldn't be used in the first place
[21:45:25 CEST] <DHE> didn't you suggest that the coded_frame field should just not carry side_data since the side_data feature and coded_frame feature's deprecation don't overlap
[21:45:39 CEST] <DHE> or something to that effect
[21:46:08 CEST] <BtbN> well, that's not that easy to achive, as it's just a normal frame
[21:46:20 CEST] <BtbN> and copy props has no notion of it being a coded frame
[23:33:14 CEST] <wm4> AVFrame not properly suppporting cropping suire is a PITA
[23:39:38 CEST] <nevcairiel> honestly it just never comes up =p
[23:39:51 CEST] <nevcairiel> top/left cropping is just neat theory not used in real-life
[23:39:59 CEST] <nevcairiel> screw mxf, its a huge headache in itself
[23:40:06 CEST] <JEEB> lol
[23:41:01 CEST] <nevcairiel> and container cropping typically tries to solve problems that people made themself
[23:41:58 CEST] <JEEB> I don't disagree with that one
[23:42:26 CEST] <JEEB> I have no idea why SMPTE ST386M decided to have the analog stuff on the top
[23:42:39 CEST] <JEEB> or well, I think I know why but it's still fun
[23:42:43 CEST] <JEEB> "fun"
[23:43:06 CEST] <JEEB> at least in MXF it's better defined than that one field in matroska
[23:43:12 CEST] <JEEB> since you have both x and y offsets
[00:00:00 CEST] --- Mon Sep 26 2016