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

burek burek021 at gmail.com
Mon Apr 25 02:05:03 CEST 2016


[00:38:55 CEST] <pfelt> hey all.  not sure where to even check for this, but is there a style guide for new filter submissions?
[00:40:56 CEST] <ubitux> style guide?
[00:43:00 CEST] <ubitux> there is the overview doc/writing_filters.txt i mentioned to you last time, then regarding coding style you just follow the style you see in other filters, then for submission click on "contribute" in the left menu of ffmpeg.org
[00:49:41 CEST] <pfelt> yeah.  it was more of a coding style question
[00:49:58 CEST] <pfelt> i've still got a lot of cleanup to do before i can submit, i just thought i'd ask tho
[00:51:40 CEST] <rcombs> four-space indentation, spaces around braces, newline before the opening brace in a function, ~80-character lines unless it's inconvenient&
[00:51:52 CEST] <rcombs> really just look around a bit and match the norm
[00:52:53 CEST] <wm4> basically k&r
[00:53:23 CEST] <pfelt> alternative question
[00:53:46 CEST] <pfelt> the basis for my filter is the movie filter.  i've modified it a bit.  new filter or patchset against movie?
[00:54:05 CEST] <ubitux> patchset against movie
[00:54:36 CEST] <ubitux> you can define a new filter within the same file if deemed necessary
[00:54:44 CEST] <ubitux> see for insteance blend/tblend
[00:55:07 CEST] <ubitux> assuming it's more appropriate than just adding an option
[00:56:55 CEST] <pfelt> the major change is a few new options to allow for changing the stream on the fly
[00:57:08 CEST] <pfelt> so it really *can* be a patset
[00:58:18 CEST] <rcombs> http://www.wired.com/2016/04/ingenious-way-iranians-using-satellite-tv-beam-banned-data/ neat
[01:00:23 CEST] <thardin> sounds like a use case for amateur satellites
[01:00:42 CEST] <thardin> if someone can design a good X-band modem
[01:55:09 CEST] <pfelt> ok, another seemingly silly question.  if i call av_strdup() do i need to av_freep() it?
[01:55:25 CEST] <ubitux> yes
[01:56:01 CEST] <pfelt> hmm.  ok.  when i had the code in i'd segfault so i wasn't sure.  it's probably something stupid i'm doing
[02:00:00 CEST] <DHE> you using av_freep properly? it wants a pointer to a pointer
[02:01:48 CEST] <pfelt> then no.  i didn't look that deep into the code to actually see that
[02:02:08 CEST] Action: pfelt was trying av_freep(char *)  not av_freep(char **)
[02:02:26 CEST] <pfelt> not sure if that showed up right or showed up as an emoticon :D
[02:03:39 CEST] <pfelt> indeed the docs do show it saying pointer to a pointer.  i stopped at the av_freep(void *  ) definition
[02:08:32 CEST] <rcombs> I'm not sure why the prototype takes void* instead of void**
[02:11:16 CEST] <pfelt> isn't it *technically* right?   just a tiny bit misleading?
[02:23:11 CEST] <DHE> void** means you can do one dereference safely before hitting the "black box" of (void*)
[02:23:31 CEST] <DHE> the idea is that it will NULL out the variable for you reducing the odds of a use-after-free
[02:23:53 CEST] <DHE> a lot of API functions do the same thing, like av_frame_free and av_packet_free
[02:54:31 CEST] <cone-016> ffmpeg 03Michael Niedermayer 07master:ea41ab098711: avformat/mpegts: factor duplicate seek back code into mpegts_resync
[02:54:31 CEST] <cone-016> ffmpeg 03Michael Niedermayer 07master:dbe1dd59e0d3: avformat/mpegts: Skip over broken 0x80 headers
[03:03:32 CEST] <rcombs> yeah, nothing invalid about using void* there, it's just not as clear
[03:23:43 CEST] <rcombs> wow, they're (widevine) not even using AES-NI
[03:35:38 CEST] <jamrial> rcombs: whatever happened to your aesni stuff?
[03:35:49 CEST] <jamrial> the cpu flag is in, but not the actual asm
[03:35:54 CEST] <rcombs> been sitting there for a while
[03:36:10 CEST] <rcombs> I forget if anything was actually blocking or if it just hadn't been explicitly OK'd
[03:36:45 CEST] <jamrial> re-send the bits that haven't been commited, then
[04:47:18 CEST] <pfelt> DHE: if you're still around, that makes sense.  i haven't had to worry too much about it because src_movie.c already has done it.  but yeah.  i'm following you now
[05:03:59 CEST] <DHE> also you're supposed to finish your drink if you find a function whose prototype is (void***)
[05:04:00 CEST] <DHE> :)
[06:43:01 CEST] <Timothy_Gu> ubitux: seems like another one of those bit flips of yours http://fatebeta.ffmpeg.org/log/x86_64-archlinux-gcc-checkheaders/20160424043633/compile
[06:43:16 CEST] <Timothy_Gu> ' ' == 0b00100000
[06:43:31 CEST] <Timothy_Gu> '$' == 0b00100100
[09:06:13 CEST] <cousin_luigi> Greetings.
[09:59:39 CEST] <flux> timothy_gu, pretty nice, I don't recall ever having seen such an issue :)
[10:44:59 CEST] <cousin_luigi> Is there an official position in regard to libdca and librtmp? Should internal encoders/decoders be preferred to them, in the stable branch?
[10:45:08 CEST] <cousin_luigi> Well, latest stable.
[11:36:37 CEST] <ubitux> Timothy_Gu: ... ok well, i'm going to try something
[11:36:44 CEST] <ubitux> i disabled one of the disk from the raid
[11:36:50 CEST] <ubitux> will see if it helps
[11:36:56 CEST] <ubitux> might be a bug in the firmware or something
[12:09:37 CEST] <BtbN> Hm, I expected more reactions to non-nonfreee nvenc.
[12:19:25 CEST] <cone-550> ffmpeg 03Michael Niedermayer 07master:c84ba07db4ab: avformat/mux: Check that deinit is set before calling it
[12:37:27 CEST] <cone-550> ffmpeg 03Diego Biurrun 07master:02cd8bb9cb43: h264: Clean up #includes
[12:37:28 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:64ae08ffec1a: Merge commit '02cd8bb9cb4381c50f42a9284098cc8a33d397db'
[12:40:54 CEST] <cone-550> ffmpeg 03Michael Niedermayer 07master:2e67a99fbc6b: avfilter/vf_drawtext: Check return code of load_glyph()
[12:43:03 CEST] <Daemon404> wm4, it's also going to be painful afaict. 
[12:44:26 CEST] <nevcairiel> probably
[12:44:42 CEST] <nevcairiel> all this h264 refactoring has generally been painful, and the codec doesnt run faster for it, and it usually introduces bugs
[12:44:47 CEST] <nevcairiel> so, meh all around
[12:45:02 CEST] <Daemon404> i dont know what the end goal is
[12:45:14 CEST] <Daemon404> just nicer code?
[12:47:46 CEST] <wm4> wouldn't be a problem if there'd be only 1 code base
[12:48:45 CEST] <wm4> also btw., at this point, all blame for reunification not happening can be put on Libav
[12:49:11 CEST] <Daemon404> i wouldnt say all
[12:49:25 CEST] Action: Daemon404 was in the room last year, saw more than that
[12:49:56 CEST] <iive> wm4: all blame have always been on libav
[12:50:00 CEST] <cone-550> ffmpeg 03Diego Biurrun 07master:f4d581cda389: lavc: Deduplicate zigzag_scan table
[12:50:01 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:a5a6621616aa: Merge commit 'f4d581cda3897f66c1dda7586b93f86a591dbbef'
[12:50:03 CEST] <wm4> iive: no
[12:50:18 CEST] <wm4> well I guess there are remaining "factors" in the ffmpeg side
[12:50:24 CEST] <Daemon404> carl factor?
[12:50:49 CEST] <wm4> names withheld
[12:52:36 CEST] <iive> the universal excuse
[12:53:01 CEST] <iive> honestly didn't you get tired at blaming carl for everything?
[12:55:27 CEST] <Daemon404> only when he gets tired of living up to his end of the deal
[12:55:28 CEST] <wm4> maybe whenc arl stops vocally blaming Libav for everything
[12:55:49 CEST] <iive> like?
[12:56:13 CEST] <Daemon404> right, im not getting into this, on a Sunday
[12:56:23 CEST] Action: Daemon404 goes back to doing productive thigns
[12:57:28 CEST] <iive> this is en example of poisonous atmosphere
[12:57:58 CEST] <Daemon404> yes, cause by carl
[12:58:07 CEST] <iive> when somebody is smeared, without even having to point concrete and actual "wrongs"... just hyping and reiterating old rumors
[12:58:19 CEST] <Daemon404> because i tire of having to explain it every goddamn time
[12:58:32 CEST] <iive> Daemon404: ok, give me example for carl obstructing reunification in the last year.
[12:58:40 CEST] <Daemon404> were you in the room?
[12:58:56 CEST] <Daemon404> about every single thing that came up he tried to smack on Libav
[12:59:29 CEST] <Daemon404> now seriously, im not discussing bloody fork politics on Sunday
[12:59:29 CEST] <iive> wasn't "the room" a year ago?
[12:59:34 CEST] <Daemon404> no, 6 months or less
[12:59:41 CEST] <wm4> * Daemon404 goes back to doing productive thigns <- that's wrong on a sunday too
[13:00:35 CEST] <iive> wm4: were you "in the room"?
[13:00:41 CEST] <wm4> no
[13:01:10 CEST] <iive> the conversations in the room were kept "secret" on purpose
[13:01:12 CEST] <rcombs> who cares who "started it"
[13:01:39 CEST] <iive> so nobody would be able to sabotage the unification.
[13:01:45 CEST] <cone-550> ffmpeg 03Diego Biurrun 07master:a7da517f6a5c: h264data: Move all data tables from a header to a .c file
[13:01:46 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:9809371aa540: Merge commit 'a7da517f6a5c472f46f67dd33bb6b95ccc919923'
[13:02:11 CEST] <Shiz> that worked out less well than expected it seems
[13:02:25 CEST] <iive> my point exactly.
[13:02:48 CEST] <iive> it was just temporarily measure, for month or two...
[13:09:47 CEST] <ubitux> iive: pretty sure blaming ppl won't help solving the situation, unless you are in the state of mind of harassing until they're fed up an leave. unfortunately, this is not anywhere close ethically viable, and apparently ppl are so stubborn on both sides that they somehow keep doing their shit. so what we want instead is having cooperation, and in this case, blame has the opposite effect
[13:10:40 CEST] <iive> ubitux: tell that to Daemon404
[13:10:55 CEST] <wm4> in any case, we'd like for carl to adjust his behavior, but he NEVER changes
[13:11:07 CEST] <wm4> and iive started this whole blaming discussion too
[13:11:34 CEST] <iive> wm4: actually you did.
[13:11:43 CEST] <ubitux> wm4: i didn't notice any particular behavior issue with that regard from carl recently
[13:12:04 CEST] <iive> ubitux: and that was my point entirely
[13:13:17 CEST] <wm4> iive: no I didn't
[13:14:19 CEST] <iive> wm4: you used blame and libav in a sentence first :P
[13:14:37 CEST] <wm4> I didn't blame any persons, just the behavior of Libav as a project
[13:15:08 CEST] <iive> wm4: it was Daemon404 that blamed a person. for something he has said in a secret meeting 
[13:15:37 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:922b7e6d86e6: intrax8: Use local destination buffers
[13:15:38 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:1a9ffc59d27c: Merge commit '922b7e6d86e6197dfa5ebde602dd12cc66fb5f1f'
[13:15:42 CEST] <Shiz> i have to say this is one of the most counterproductive arguments i've read
[13:15:54 CEST] <wm4> and it always goes this way
[13:16:33 CEST] <iive> he said, she said..
[13:17:20 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:65127450add5: intrax8: Make x8_init_block_index not use mpegvideo fields
[13:17:21 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:627115b3e43f: Merge commit '65127450add50c3bca307edc0517d2e8382717a0'
[13:17:22 CEST] <iive> wm4: i'm still interested what you had in mind, when you blamed libav (as project)
[13:19:31 CEST] <wm4> we've made plenty of concessions towards Libav... michaelni stepped down as leader, and we've made proposals how the unification could go
[13:19:36 CEST] <wm4> but Libav showed zero interest
[13:26:32 CEST] <iive> that's not surprising.
[13:30:56 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:68127e1bf803: intrax8: Keep a reference to the context idctdsp
[13:30:57 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:83e0b1b1d7b4: Merge commit '68127e1bf8037a6e0acd6401cc8c5da950e3fa0a'
[13:47:44 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:577393321c38: intrax8: Carry over the loopfilter value in ff_intrax8_decode_picture
[13:47:45 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:eaeba6f241e0: intrax8: Pass the output frame to the decoding function
[13:47:46 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:65f14128c4bc: intrax8: Use a constant buffer instead of a ScratchpadContext
[13:47:47 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:8072345e9f86: intrax8: Keep a reference to the GetBitContext reader
[13:47:48 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:1eaae7abb8f2: intrax8: Reference the current AVCodecContext
[13:47:49 CEST] <cone-550> ffmpeg 03Vittorio Giovara 07master:159323897f54: intrax8: Add a local BlockDSPContext and initialize it
[13:47:50 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:e5c655b09817: Merge commit '577393321c389ad2973bec6168a8045c94a9e099'
[13:47:51 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:36dad146935a: Merge commit 'eaeba6f241e0de0e797be10f8fda967ef8489e64'
[13:47:52 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:93c61c980d63: Merge commit '65f14128c4bcf8fcd9d3ba1e20b7a22057c9cfb0'
[13:47:53 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:50fa5715bcc3: Merge commit '8072345e9f86d88fbc4a15c17cb03f1e4701c9a5'
[13:47:54 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:52692eed615c: Merge commit '1eaae7abb8f208fefb4e8b9e983e61b2499206a3'
[13:47:55 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:896fce850966: Merge commit '159323897f545e7405fb9db234e0ba123e174376'
[13:49:15 CEST] <cone-550> ffmpeg 03Ico Doornekamp 07master:edf54887e293: rtpdec_jpeg: fix low contrast image on low quality setting
[13:49:16 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:4fe4c5c3761a: Merge commit 'edf54887e2935a30f9d9a46dd806802c3c867c0e'
[13:51:53 CEST] <cone-550> ffmpeg 03Martin Storsjö 07master:cdb1665f70de: aarch64: Make transpose_4x4H do a regular transpose
[13:51:54 CEST] <cone-550> ffmpeg 03Derek Buitenhuis 07master:87b8e9500874: Merge commit 'cdb1665f70def544ddab3e3ed3763ef99c8b3873'
[16:10:56 CEST] <wm4> [FFmpeg-devel] Cannot compile ffmpeg-0.10.16
[16:10:58 CEST] <wm4> hell
[16:11:19 CEST] <wm4> outdated Oracle crap
[16:11:28 CEST] <JEEB> oracle this time?
[16:13:57 CEST] <wm4> "please excuse me, that I bother you with this old version of ffmpeg, however, 
[16:13:57 CEST] <wm4> javafx 8 requires libavcodec53 and libavformat53 on linux systems, which, as 
[16:13:57 CEST] <wm4> far as I know, requires that I compile ffmpeg 0.10.16. "
[16:14:54 CEST] <JEEB> lol
[16:14:59 CEST] <JEEB> not even main part of java :P
[16:22:54 CEST] <anadon> Can someone come over to #ffmpeg to help me with a libav question.  It's been a few days of me asking to no response.
[16:24:22 CEST] <JEEB> wm4: so something like this https://github.com/jeeb/ffmpeg/commit/41b8aa0dfe3dfdf1016225854b271a586454edd7 ?
[16:24:33 CEST] <JEEB> with regards to the final version of the PGS fix
[16:25:09 CEST] <wm4> looks good to me
[16:25:57 CEST] <JEEB> also with this the non-CCIR macros could just be removed since IIRC nothing uses them any more in lavc :)
[16:26:12 CEST] <wm4> awesome
[16:26:12 CEST] <JEEB> people found out how often full range YCbCr was being used in paletted formats
[16:26:52 CEST] <nevcairiel> its not about full-range ycbcr, its really more about limited range rgb, which should never exist
[16:27:35 CEST] <JEEB> I thought it was just that they thought that the input values were already in the full range and thus quantization wouldn't be required
[16:27:56 CEST] <JEEB> and the _CCIR ones would just do it so that the range goes from limited to full
[16:30:39 CEST] <jkqxz> Limited-range RGB is an abomnination.  Really nothing in software should ever see it, but the requirement in CEA-861/HDMI to use it on the wire is inconsistently implemented and leads to horrible fail.
[16:32:18 CEST] <JEEB> there, posted the patch on ML
[16:32:43 CEST] <wm4> jkqxz: indeed, fuck that shit
[16:33:02 CEST] <JEEB> pretty much
[16:38:25 CEST] <jkqxz> (The only consistently-working answer to the RGB limited-range problem if you are an HDMI receiver is "pretend you are actually DVI receiver".  If you need audio, sucks to be you.)
[17:47:10 CEST] <JEEB> michaelni: would that PGS patch I posted be something considered for backporting since as far as I can tell PGS subpictures have had the wrong RGB range and colorimetry for ages and I guess it would be nice to fix it
[22:17:13 CEST] <michaelni> JEEB has that been pushed to master ? (i dont want to backport things that have not yet been pushed to master)
[22:17:29 CEST] <JEEB> not yet since no comments on the latest iteration. just noted for the future if it gets merged
[22:17:59 CEST] <michaelni> ok, then please backport or ping me when its pushed
[22:18:07 CEST] Action: michaelni will forget
[22:18:17 CEST] <JEEB> gotcha
[23:05:51 CEST] <cone-749> ffmpeg 03Jan Ekström 07master:9779b6262471: pgssubdec: fix subpicture output colorspace and range
[23:53:35 CEST] <durandal_1707> size is 8x8 yet strachpad is of 42 size?
[23:57:07 CEST] <durandal_1707> its so side libav devs ignore my fixes
[23:57:15 CEST] <durandal_1707> *sad
[00:00:00 CEST] --- Mon Apr 25 2016


More information about the Ffmpeg-devel-irc mailing list