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

[burek]

[01:15:28 CET] <jkqxz> Without a really very strong justification, a total 0.1% speedup for a nebulous change is far too small to avoid Producing Wrong Data Without Doing Anything Obviously Wrong <http://www-plan.cs.colorado.edu/diwan/asplos09.pdf>.
[02:36:25 CET] <newbe-user> \help
[07:54:46 CET] <midgetspy> Hey guys I'm working with libav* inside Kodi and noticed that ffmpeg doesn't implement cropping in its demuxer (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroskadec.c#L432). Is this intentionally omitted? If I were to add it and submit a patch would that be welcome? If so I'd appreciate any guidance about where to start, diving right into the codebase is a little daunting 
[07:54:46 CET] <midgetspy> :0)
[08:08:18 CET] <wm4> midgetspy: there's no API concept for cropping and thus can't be implemented
[08:13:55 CET] <midgetspy> wm4: what do you mean by "there's no API concept for cropping"?
[08:14:28 CET] <wm4> no way to export cropping etc.
[08:17:04 CET] <midgetspy> I'm not familiar with the ffmpeg architecture so sorry if I'm being dense... do you mean that the ffmpeg API has no concept of cropping and so there's no point reading it from the matroska container?
[08:17:07 CET] <ubitux> apparently, at least cinedec is exporting crop metadata in the stream
[08:17:30 CET] <ubitux> so the same could be done for matroska
[08:17:49 CET] <ubitux> but i suppose the new trending way of exporting data is through side data
[08:20:00 CET] <midgetspy> My (naive) thought after brief investigation was that I would add it to AVStream and then populate it in the matroska demuxer... of course I had a feeling it wouldn't be that simple (not that that was going to be simple, heh)
[08:20:42 CET] <midgetspy> it seemed to me that it's a property of a video stream so it'd make sense to have it in AVStream along with width/height
[08:20:52 CET] <wm4> sure the demuxer could just export it (even in a demuxer-specific way), but I think it shiuld be added to AVFRame too
[08:21:53 CET] <wm4> there's also a question how matroska cropping works (its not clearly defined at all), and how it interacts with codec cropping
[08:23:05 CET] <midgetspy> in my case I have been attempting to follow the VLC implementation for Kodi
[08:24:11 CET] <wm4> following the mpc-hc implementation would be a better idea
[08:25:03 CET] <wm4> anyway, what I find worrisome here is how to add it to AVFrame
[08:25:17 CET] <wm4> so far everything assumes that there's no cropping
[08:25:39 CET] <wm4> and codec cropping (like in h264) is handled by adjusting the width/height and the plane data pointers
[08:26:02 CET] <wm4> (the latter doesn't work for hw decoding, so top/left cropping is omitted)
[08:27:56 CET] <midgetspy> ok I'll take a look at mpc-hc. So is your suggestion I implement it in the matroska demuxer specifically and then put it in the AVStream->side_data? I'm not sure I understand how side_data is packed just looking at the headers but I'll look into it. I also see AVStream->metadata but that seems like not what it's meant for?
[08:29:16 CET] <wm4> AVStream side data might be fine
[08:30:12 CET] <wm4> anyway, my worry is about how to nicely integrate it into ffmpeg's ecosystem so that the result isn't just a mess that somehow sometimes allows to get cropping params while it doesn't work in general, or so
[08:36:12 CET] <midgetspy> Makes sense, I'm glad I asked here before starting hacking around in the code. I have only the very narrow technical problem that I'm using ffmpeg as a demuxer in Kodi and it gives me no way to access the matroska crop values. If you have guidance of how I can solve that problem in a way that fits into the ffmpeg ecosystem I'm all ears. I'd like to find a solution that'd be accepted into 
[08:36:12 CET] <midgetspy> ffmpeg master :0)
[08:37:47 CET] <midgetspy> (In fact my real problem is that I want to crop black bars off a video file without re-encoding it and my plan is to solve that with matroska's cropping params as that's the only solution I could find)
[08:38:44 CET] <JEEB> ugh matroska cropping
[08:39:15 CET] <JEEB> originally meant for avc parameter value override in the demuxer
[08:40:13 CET] <JEEB> and then people noticed it and started using it for stuff like cropping a 4:3 image out of a 16:9 encoded blu-ray
[08:40:59 CET] <JEEB> also the cellar people seem to have noticed how badly it's defined
[08:42:13 CET] <midgetspy> Heh, I want to use it for cropping a 2.40 image out of a 16:9 blu-ray
[08:43:03 CET] <JEEB> yes, same thing and most probably wouldn't even work with the demuxer that defined the feature :)
[08:43:55 CET] <JEEB> because that is way more than what you can override by hacking parameter set values
[08:44:39 CET] <JEEB> wonder if cellar will just drop it or of it will stay as a badly defined thing in there, too
[08:45:16 CET] <JEEB> i wonder if the cropping-like metadata in isobmff is in any way better
[08:46:55 CET] <midgetspy> well personally I'd still like to have the demuxer able to read it so that the player is able to make assumptions about its implementation if it so chooses ;-P
[08:49:10 CET] <JEEB> I'm not against having well defined side data for cropping or whatever, but I just have a thing against the matroska field
[08:51:35 CET] <midgetspy> ok well I will proceed and see if I can figure out how to read it in the demuxer and add it to the side channel. What is the desired way to get feedback on it as I work, ask in here? Mailing list? I hope in the end it will be accepted into master so I'd like to get some feedback sooner than later so I don't waste my time if the change isn't wanted
[08:54:38 CET] <midgetspy> What's the difference between AVStream->metadata and AVStream->side_data? Other than the data structure...
[08:57:34 CET] <JEEB> as for the side data it shouldn't leave the player guessing
[08:58:00 CET] <JEEB> it should define at which data the cropping it should be applied
[08:59:01 CET] <JEEB> decoded data, decoded and decoder cropped data, image after aspect ratio has been applied are at least three different points of possible cropping
[09:12:49 CET] <wm4> it's still not clear how matroska and codec aspect ratio alone interact either (without any cropping present)
[09:15:13 CET] <JEEB> I recommend looking at how 14496-12 defines cropping if it has anything like that
[09:32:51 CET] <cone-649> ffmpeg 03Paul B Mahol 07master:b098e1a46975: avcodec/dvaudiodec: now that we got samples, fix 12bit case
[11:36:11 CET] <michaelni> midgetspy, it wasnt mentioned but as its related see AVPanScan, the struct can defines per field croping rectangles. (The name pan scan originates from mpeg1/2 terminology)
[11:37:21 CET] <michaelni> also there can be multiple such rectangles in side data of AVFrames
[11:40:34 CET] <michaelni> atomnuker, theres a patch for a qualification task for truhd on ffmpeg-devel (0321 21:29 Disha Singh     (135K) [FFmpeg-devel] [PATCH]Addition of MLP encoder), you are listed as Qualification Mentor on  https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis
[11:43:45 CET] <kierank> so, who has outreachy students?
[12:17:42 CET] <wm4> how is ffmpeg CLI supposed to behave if timestamps go backwards? drop the frame or apply non-working magic?
[12:21:15 CET] <atomnuker> michaelni: I know, I keep in touch with Disha
[12:21:28 CET] <atomnuker> still has some problems left to solve
[12:22:54 CET] <michaelni> atomnuker, i meant someone should review the patch on ML
[12:25:51 CET] <jkqxz> wm4:  IMO, apply non-working magic and warn about it.  I don't think you should ever drop frames unless the user has explicitly said you can (excepting cases where constrained resources force you to).
[12:26:47 CET] <wm4> well it seems it's normal, and just doesn't happen in fate-cavs because of crazy interactions of insane code
[12:33:08 CET] <ismail> wm4: semi-related, do you know if cavs used in the wild?
[12:33:51 CET] <kierank> neeraj: where is fuzz3.avi?
[12:33:54 CET] <durandal_170> people mail me to send them ffmpeg builds....
[12:38:21 CET] <neeraj> sorry the name of the file was fuzz2 which i pasted 
[12:38:28 CET] <neeraj> sorry uploaded
[12:40:16 CET] <wm4> ismail: no and I don't care, I just had to deal with its fate test
[13:33:49 CET] <BBB> my fingers are one big race condition today
[14:57:23 CET] <ubitux> yay hscale aarch64 working.
[15:23:06 CET] <ac_slater> hey all. I've made an openmax h264 encoder interface for libavformat. My only use case for this currently is to mux with mpegts and write to a file or send via udp/unix socket. With all three of these outputs, I'm seeing a 0-20second lag from input to output. ffmpeg is claiming my encoder is running at >= 1.00x. Is there a buffer between encoder and output mux (mux and output) that I can control? 
[15:39:35 CET] <Compn> ac_slater : you want zero latency
[15:40:16 CET] <Compn> udp sounds like it would be slow
[16:49:56 CET] <rcombs> that was fast
[16:51:07 CET] <atomnuker> rcombs: is the apple aac encoder chosen over the native one by default?
[16:51:12 CET] <rcombs> no
[16:51:13 CET] <jamrial> wait, these audiotoolbox decoders and encoders have more priority than the native ones?
[16:51:19 CET] <jamrial> that shouldn't happen
[16:51:27 CET] <rcombs> or, if it does, something's badly wrong
[16:52:20 CET] <rcombs> oh, he did `--disable-encoders`
[16:52:29 CET] <rcombs> so yeah, it's the only one available so it gets picked
[16:53:03 CET] <jamrial> funny he request that it should fallback to another encoder instead of exit with error, then :p
[16:53:13 CET] <jamrial> when he purposely disabled every other encoder
[16:53:19 CET] <rcombs> kinda hard to do that when you don't build anything else :3
[16:59:43 CET] <rcombs> ah, it's a bitrate issue
[17:26:26 CET] <rcombs> &if you ask what the applicable bitrates are for ALAC, the function returns `'who?'`
[17:26:53 CET] <rcombs> erroring there makes sense, but nice return code
[18:01:28 CET] <ac_slater> Compn: sorry for the late reply. My h264 encoder is doing baseline 3.1 at 15 fps with intraperiod of 15 (IDR frame every second). Isn't this what x264 does? If not, then that's probably my next step
[18:10:39 CET] <cone-224> ffmpeg 03Ganesh Ajjanagadde 07master:8dbffda0f940: lavc/psymodel: check for av_malloc failure
[18:49:32 CET] <TD-Linux> ac_slater, how small do you need the delay to be?
[19:08:53 CET] <cone-224> ffmpeg 03Rostislav Pehlivanov 07master:14b41e061db6: vc2enc: macro out slice size rounding
[19:08:54 CET] <cone-224> ffmpeg 03Rostislav Pehlivanov 07master:a010e36f23df: vc2enc: correctly zero out the slice size cache
[19:08:55 CET] <cone-224> ffmpeg 03Rostislav Pehlivanov 07master:a14d4c076dde: vc2enc: simplify calc_slice_sizes()
[20:29:32 CET] <cone-224> ffmpeg 03Michael Niedermayer 07master:fe3de6bc6222: fate: Add test that also decodes packed_bframes.avi
[20:34:00 CET] <ac_slater> TD-Linux: sorry for the delay mate, < 2 seconds consistent 
[20:34:41 CET] <ac_slater> TD-Linux: Somehow I can't seem to determine where the growing latency is coming from ... :(
[21:06:18 CET] <rcombs> man, I forgot about the clusterfuck that is 7.1 AAC
[21:07:33 CET] <nevcairiel> 7.1 without PCE is silly
[21:08:42 CET] <rcombs> pity audiotoolbox doesn't provide a way to encode PCE
[21:09:10 CET] <rcombs> there's a whole infrastructure for passing encoders a list of channels in a specific order
[21:09:27 CET] <rcombs> and if you use it with AAC it gives a "format unsupported" error
[21:11:45 CET] <rcombs> nevcairiel: btw, in re: audiotoolbox encoders existing, at_aac is an order of magnitude or two faster than the internal encoder at the moment
[21:12:04 CET] <rcombs> well, probably less so if I built the internal encoder with more optimizations enabled
[21:12:11 CET] <rcombs> but still it's fast
[21:12:34 CET] <atomnuker> 1-2 orders of magnitude means 10 to 100 times faster
[21:12:54 CET] <rcombs> yeah, it was here, but I said that and then remembered I have most optimizations disabled
[21:13:36 CET] <nevcairiel> ie. you dont have any real numbers? :D
[21:14:01 CET] <rcombs> if nothing else it's useful for comparisons
[21:15:32 CET] <wm4> rcombs: faster at same quality? (also, how do you measure quality)
[21:32:38 CET] <wm4> oh, nice spam attempt
[21:36:57 CET] <rcombs> alright, at similar bitrates AT is between 2x and 5x faster depending on channel count (and probably other parameters but I cba to test more right now)
[21:37:16 CET] <RiCON> rcombs: do those enc/decs work with apple application support in windows or is it osx-only?
[21:37:25 CET] <RiCON> i assume no
[21:37:45 CET] <wm4> rcombs: I guess the internal encoder still has a long way to go...
[21:37:48 CET] <rcombs> RiCON: in theory you can probably link this against the Windows AudioToolbox DLL, but I don't have anything setup to do that in configure
[21:38:05 CET] <wm4> or maybe Apple is actually good at doing fundamental multimedia components
[21:38:12 CET] <rcombs> and then the redist police would come after you
[21:38:41 CET] <rcombs> wm4: their AAC encoder is like the only good encoder they've ever done
[21:39:11 CET] <wm4> what about the other encoders?
[21:39:27 CET] <rcombs> there's ALAC, which is uh&
[21:39:34 CET] <wm4> oh ok lol
[21:39:43 CET] <rcombs> I haven't really perf-tested it but it's a lossless codec and I don't really expect much differentiation there
[21:39:44 CET] <wm4> I also see pcm alaw/ulaw
[21:39:50 CET] <wm4> and whatever ilbc is?
[21:39:58 CET] <RiCON> internet low bitrate codec
[21:39:58 CET] <rcombs> and then PCM alaw/mulaw which are just there because they're available
[21:40:01 CET] <rcombs> not really useful
[21:40:04 CET] <RiCON> webrtc stuff
[22:11:54 CET] <JEEB> rcombs: I thought they just licensed Adobe's?
[22:12:00 CET] <JEEB> uhh
[22:12:01 CET] <JEEB> not adobe
[22:12:05 CET] <JEEB> dolby
[22:13:22 CET] <rcombs> did they?
[22:13:34 CET] <JEEB> that's what I heard
[22:17:48 CET] <JEEB> seems to be a rumor/whatever from circa 2004, some really old audio FAQ notes that "The iTunes/apple codec is based on the original Dolby code and has also been tuned for quality significantly, despite the fact that it is CBR only the quality is quite good."
[22:23:35 CET] <rcombs> JEEB: well it's not CBR-only anymore
[22:23:51 CET] <rcombs> so either it's been modified quite a bit, or it's been replaced
[22:24:15 CET] <RiCON> having everyone use itunes likely helped
[22:25:03 CET] <JEEB> rcombs: it probably just got updated :)
[22:26:02 CET] <JEEB> that line seems to now that I see even start with "Apple's AAC: CBR only with quicktime <7, quicktime 7 and later include VBR AAC."
[22:26:34 CET] <JEEB> tl;dr possibly tweaked dolby's AAC
[22:26:57 CET] <JEEB> in any case an encoder made (relatively) easily available
[23:47:22 CET] <llogan> i wonder if there is a way to lock certain bug reports (such as the expired "art contest")
[23:47:41 CET] <llogan> because that one seems to get more spam attachments
[23:48:57 CET] <llogan> also, i immediately know it was spam because the username was female, which is kind of funny and sad at the same time.
[23:49:17 CET] <atomnuker> michaelni: any way to reproduce the overflow on the aac encoder you reported?
[23:53:42 CET] <michaelni> atomnuker, clang with ftrapv but you can just add a if() or av_assert() there to check for INT_MIN return
[23:54:02 CET] <michaelni> atomnuker: http://fate.ffmpeg.org/report.cgi?time=20160323212826&slot=x86_64-freebsd10-clang33-ftrapv
[23:59:08 CET] <cehoyos> michaelni: Hi, I have moved two proposals to the "ignored" list, I hope this was ok. What about "Multi - Client Video Streaming over WLAN": Is there a chance that this will be an FFmpeg project?
[23:59:53 CET] <cehoyos> atomnuker: Did you see that you have two candidates? Do they know that only one can be accepted?
[00:00:00 CET] --- Thu Mar 24 2016