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

[burek]

[00:00:44 CET] <durandal_1707> knight___: AVFrame->extended_data[channel][samples]
[00:01:37 CET] <durandal_1707> not exactly for >uint8 samples. but thats idea
[00:03:20 CET] <knight___> Ok so every Frame has a few channels in it, each channel has its own array of samples (which are tiny bits of data) and  the number of channels are determined by the layout, stereo-4 and so on ?
[00:04:11 CET] <durandal_1707> yes
[00:04:56 CET] <durandal_1707> thats for planar sample formats
[00:05:50 CET] <knight___> thats cool
[00:09:34 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:ac8c72f8f1f7: mov: Fix checking layout and loading padding for cubemaps
[00:09:35 CET] <cone-310> ffmpeg 03Vittorio Giovara 07master:9ae3506696ba: matroskadec: cosmetics: Rearrange checks for projection-depedendent properties
[00:20:39 CET] <knight___> #define AV_NUM_DATA_POINTERS 8:---> why is this 8?
[00:25:53 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:587226ad4594: lavc/libx265: Add gray10 and gray12 encoding support.
[00:30:56 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:a9c20598b505: lsws/input: Do not define unused functions.
[00:33:50 CET] <cone-310> ffmpeg 03Carl Eugen Hoyos 07master:851f4255e0e2: lsws/slice: Move a misplaced const.
[01:50:09 CET] <knight___> @durandal_1707 I have written a simple square filter, can you verify?
[03:58:43 CET] <adeel1> durandal_1707: yes
[05:21:12 CET] <cone-980> ffmpeg 03James Almer 07master:dbc932e745fe: Revert "lavu/atomic: add support for the new memory model aware gcc built-ins"
[08:06:30 CET] <wm4> ah the spherical fate tests now pass on 64 bit systems
[09:59:12 CET] <wm4> can anyone explain to me why "side_data_type" doesn't appear in the ffprobe output (if there's side data), even though it's definitely in the code?
[10:01:00 CET] Action: wm4 solves it by using manual printfs, as always
[10:16:22 CET] <cone-220> ffmpeg 03Muhammad Faiz 07master:61926b6c3e56: swresample/resample: use uniform normalization
[11:51:54 CET] <wm4> michaelni: 946ed78f5f8683229afe778a774c12b3a25aba57 mutates the packet data...
[11:53:06 CET] <wm4> that's what breaks -fflags +keepside
[11:57:15 CET] <JEEB> funky
[14:47:01 CET] <cone-466> ffmpeg 03Thomas Turner 07master:a50ccbd240a9: avutil/tests/lfg.c: added proper normality test
[14:47:02 CET] <cone-466> ffmpeg 03Michael Niedermayer 07master:1d0bad421ceb: avutil/tests/lfg: Remove debugging start/stop timer
[15:42:35 CET] <BBB> wbs: holy crap patchload
[15:42:54 CET] <BBB> wbs: thats all been thoroughly tested on libav right? So no need for extensive review
[15:45:40 CET] <BBB> wm4: what is merged side data?
[15:47:42 CET] <wbs> BBB: yes, all of those have been in libav for weeks/months, so they're pretty safe. most of them are pretty small couple-of-line tweaks, but some are bigger optimizations. it basically just reduces the diff for the 8bpp things to libav down to the bare minimum
[15:48:40 CET] <wm4> BBB: by default, libavformat removes all side data from AVPackets, and adds it to the packet data
[15:48:51 CET] <wm4> it appends it to the end of the codec data, using a special marker
[15:48:58 CET] <wm4> see av_packet_merge_side_data()
[15:49:04 CET] <BBB> wtftftftftftf?!?!?!?!?
[15:49:15 CET] <BBB> libavformat touches packet data?
[15:49:16 CET] <wm4> in libavcodec, the side data is split again before it's passed to the decoder
[15:49:26 CET] <wm4> yes
[15:49:31 CET] <wm4> it's supposed to help MPlayer
[15:49:32 CET] <wm4> I mean
[15:49:38 CET] <BBB> kill it
[15:49:44 CET] <BBB> Im going to vomit for a few hours, bbl
[15:49:44 CET] <wm4> API users which need to transport packet data and can't keep the side data
[15:49:57 CET] <wm4> glad you like it
[15:58:12 CET] <cone-466> ffmpeg 03Muhammad Faiz 07master:fe57bf7cd6ac: fate/swresample: fix FUZZ typo
[16:09:36 CET] <BBB> Im having a strange feeling that weve discussed this patch before
[16:09:39 CET] <BBB> like a flashback
[16:10:49 CET] <wm4> I don't remember anything, but I might have complained multiple times on IRC
[16:10:55 CET] <wm4> but this time I won't give up
[16:10:58 CET] <wm4> because fuck this shit
[16:11:20 CET] <iive> is that about subtitles?
[16:13:07 CET] <wm4> no
[16:18:07 CET] <rcombs> yeah the side data merge/split stuff has never made sense
[16:21:52 CET] <iive> hum, MPlayer code that uses the above function have been added at 2016.
[16:24:45 CET] <BBB> this seems like one of the most obscure crazy hacks Ive ever seen
[16:25:41 CET] <BBB> imagine me adding this to the smtp email delivery standard, attachments shall be added at the end of the message, separated by  from the main message
[16:27:05 CET] <nevcairiel> isnt that basically how those work? =p
[16:27:14 CET] <iive> :)
[16:28:09 CET] <BBB> I believe under  is the corporate disclaimer, not attachment
[16:28:22 CET] <BBB> although we dont ever read either of them, so I guess theyre interchangeable in some ways
[16:28:54 CET] <BBB> you know, if you are not the intended recipient of this email, please delete it and confirm in writing that you have done so or YOU WILL GO TO JAIL, YOU FAKE NEWS LIAR!!!!"
[16:31:28 CET] <ubitux> yes, the side data split/merge has been discussed several times, at least once a year since 2012
[16:32:40 CET] <ubitux> maybe not in the recent ones
[16:59:05 CET] <wm4> iive: which function?
[16:59:37 CET] <wm4> anyway, I'm fine with the function itself existing, just their use in ffmpeg code should be fully removed
[17:20:16 CET] <rcombs> BBB: attachments are added at the end of the message, separated by "--[separator]", where [separator] is a string defined in a message header
[17:20:35 CET] <rcombs> I'm completely serious, this is how MIME multipart works
[17:27:54 CET] <wm4> rcombs: and everyone was sad
[17:42:54 CET] <wm4> is there a way to set global fate options, that will be passed to all tools (ffmpeg/ffprobe)?
[17:52:33 CET] <jkqxz> wm4:  Abuse lack of quoting?  HWACCEL='none -also other -stuff'
[17:54:01 CET] <adeel1> durandal_1707: yes, I get a black screen.
[18:00:04 CET] <ubitux> wm4: tests/fate-run.sh in ffmpeg() function maybe; no such thing seems to exist for ffprobe
[18:00:36 CET] <ubitux> you probably want to wrap the run ffprobe${PROGSUF} ... into one
[18:21:59 CET] <durandal_1707> adeel1: find out why
[18:26:23 CET] <adeel1> durandal_1707: for one example it's completely black, and for the other one I get some purple stuff (at one point I got a clear decoded image, but after changing the pointer stuff it changed).
[18:33:50 CET] <durandal_1707> adeel1: bacause you cant change stuff out of nowhere
[19:31:49 CET] <adeel1> durandal_1707: So, I believe the problem stared when I changed x->frame->data[0] to p->data[0]. Could this be it?
[20:02:50 CET] <wm4> jamrial: I can't see anything civil in having to fight for every millimeter, just because it's a cleanup (and michaelni apparently doesn't like this kind of change)
[20:03:51 CET] <jamrial> i mean there were argumens and no insults. even if they seem pointless or irritating, it's at least civil
[20:04:37 CET] <jamrial> if people start assuming malice from the other party then it's all downhill from there
[20:16:32 CET] <wm4> it's already pretty downhill
[21:15:48 CET] <cone-362> ffmpeg 03Michael Niedermayer 07master:01a33b835f7a: avcodec/pictordec: Fix runtime error: left shift of 64 by 25 places cannot be represented in type 'int'
[21:15:48 CET] <cone-362> ffmpeg 03Michael Niedermayer 07master:3016e919d4e1: avcodec/wavpack: Fix runtime error: left shift of negative value -5
[21:20:54 CET] <ramiro> AVIContext::is_odml is unused in libavformat/avidec.c
[21:21:06 CET] <ramiro> but I'm too lazy to send a patch
[21:32:41 CET] <BtbN> ffmpeg with libx265 generates more heat than Prime95 in maximum heat mode. Impressive
[21:37:32 CET] <philipl> heh.
[21:37:40 CET] <philipl> BtbN: did you get a chance to look at the mpeg2 behaviour?
[21:38:32 CET] <BtbN> nope, was busy setting up new PC and stuff
[21:38:35 CET] <BtbN> But I can give it a go now
[21:40:27 CET] <BtbN> Do you have an mpeg2 sample at hand?
[21:43:49 CET] <philipl> I admittedly have not tested these recently, but the basic samples are relevant: interlaced mpeg2.
[21:43:52 CET] <philipl> http://samples.ffmpeg.org/MPEG2/interlaced/
[21:44:30 CET] <philipl> The main thing I saw was deadlocks in the cuvid/cuda library code on certain occasions.
[21:44:53 CET] <philipl> Not always repeatable. It seemed to happen more if I didn't attempt to deinterlace, and I didn't do explicit track mapping.
[21:44:54 CET] <BtbN> Just by decoding it?
[21:44:58 CET] <philipl> Transcoding
[21:45:03 CET] <philipl> with hwaccel
[21:45:56 CET] <philipl> Independent of mpeg2, there's the other problem I saw. As soon as I ask for b frames when transcoding, it will return a 'Not enough surfaces' error.
[21:46:08 CET] <philipl> Does not happen if I don't ask for the hwaccel (but it's still using cuvid and nvenc)
[21:47:07 CET] <BtbN> Also, did you have a chance to look at the scale/crop patch?
[21:48:05 CET] <BtbN> ./ffmpeg.exe -r 50 -deint adaptive -hwaccel cuvid -c:v mpeg2_cuvid -i D:/Cache/koncercik.mpg -c copy -c:v h264_nvenc -global_quality 22 -y out.mkv
[21:48:10 CET] <BtbN> this is working fine here
[21:49:15 CET] <iive> BtbN: talking about deadlocks, what happened with init order and out of memory error when using cuda and nvenc?
[21:49:29 CET] <BtbN> it was eventually fixed
[21:49:46 CET] <BtbN> Pushing the cuda context before encoding was missing
[21:49:58 CET] <BtbN> for some super weird reason, it worked without that before, which shouldn't ever have worked.
[21:51:06 CET] <BtbN> philipl, no, even running it a lot of times runs without it locking up
[21:52:58 CET] <iive> BtbN: so it was driver bug?
[21:53:14 CET] <BtbN> no
[22:02:35 CET] <iive> oh, so you push the context by the application.
[22:21:12 CET] <furqan> hello guys, i am trying to learn ffmpeg, i want to make an program that takes a mp4 video without audio and mp3 audio and output mp4 video with audio. could you guys suggest some starting pointers or functions that i need to look into?
[22:24:16 CET] <JEEB> under docs/examples there's a demux and mux examples, thos are what you'll need
[22:24:28 CET] <JEEB> since mp3 audio goes nicely into mp4 you don't need to decode or encode
[22:48:46 CET] <shurhat> Hello everyone, I wanted to know whether anyone is already working on the "ambisonic decoder" project or not?
[22:49:11 CET] <shurhat> @durandal_1707
[22:50:12 CET] <durandal_1707> shurhat: yes there is already someone
[22:50:59 CET] <shurhat> Being late to the party, can you please tell me which projects are currently open?
[22:53:11 CET] <durandal_1707> all
[22:57:08 CET] <shurhat> @durandal_1707 oh okay. Any pointers on approaching the ambisonic decoder project?
[22:58:14 CET] <durandal_1707> shurhat: try to understand other audio filters
[22:59:13 CET] <durandal_1707> mixing coefficients are in wikipedia article
[23:01:11 CET] <Mornix> Hi! I have an assignment which requires me to document a piece of code. I chose to do a filter in FFmpeg. Is this something that would be of use for me to submit a patch for the documentation changes?
[23:07:33 CET] <ubitux> writing filters is documented in doc/writing_filters.txt
[23:09:57 CET] <shurhat> @ubitux Thanks a lot. I'll be working on its qualification task.
[23:10:41 CET] <ubitux> i was replying to Mornix, i doubt writing filters is going to help you wrt writing a decoder
[23:12:47 CET] <shurhat> @ubitux oh okay, thats fine but one of the qualification task for the project I was talking about is implementing a shelf filter.
[23:19:36 CET] <Mornix> ubitux: Sorry, the filter already exists (it's the detelecine filter), I've just added some comments/documentation to the code.
[23:59:05 CET] <BBB> wm4: I think what michaelni means is that its legal for an application to do for (n = 0; n < 1000; n++) { av_packet_add_side_data(pkt, side_data_type=n, side_data_sz=1, side_data = [ 0 ]); }
[23:59:13 CET] <BBB> wm4: since its external API
[23:59:36 CET] <BBB> wm4: now obviously that is utterly ridiculous, and the app could probably even do it without using API since AVPacket is also exposed
[23:59:48 CET] <BBB> wm4: I think thats what he means
[00:00:00 CET] --- Thu Mar  9 2017