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

[burek]

[01:05:29 CEST] <jamrial> jkqxz: i disagree, sps parsing can and should be added to libavformat
[01:05:39 CEST] <jamrial> we did it for hevc, and av1
[01:05:58 CEST] <jamrial> making that function avpriv can be a pita in the long run
[01:06:21 CEST] <nevcairiel> also his current code is super wrong, semantically
[01:06:39 CEST] <nevcairiel> he passes some random pointer as AVCodecContext
[01:06:57 CEST] <nevcairiel> if the code ever tries to access it, nevermind a ssuming it may have a H264Context in its priv_data,  there is no c oming back from that
[01:07:00 CEST] <jamrial> it's for logging purposes. the AVClass is always first
[01:07:07 CEST] <jamrial> but yes, it's ugly
[01:07:08 CEST] <nevcairiel> but the API does not document it like that
[01:07:10 CEST] <nevcairiel> hence, wrong
[01:07:23 CEST] <nevcairiel> its an AVCodecContext argument, it needs to get one, a real one
[01:08:23 CEST] <jkqxz> So limited copy of H.264 header parsing?  I guess it doesn't actually need that much of it.
[01:08:49 CEST] <jamrial> yeah, only until the beginning of vui_parameters
[01:09:23 CEST] <cone-114> ffmpeg 03Lynne 07master:4d2f62150dba: aarch64/opusdsp: implement NEON accelerated postfilter and deemphasis
[01:11:46 CEST] <jkqxz> I wonder whether it could include cbs_h264_syntax_template.c.
[01:12:00 CEST] <jkqxz> Hmm, probably a bit too horrible.
[01:12:36 CEST] <jkqxz> A file include might be better than a complete reimplementation, still.
[01:25:08 CEST] <jamrial> jkqxz: i suggested to basically copy what you did in cbs_h264, since it's the simplest, most straightforward sps parsing function in the codebase
[01:25:53 CEST] <jamrial> compared to h264_ps, which does a lot more than just read bits, it should be trivial to copy into libavformat
[01:32:34 CEST] <jkqxz> The fatal case would be when the next version of this format decides it needs to know the value of some field that is currently discarded (something HRD, say).  Then you're entirely screwed with this avpriv approach.
[01:39:15 CEST] <jkqxz> Also the code does already write to some random memory through that forged AVCodecContext pointer: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264_ps.c;h=17bfa780ce26e78ffa37147d433abb3efb916220;hb=HEAD#l184>.
[01:57:26 CEST] <tmm1> is it possible to define and register an AVInputFormat at runtime?
[01:58:44 CEST] <jamrial> no
[02:00:26 CEST] <tmm1> thanks
[02:26:20 CEST] <jamrial> i could use other people's opinion on that thread
[10:37:27 CEST] <cone-522> ffmpeg 03joepadmiraal 07master:951561b64ee6: libavformat/dashenc : Prevent writing manifest files multiple times
[12:42:14 CEST] <cone-522> ffmpeg 03Don C. Bigler 07master:2be7c388db67: avdevice/opengl_enc: fix build error using msvc compiler
[14:36:46 CEST] <thardin> oof, that mxf avg_frame_rate ticket
[14:37:47 CEST] <thardin> I went over S336m and it turns out ULs are not allowed to contain bytes 0x80-0xFF
[14:38:28 CEST] <thardin> so the probe function can be improved somewhat
[14:52:59 CEST] <thardin> ah no, that's only for the first 8 bytes of the UL
[16:06:49 CEST] <thardin> getting a bit annoyed at all these hacks that don't have corresponding files in FATE
[16:13:41 CEST] <kurosu> thardin: I think michaelni and cehoyos also run ffmpeg against ticket files. Dunno how and how much though, but that's why they sometimes come back with issues
[16:20:01 CEST] <thardin> i see
[16:22:07 CEST] <thardin> still, should be in fate
[16:36:23 CEST] <rcabrera> Pasting this here as I wrote it on the wrong channel.
[16:36:42 CEST] <rcabrera> I am parsing this args with avfilter_graph and creating a filter graph, however even I get the frames from the buffersink the filter doesn't seem to be applied. 
[16:36:42 CEST] <rcabrera> https://pastebin.com/LATvky15
[16:36:42 CEST] <rcabrera> Any idea of why this could be happening?
[16:36:42 CEST] <rcabrera> The image should be flipped but instead I see the frame as if no filters were  applied
[16:42:55 CEST] <kurosu> thardin: I did that for some of the tickets that I fixed
[16:43:27 CEST] <kurosu> and some people/parties expressed interest in adding as many of these files as possible
[16:43:43 CEST] <kurosu> though size of the fate suite was mentioned
[16:47:01 CEST] <kurosu> and fate-suite grew by 20MB since I last sync'ed it \o/
[16:54:56 CEST] <durandal_1707> sent 319 bytes  received 572,663 bytes  163,709.14 bytes/sec
[16:54:58 CEST] <durandal_1707> total size is 1,158,179,157  speedup is 2,021.32
[17:02:10 CEST] <thardin> kurosu: the problem is that it's hard to write patches to certain things (like probing) if such samples can't be tested by all
[17:25:37 CEST] <durandal_1707> trac is 503
[17:30:48 CEST] <BtbN> %256 and &255 is equivalent, right? Or am I confusing myself?
[17:31:34 CEST] <JEEB> & 0xFF basically selects the least significant byte's value
[17:31:53 CEST] <JEEB> the hex-version at least makes it easier to see for me than just a 255
[17:31:54 CEST] <durandal_1707> negative is differents i think
[17:32:08 CEST] <BtbN> Only caring about unsigned ints
[17:33:12 CEST] <JEEB> so basically you will be getting the value between 0x00-0xFF from the least-significant byte. so I would *guess* for unsigned ints they're equivalent with % 256
[17:37:00 CEST] <BtbN> Yeah, I'm just gonna roll with the assumption. Compiler will optimize it anyway I guess
[17:39:51 CEST] <durandal_1707> do not use %
[17:47:47 CEST] <ubitux> BtbN: not if it's signed
[17:48:50 CEST] <ubitux> using % on x86 generates 5 more instructions here (gcc -O2) on signed int
[17:49:07 CEST] <BtbN> Yes, on signed ints it's clearly different
[17:49:34 CEST] <nevcairiel> & on signed probably also doesnt make much sense
[17:49:56 CEST] <nevcairiel> except for cases where one tries to be  very smart = p
[17:50:01 CEST] <BtbN> it ignores the signedness pretty much
[17:50:34 CEST] <ubitux> there are many places where we use signed instead of unsigned but rely on it to be positive
[17:50:56 CEST] <ubitux> it sometimes happen that you want to detect -1 only and not the whole negative space
[17:51:37 CEST] <nevcairiel> sure, but in reality you are not really dealing with a signed number
[17:51:49 CEST] <nevcairiel> i mostly meant & on negative n umbers is weird
[19:01:58 CEST] <durandal_1707> anybody here can read japanese? i need some bitmap translated
[19:02:10 CEST] <JEEB> sure
[19:03:45 CEST] <durandal_1707> https://0x0.st/zZk0.png
[19:04:23 CEST] <JEEB> this selection cannot be done with the free version
[19:06:06 CEST] <durandal_1707> aha, thanks, the other version of similar software is limited differently but somehow buggy
[19:06:21 CEST] <JEEB> np
[00:00:00 CEST] --- Thu Apr 11 2019