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

[burek]

[03:31] <cone-747> ffmpeg.git 03Andreas Cadhalpun 07master:840c3c05316a: libavcodec/ppc/mpegvideoencdsp.c: fix stack smashing in pix_norm1_altivec() and pix_sum_altivec()
[08:50] <akira4> hi, Is it possible to download only a specific test file from the fate-suite?
[08:53] <ubitux> akira4: make fate-rsync V=1, cancel it when you see the rsync command, and adjust it to your needs
[08:59] <akira4> okay. thanks.
[10:07] <saste> should we keep eq just because it might be faster than eq2?
[10:08] <saste> or should we discard it?
[10:09] <wm4> discard
[10:11] <nevcairiel> doesnt it like use the same code?
[10:11] <nevcairiel> should figure out why its faster
[10:13] <saste> nevcairiel, indeed
[10:35] <wm4> michaelni: what is with the av_find_best_pix_fmt_of_2() api changes?
[10:35] <wm4> michaelni: at one point you even move it from avcodec to avutil, without even bumping any versions
[10:36] <nevcairiel> isnt that like years ago already, and you bring it up now? :p
[10:36] <wm4> that was 2014
[10:36] <nevcairiel> thats an eternity in multimedia!
[10:36] <nevcairiel> but you are still rather late bringing it up :p
[10:38] <wm4> not adding the function to apichanges is apparently Libav's fault
[12:09] <michaelni> wm4, av_find_best_pix_fmt_of_2() ? there is no such function in release/2.2 and in release/2.3 its in libavutil
[12:13] <wm4> michaelni: well, technically that change just deprecates the old function, but both deprecations and new functions should be in apichanges
[12:17] <nevcairiel> so your gripe is only about docs now? send a patch! :D
[12:44] <wm4> yeah, I wanted to use the function, and had trouble to find out in what ffmpeg and libav versions it's supported
[13:59] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:47111d366dff: ffprobe: fix memleaks on errors
[14:07] <cone-861> ffmpeg.git 03agathah 07master:dac91bb4c3a7: avcodec/nvenc: set repeatSPSPPS flag for streaming
[14:18] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:f7a1c5e4d229: doc/APIchanges: Add av_find_best_pix_fmt_of_2() and av_get_pix_fmt_loss()
[14:38] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:0d64982828ae: doc/APIchanges: fill in and correct some values
[14:58] <cone-861> ffmpeg.git 03Derek Buitenhuis 07master:6c906ded380e: doc/platform: Reference only MSYS2 and MinGW-w64
[15:42] <anshul_mahe> I was trying to calculate crc32 of a packet, that packet doc say that crc32 should be done including crc32 bytes, how can it be done
[15:43] <anshul_mahe> I am encoding one packet, where at last there is field of crc32.
[15:44] <anshul_mahe> if i am considering last 4 byte in crc32 including last 4 byte crc(which are garbage yet). then crc32 would not remain consistent
[15:44] <anshul_mahe> what should I fill there
[15:48] <anshul_mahe> here are exact stements of doc http://pastebin.com/nKquiu6Z
[15:50] <nevcairiel> that text applies to decoding, where its quite common to include a crc in the last 4 bytes which results in a output of zero
[15:50] <nevcairiel> if you want to encode, you need to calculate this value differently
[15:51] <nevcairiel> i'm assuming you are talking about encoding here
[15:52] <kierank> anshul_mahe: you calculate the crc on the data then write it in the space
[15:52] <kierank> and when you decode you do the crc on data+crc to get zero
[15:52] <nevcairiel> what it seems to do is calculate the crc of the buffer without these 4 bytes, and then write the result into these 4 bytes, which should then give a crc of zero over the whole buffer
[15:52] <nevcairiel> a neat mathematical connection that it results in 0 exactly :d
[15:55] <anshul_mahe> ok thanks
[15:55] <anshul_mahe> I got it
[15:57] <kierank> anshul_mahe: how are you testing your scte35 remuxer by the way?
[15:59] <anshul_mahe> checking byte by byte, if data is same
[16:00] <anshul_mahe> in hls case, It has not yet worked, because I only of 2 events in the video shared
[16:00] <anshul_mahe> *only have
[16:00] <kierank> In my code I might be implementing scte104 to scte35 conversion at some point
[16:01] <anshul_mahe> yes I am implementing same
[16:01] <anshul_mahe> in bmdtool
[16:01] <anshul_mahe> which is ur code
[16:02] <anshul_mahe> I am implementing scte_35_encoder I have implemented scte_104_decoder
[16:03] <kierank> I will need to figure out how to get a scte 104 generator here
[16:04] <anshul_mahe> I have also implemented 2 more parser in bmdtool to generate scte-104
[16:05] <anshul_mahe> one is vanc and other is smpte 2010
[16:05] <kierank> smpte 2010 is vanc
[16:06] <anshul_mahe> which code is urs, is it have interface with bmd device or mxp
[16:06] <kierank> what is mxp?
[16:07] <anshul_mahe> *mxf
[16:07] <anshul_mahe> sry
[16:08] <kierank> blackmagic
[16:09] <kierank> probably i won't work on it unless I can find a scte 104 source
[16:09] <aetasx> you guys have any theories as to why running a hqdn3d=1 filter right before x264 compression would end-up requiring more space?
[16:10] <anshul_mahe> aetasx: no i dont have any
[16:10] <anshul_mahe> aetasx: I dont know what is it
[16:12] <anshul_mahe> I am still unable to get correct crc32, here is 4 line of code. means I checked including that crc bytes it is not coming 0 
[16:13] <anshul_mahe> I am using crc32 function from tools, here is code http://pastebin.com/8rFsvCSQ
[16:13] <kierank> there are different crc polynomials
[16:13] <kierank> are you using the right one
[16:15] <iive> aetasx: repeat the test with fixed quant, instead of constant rate factor. 
[16:17] <anshul_mahe> kierank: What polynomial should I use, I have to follow ITU-T H.222.0 / ISO/IEC 13818-1 
[16:17] <kierank> read the spec
[16:17] <anshul_mahe> but those docs dont say a lot about polynomial they are giving an equation 1 +x +...... +x ^32
[16:17] <kierank> that's a polynomial
[16:18] <kierank> I think you should read up on crc32
[16:18] <anshul_mahe> yes, but what is x, to calculate it and pass in parameter
[16:19] <kierank> read up on crc32
[16:19] <kierank> and you'll find out
[16:20] <anshul_mahe> ok i will try again.
[16:33] <wm4> is there a flag yet that signals whether a generic RGB format has alpha?
[16:33] <wm4> or does ffmpeg consistently use RGB0 etc.? (though that doesn't cover all cases)
[16:34] <Daemon404> what was the point of RGB0 and RGBX again
[16:34] <wm4> signaling if the 4th channel contains something
[16:36] <Daemon404> 'something' ?
[16:37] <wm4> alpha or padding
[16:37] <wm4> don't ask such complicated questions
[16:38] <wm4> I guess RGB0 is supposed to have the 4th component set to 0?
[16:38] <nevcairiel> the point is to output 32-bit RGB (for alignment, etc) without a meaningful alpha channel
[16:38] <nevcairiel> no idea why there is two of those
[16:38] <Daemon404> ok... but why does that need its own colorspace
[16:38] <Daemon404> RGBA with 0 is identical
[16:39] <wm4> and you still don't know whether the alpha channel is significant, or what kind of alpha it uses (premultiplied or straight)
[16:39] <nevcairiel> one might think  its a fully transparent image if you get RGBA with all 0 for alpha :p
[16:39] <Daemon404> well FF
[16:40] <rcombs> is RGB0 0's in the 4th byte and RGBX garbage?
[16:40] <nevcairiel> the code might still try to interpret the alpha, despite the codec never having any meaningful data in there, so signaling it as empty is useful
[16:40] <Daemon404> i dont see how its useful
[16:40] <Daemon404> other than ricing
[16:41] <nevcairiel> its more than ricing, knowing if you have to take care of a alpha channel or you can just ignore it can have serious performance implications
[16:41] <Daemon404> i should rephrase
[16:41] <Daemon404> why is it a colorspace on its own
[16:41] <Daemon404> instead of a flag
[16:41] <nevcairiel> because we dont have a concept of flags? :)
[16:41] <rcombs> also, I just sent a patch for an extremely silly dashenc issue
[16:41] <wm4> there are 4 kinds of situations: alpha is set to a constant value, alpha is garbage, alpha is premultiplied alpha, alpha is straight alpha
[16:41] <wm4> so a flag would be better
[16:42] <wm4> nevcairiel: we do for audio
[16:42] <wm4> because someone wanted to save 1 extra sample format, there's some flag that tells you whether audio is 24 bit or really 32 bit
[16:42] <nevcairiel> the premultiplied doesnt actually affect the alpha channel itself .. it affects all other channels, and i'm not sure i have seen a codec that actually stored pre-multiplied
[16:43] <wm4> and actually there are a shitload of other flags for images too (like colorspace)
[16:43] <rcombs> const char *number_format = DASH_TMPL_ID_TIME ? "lld" : "d"; <-- oops
[16:43] <nevcairiel> heh
[16:43] <nevcairiel> does it really hurt anything to use lld for everything though?
[16:44] <rcombs> yup
[16:44] <rcombs> because that's a 4-byte int
[16:44] <nevcairiel> i guess printf depends on that how to read the value
[16:44] <wm4> MUST MICROOPTIMIZE
[16:44] <rcombs> and I've just been headscratching at a Win32 issue where it prints out <actual value> + <random in the upper 4 bytes>
[16:44] <wm4> can't waste cycles when muxing dash
[16:45] <nevcairiel> well to avoid that you would need to cast every value
[16:45] <rcombs> yeah, that'd be fine
[16:45] <nevcairiel> its fascinating printf doesnt cause more crashes or undefined behaviour with such things going wrong so easily
[16:46] <rcombs> and well, it wasn't random; it was a deterministic value of "whatever the next thing on the stack was"
[16:46] <rcombs> which ended up being very consistent
[16:46] <nevcairiel> just unexpected
[16:46] <rcombs> yeah
[16:47] <rcombs> I just corrected it to const char *number_format = (id_type == DASH_TMPL_ID_TIME) ? "lld" : "d";
[16:47] <wm4> lol that code is so "clever"
[16:48] <rcombs> :/
[16:48] <wm4> it creates a format string in a complicated function, or something
[16:48] <rcombs> yeah, not great
[16:48] <Daemon404> the code is bound to be bad
[16:48] <Daemon404> it's generatign xml
[16:48] <Daemon404> without a lib
[16:48] <wm4> ooh
[16:48] <wm4> wonderful
[16:48] <nevcairiel> i think its even weirder that we have a dash encoder but not a decoder .. and all that because hand-crafting xml is actually something you can do (although i would argue you possbly shouldn't), but writing your own parser would be super painful :p
[16:49] <wm4> and using an external lib is taboo
[16:49] <nevcairiel> libxml2 is apparently evil
[16:49] <nevcairiel> well it is kinda huge
[16:49] <nevcairiel> but it is xml
[16:49] <wm4> the mainstream xml libs are indeed evil
[16:49] <wm4> there are some smaller ones which are almost sane
[16:49] <rcombs> Daemon404: the insane bit here isn't even the XML
[16:49] <wm4> of course I forgot which ones
[16:50] <nevcairiel> but those are probably not well known or well distributed, so thats an argument one of the NIH crowd would use :D
[16:50] <nevcairiel> I would like a dash demuxer, otherwise I'll have to find a solution to that at some point ....
[16:50] <nevcairiel> its becoming more popular
[16:51] <rcombs> don't we still not handle DASH indexes properly anyway?
[16:51] <wm4> I'd be totally fine if someone would NIH a xml scanner, which could handle 90% of xml, but the stuff the existing "parsers" in libav* do is just painful and dumb
[16:51] <Daemon404> ... or just require an xml lib
[16:51] <rcombs> <insert quip about XML and regexes>
[16:51] <nevcairiel> we already get complaints of people trying to play youtube 1080p stuff  which apparently is mostly only available in dash now
[16:52] <wm4> aren't there libs for dash?
[16:52] <rcombs> (it's probably a good thing we don't link a regex lib)
[16:52] <Daemon404> not in c
[16:52] <wm4> nevcairiel: 1080p youtube is easy
[16:52] <wm4> nevcairiel: they're just separate (but unfragmented) files for audio and video
[16:52] <iive> there is a third option. Add xml parser lib to the glibc
[16:52] <wm4> nevcairiel: except with one catch, the lavf mp4 demuxer behaves dumb when reading them
[16:52] <nevcairiel> well syncing up those would still require manual hackery
[16:53] <iive> like iconv :)
[16:53] <wm4> most video players can do external audio files
[16:54] <nevcairiel> i've just ignored it for now
[16:55] <nevcairiel> i have a looong list of things to work on anyway
[16:55] <kierank> nevcairiel: do you know if there is an atmos software decoder
[16:55] <wm4> besides, there are people here who don't like demuxer-based "unsegmenting", like mp4 edit lists (but also DASH and HLS) would require
[16:55] <kierank> dash is higher level than lavf imho
[16:55] <nevcairiel> kierank: not heard of any commercial software supporting it .. maybe dolby has a reference one locked in some fortress somewhere, but not that i've seen
[16:56] <kierank> i have considered trying to RE it from firmware updates
[16:56] <wm4> kierank: simple, send the shit via hdmi digital passthrough to expensive consumer hw
[16:56] <nevcairiel> that works of course
[16:56] <nevcairiel> it already took me a day of RE'ing just to fix our TrueHD parser to not barf on the extra data
[16:57] <nevcairiel> but i may just suck at RE'ing
[16:57] <nevcairiel> :D
[16:57] <nevcairiel> i wonder if libav finally applied the patches, its been rotting for months on their ML and some user bumps it once a blue moon because they want it applied, but nothing happens
[16:58] <kierank> the libav way (tm)
[16:58] <nevcairiel> nope, not applied
[16:58] <nevcairiel> i even sent it to them the same day i sent it to ffmpeg
[16:58] <nevcairiel> that was september
[16:58] <nevcairiel> :d
[16:59] <iive> nevcairiel: maybe you should have sorted the patch alphabetically first?
[17:25] <akira4> ubitux, I extracted the webvtt code from the .c files. The SRT file--http://pastebin.com/wgX5XGUU and the webvtt---http://pastebin.com/YCAmwPyf
[17:25] <akira4> I'm not sure the output is correct though.
[17:25] <ubitux> well, where is the color information?
[17:26] <akira4> the code was printing some class tags.
[17:27] <ubitux> so you probably need to define the class somewhere
[17:27] <ubitux> with the color settings
[17:27] <akira4> hmm.
[17:31] <akira4> but won't that be a part of a CSS file? 
[17:33] <ubitux> an external file? mmh maybe they're doing this
[17:34] <ubitux> what is the code doing?
[17:34] <ubitux> where are these class defined?
[17:37] <wm4> hm, so apparently av_find_best_pix_fmt_of_2() returns bullshit if endian swapping is involved
[17:38] <akira4> link to the current diff : http://pastebin.com/nAc3ZBLu.
[17:39] <kierank> can libavfilter support changing the resolution on the fly
[17:39] <wm4> kierank: no, you have to recreate it
[17:39] <kierank> ok not the end of the world
[17:40] <ubitux> akira4: ah, hum, so it just flags with a weird class name if it matches very known color, and... the user is responsible for defining its css?
[17:41] <ubitux> sounds strange
[17:41] <ubitux> make sure it doesn't generate these class
[17:41] <ubitux> somewhere, somehow
[17:41] <akira4> yeah.
[17:41] <ubitux> there might be a way of inlining the css inside the webvtt
[17:41] <akira4> I was reading something related to cues in webvtt
[17:42] <akira4> they have a color property so maybe that could work.
[17:42] <kierank> wm4: I'm going to hope it doesn't leak on reconfigure then
[17:42] <kierank> because I'll need to reconfigure possibly dozens of times per minute
[17:43] <wm4> what's the use case?
[17:44] <kierank> needing to output a constant pixel format, resolution, etc from various different inputs and pixel formats
[17:44] <wm4> ah, I guess my problem with av_find_best_pix_fmt_of_2() was a user error (shouldn't have attempted to use the undocumented loss_ptr)
[17:44] <wm4> kierank: and why does this happen every few seconds?
[17:45] <kierank> the input stream can be switched or loss or whatever at any time
[17:45] <kierank> lost*
[17:46] <kierank> thankfully the filter chain shouldn't buffer
[17:49] <wm4> michaelni: ya16be -> rgba64 creates vertical artifacts (like bars), is this known or should I report it?
[18:39] <michaelni> wm4, please report it
[18:40] <wm4> k
[18:40] <wm4> just wondering, would this conversion discard bits?
[18:41] <michaelni> ideally it should not, id have to check the implementtation though
[19:09] <ubitux> http://ubitux.fr/pub/pics/_palette-optim.png :(
[19:09] <wm4> michaelni: #4278 
[19:09] <wm4> ubitux: pretty good, is it drugs?
[19:09] <wm4> LSD visualization
[19:09] <ubitux> almost, it's lavfi
[19:12] <cone-861> ffmpeg.git 03Paul B Mahol 07master:7849ce438efe: avfilter/vf_lenscorrection: support 8bit planar RGB formats
[20:10] <saste> well, because of libcdio I need to split the input depending on the @chapter info
[21:27] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:fdb93996811b: avfilter/vf_showinfo: show timebase & framerate too
[21:27] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:95d04690aa4f: swscale/input: Fix alpha of YA16 input
[21:27] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:f30798584fd9: swscale/input: fix rgba64 alpha non native
[21:51] <cone-861> ffmpeg.git 03Derek Buitenhuis 07master:da9bffaf08a1: doc/platform: Reference only MSYS2 and MinGW-w64
[21:51] <cone-861> ffmpeg.git 03Michael Niedermayer 07master:5f764f43d27b: Merge commit 'da9bffaf08a1173451da1b4e1ae50881e7093642'
[21:57] <cone-861> ffmpeg.git 03Christophe Gisquet 07master:9a9b088d9e2d: libavformat/img2dec: fix warning when !HAVE_GLOB
[23:53] <cone-861> ffmpeg.git 03Brian Brice 07master:f845ae0c8ed8: librtmp: Allow changing the socket send buffer size
[23:59] <nevcairiel> oh boy, more crazy hacks for debian snobs :d
[00:00] --- Thu Jan 22 2015