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

[burek]

[01:14] <cone-195> ffmpeg.git 03Christophe Gisquet 07master:585047bb7dae: h264: do not return on sidedata allocation failure
[01:45] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:7444cf9a9c0b: avcodec/imc: Fix bitstream buffer padding
[02:28] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:8231764784a4: ffv1dec: check that global parameters do not change in version 0/1
[02:28] <cone-195> ffmpeg.git 03Luca Barbato 07release/2.2:23376ae2f024: mpegts: Define the section length with a constant
[02:28] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:1578986a0da4: proresenc_kostya: properly account for alpha
[02:28] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:5b1a953960dd: Merge commit '8231764784a405f546e9c427a6de22d3f4de5c35' into release/2.2
[02:29] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:f1da6691a41f: Merge commit '23376ae2f0247ff659724b6a5313639db0c991ad' into release/2.2
[02:42] <cone-195> ffmpeg.git 03Luca Barbato 07release/2.2:7788297a5965: mpegts: Do not try to write a PMT larger than SECTION_SIZE
[02:42] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:afbaf6b367e1: Merge commit '7788297a59656ececd84f602292bfeb79f7eedd7' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Reinhard Tartler 07release/2.2:493a92313fa6: Prepare for 10.4 Release
[02:58] <cone-195> ffmpeg.git 03Reinhard Tartler 07release/2.2:ee9e966296d7: Update Changelog for v10.4
[02:58] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:b3f48a5044fd: proresenc: Remove unneeded parameters from encode_alpha_plane()
[02:58] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:e912b0777b24: proresenc: Report buffer overflow
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:9e6d8c309f27: Merge commit 'ee9e966296d74ca3836be5b5adc839cfc73d8c98' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:35fe089dd9b6: Merge commit 'b3f48a5044fd04539337e91d28022207c9d3b9e8' into release/2.2
[02:58] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:459a84ada3b7: Merge commit 'e912b0777b24133df27836b6c529faa89af588dc' into release/2.2
[03:13] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:a437298de55c: proresenc: Realloc if buffer is too small
[03:13] <cone-195> ffmpeg.git 03Christophe Gisquet 07release/2.2:f25f5f8c62ec: proresenc: Properly account for alpha plane
[03:13] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:bb1d75e6c5e3: Merge commit 'a437298de55c6a6a4f06b12335b3891bf4459082' into release/2.2
[03:13] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:8b55f67e3ee3: Merge commit 'f25f5f8c62ec7728ee7f5dcc8f1abd0dc6235735' into release/2.2
[03:26] <cone-195> ffmpeg.git 03Diego Biurrun 07release/2.2:37e2d574ddce: setpts: Add missing inttypes.h #include for PRId64
[03:26] <cone-195> ffmpeg.git 03Michael Niedermayer 07release/2.2:5ac46a0969a3: Merge commit '37e2d574ddcedc25e32bd963737b033354543789' into release/2.2
[05:03] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:949057c95879: avcodec/h264: do proper cleanup in ff_h264_alloc_tables() in case DPB alloc fails
[05:03] <cone-195> ffmpeg.git 03Michael Niedermayer 07master:1fa35e4352cc: avcodec/h264_slice: More complete cleanup in h264_slice_header_init()
[10:07] <cone-195> ffmpeg.git 03Muhammad Faiz 07master:c82a288f8747: avfilter/showcqt: add fontcolor option
[10:20] <cone-195> ffmpeg.git 03Clément BSsch 07master:45c7f3997ea1: avutil/pixelutils: faster pixelutils_sad_[au]_16x16
[15:29] <cone-195> ffmpeg.git 03Reimar Döffinger 07master:8fc9bd0d32f0: dict.c: Free non-strduped av_dict_set arguments on error.
[15:50] <ubitux> saste: yes, "timecodes" are for a few known fixed rates
[15:50] <ubitux> saste: it's a SMPTE timecode, some broadcast stuff
[15:51] <ubitux> it's just a representation of frame number as a time bastardization for humans
[15:51] <ubitux> you're not supposed to use it unless you know what you are doing
[15:55] <saste> ubitux, uhm ok
[15:55] <saste> i need to show PTS representing a time, which is different from the PTS time
[15:56] <saste> so I need to add an offset
[15:56] <saste> i could do setpts,drawtext,setpts
[15:56] <saste> but maybe I could add an offset parameter to the %{pts} function
[15:56] <ubitux> i thought we had such thing
[15:57] <saste> with timecodes it is possible to set the initial value
[15:57] <ubitux> mmh maybe that was just %{pts} indeed
[15:57] <ubitux> would be nice to have a timed representation indeed
[15:58] <ubitux> saste: it seems possible
[15:58] <saste> what do you mean by "timed representation"?
[15:58] <ubitux> there is a "hms" mode for func_pts
[15:59] <saste> The second argument is an offset added to the timestamp. 
[15:59] <saste> wtf i missed that...
[15:59] <ubitux> %{pts:hms}, right
[16:00] <ubitux> we should add an example in the documentation
[16:02] <ubitux> we don't have a boxpadding option btw?
[16:08] <cone-195> ffmpeg.git 03Clément BSsch 07master:f4dec0dba0fa: doc/filters: fix Shwo/Show typo
[19:04] <wm4> ubitux: hm the more I think about this, the more I'm convinced that subtitle converters absolutely do not belong in libavcodec
[19:05] <kierank> smarter: http://www.slideshare.net/fullscreen/touradj_ebrahimi/spie2014-hev-cvsvp9/
[19:05] <wm4> the converters seem to be the only decoders which must access AVPacket pts/duration, while normally no decoder needs to interpret these fields (and also don't need a time_base)
[19:19] <ubitux> wm4: the reason they need it is because the internal ass representation need that
[19:20] <ubitux> what is wrong is the internal ass representation
[19:20] <ubitux> when we drop that, the decoders will no longer require it
[19:26] <ubitux> i guess i'm going to go back on subtitles again soon
[19:34] <Compn> ubitux : we could just do it both ways
[19:34] <Compn> internal ass and external filters to convert it or whatever
[19:36] <ubitux> Compn: internal ass is wrong, we need to change its form because the timestamps don't belong here
[19:37] <ubitux> i don't get what you mean about "external filters"
[20:14] <cone-637> ffmpeg.git 03Clément BSsch 07master:554d8190624f: avutil/pixelutils: faster pixelutils_sad_16x16
[20:16] <ubitux> anyone with ppc hw here?
[20:18] <ubitux> with altivec in particular
[20:18] Action: cbsrobot- stares at his basement
[20:19] <wm4> ubitux: unfortunately, the "other" ass subtitle format has this problem that it requires a sequence number
[20:20] <ubitux> yes
[20:20] <ubitux> that's why we will probably come up with a different representation than ass
[20:20] <ubitux> without these constraints
[20:22] <wm4> the fabled universal tag format?
[20:22] <ubitux> for example, or simply a bastardization of ass
[20:23] <wm4> the latter sounds potentially better
[20:23] <ubitux> "ffass"
[20:23] <ubitux> maybe "ffatass" sounds better
[20:23] <wm4> "assff"
[20:24] <ubitux> "aff" ?
[21:30] <BtbN> Is there some high motion lossless video i can use for encoder testing somewhere?
[21:41] <durandal_1707> anybody going to port nnedi3?
[21:42] <ubitux> BtbN: maybe some scenes of tears of seal or sintel?
[21:42] <ubitux> durandal_1707: not me
[21:43] <ubitux> durandal_1707: https://github.com/dubhater/vapoursynth-nnedi3 right?
[21:43] <durandal_1707> yes
[21:56] <kurosu> "binary1_0.9.4.bin"
[21:57] <Compnn> michaelni : another great mail about the differences of review and commits to ffmpeg and merges from libav. thank you for not flaming with atilla :)
[22:00] <ubitux> kurosu: 13M of weird float tables? :D
[22:01] <ubitux> durandal_1707: hf porting this..
[22:01] <Compnn> BtbN : foreman ?
[22:01] <durandal_1707> ubitux: hf?
[22:01] <ubitux> have fun
[22:01] <BtbN> Compnn, hm?
[22:02] <durandal_1707> ubitux: i dont get what function actually do work
[22:03] <durandal_1707> shit what this .bin thing do
[22:04] <ubitux> it's 13M of floats
[22:04] <ubitux> :D
[22:04] <durandal_1707> 13M ??? that is insane
[22:06] <cone-637> ffmpeg.git 03Luca Barbato 07master:f9f34cb9983e: ogg: Use separate classes for the aliases
[22:06] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:9bff8cfc913e: Merge commit 'f9f34cb9983ec6f4ef119c34b726d3b39c143110'
[22:22] <cone-637> ffmpeg.git 03Reinhard Tartler 07master:5caf039ba2b4: Prepare for 11_beta2 Release
[22:22] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:e3601ceeb875: Merge commit '5caf039ba2b4be067568a30146f29008d8db28d0'
[22:23] <Daemon404> oh he left
[22:24] <Daemon404> someone should have told him it was a trained neural network
[22:33] <Compnn> BtbN : http://samples.ffmpeg.org/yuv/foreman.qcif.bz2 lossless raw motion
[22:33] <BtbN> ah, nice. Thanks
[22:33] <Compnn> theres other clips in that dir
[22:34] <Compnn> i dunno which is best...
[22:59] <cone-637> ffmpeg.git 03Reinhard Tartler 07master:749b1f1359b5: configure: add --enable-rpath
[22:59] <cone-637> ffmpeg.git 03Michael Niedermayer 07master:2e3c1699aea7: Merge commit '749b1f1359b5af0a08221923b016551b18ab6171'
[23:03] <BBB> BtbN: typically people use https://media.xiph.org/video/derf/
[23:03] <BBB> BtbN: theres also some more academic collection used for hevc/h264, but I dont know if theres a single location for it
[23:04] <BtbN> Yeah, i already got what i needed
[23:04] <BBB> ok cool
[23:06] <BtbN> Couldn't get ShadowPlay to just encode a random video anyway. So i had to play a random FPS game and compare that.
[23:26] <ubitux> kierank: why are you so pushy about having michael moving to VDD :/
[23:26] <ubitux> it won't make a single (positive) difference
[23:29] <kierank> i am not the only one
[23:29] <kierank> see j-b's email
[23:30] <kierank> ubitux: it can't make the situation worse
[23:30] <ubitux> it can
[23:30] <ubitux> definitely
[23:30] <kierank> how can it get worse than now
[23:31] <ubitux> people can be manipulated easily in such situation
[23:32] <ubitux> also, as i already explained several times, what will be said and how it will be remembered are two different things
[23:32] <ubitux> and there will be no trace except random testimonies
[23:32] <ubitux> testimony*
[23:33] <ubitux> Stefano didn't approve this harassment either btw
[23:33] <kierank> neither did carl
[23:33] <kierank> but the part in these emails saying I'd love to have a discussion with you etc etc
[23:33] <kierank> but then not doing anything is a joke
[23:34] <ubitux> discussion can be over email and irc
[23:34] <kierank> you think there hasn't been enough of that with libav
[23:35] <ubitux> then how changing the medium will change anything?
[23:35] <kierank> because it is conducive to compromise
[23:36] <ubitux> this is insane
[23:36] <ubitux> it's like saying "let's make a compromise; we agree on the technical part, and on your side please hit your head on a wall so we are even"
[23:37] <kierank> so turning up to have an adult conversation is "hitting your head on the wall
[23:38] <ubitux> no, but forcing someone physically move just for the sake of having him move around the globe is definitely not behaving as an adult
[23:38] <ubitux> real life talks are broken to talk about such issues
[23:38] <ubitux> and i explained why
[23:38] <kierank> let's be honest even if we held the meeting in vienna at his house he wouldn't do anything
[23:39] <kierank> sorry to talk about someone here in the 3rd person
[23:40] <ubitux> and so what?
[23:40] <kierank> see all of j-b's email as response
[23:40] <ubitux> see mine
[23:41] <kierank> the world is bigger than ffmpeg and libav's petty fight
[23:41] <kierank> everyone has to deal with the mess as a result because some people are  to petty to talk
[23:41] <kierank> i hope he forks to be honest
[23:41] <ubitux> the world can learn to send emails
[23:42] <kierank> yeah because the one thing we want more of is hearing the same stories for the 20th time 
[23:42] <kierank> with each side's sprinkle of BS on top
[23:42] <ubitux> yes, and ofc in real life it will make a huge difference
[23:43] <kierank> libav people will speak to michael irl
[23:43] <kierank> but not by email
[23:43] <ubitux> if you expect michael to say different things in real life, then maybe that's because you expect to influence him in some way
[23:43] <kierank> carl on the other hand
[23:43] <kierank> by definition compromise involves changing  your position
[23:43] <kierank> so yes
[23:43] <kierank> I hope positions on both sides will move
[23:44] <ubitux> and what so changes do you suggest?
[23:44] <kierank> I can't read minds
[23:45] <ubitux> i'm sure libav can make a list
[23:45] <kierank> and you can make a list for them
[23:45] <ubitux> yes
[23:45] <ubitux> we can make our own, but we don't have much requests
[23:46] <kierank> what about the users
[23:46] <kierank> again going back to this petty problem
[23:46] <kierank> the world is bigger than ffmpeg/libav
[23:46] <ubitux> we communicate with our users through mailings lists and irc; also, we have ffmpeg representative at these meetings
[23:47] <ubitux> we don't need to have michael their if he is not willing to go
[23:47] <ubitux> there*
[23:47] <kierank> your users (cf debian-devel) want you to stop fighting
[23:47] <ubitux> we are not fighting
[23:47] <kierank> michael's (perceived or past or current or whatever) behaviour is a major issue in the ffmpeg/libav split
[23:47] <kierank> therefore michael is involved
[23:48] <ubitux> no such complain was raised in the thread except from libav ppl digging 3yrs old threads
[23:48] <kierank> huh
[23:48] <kierank> look at all the people saying how they have to rewrite their code because of forks
[23:48] <ubitux> how is that directed at michael?
[23:49] <ubitux> it's a fork issue, not "a michael issue"
[23:49] <ubitux> we do our best on the technical part to fix that
[23:49] <kierank> if there was no fork the problem would not exist and michael is a part of the forking reasons
[23:49] <ubitux> he was 3yrs ago
[23:50] <kierank> sure but libav people don't see anything else apart from that
[23:50] <kierank> except for misleading posts on debian-devel
[23:50] <kierank> which makes the situation worse
[23:50] <kierank> and no concept of compromise
[23:50] <ubitux> the compromise is to not replace libav
[23:51] <kierank> "if you come to ffmpeg and delete avresample we can all work happily " (lol)
[23:52] <ubitux> kierank: we can listen to suggestions to change our workflow
[23:52] <ubitux> actually, wm4 raised the topic a few days ago
[23:52] <ubitux> about the technical changes
[23:52] <ubitux> it was frozen on both side
[23:53] <ubitux> (we don't agree on the review process)
[23:53] <kierank> sure you don't agree on the review rules but you could come to some agreement where there is a mailing list where both sets of patches go to
[23:53] <kierank> on a neutral domain
[23:53] <kierank> so that ffmpeg people can comment on libav changes
[23:54] <kierank> like me you probably need to filter out the term k&r
[23:54] <kierank> but anyhow
[23:54] <ubitux> we could setup an automatic forward to such list
[23:54] <kierank> yes but has there been any proposals between both sides?
[23:54] <kierank> no
[23:54] <ubitux> or actually, you would just have to register ffmpeg-devel and libav-devel to a common ml
[23:54] <kierank> because both sides have never communicate
[23:55] <ubitux> well& what do you want to communicate about?
[23:55] <ubitux> i mean, we do communicate at times
[23:55] <kierank> setting up such a list for example
[23:55] <kierank>  and to be honest on the neutral mailing list nobody can say on either side that someone is a spy or other nonsense
[23:56] <ubitux> but everytime i point out something from ffmpeg on libav side i get either ignored or some ppl say to me that i'm permanently trying to show ffmpeg is better
[23:56] <iive> there was "bringing ffmpeg and libav closer" thread a few months back.
[23:56] <kierank> ubitux: yes so on the neutral mailing list it is better
[23:56] <ubitux> sure ok
[23:56] <ubitux> well then
[23:56] <ubitux> let's just setup such ml
[23:56] <iive> then I demanded that michaelni ban is removed from their maillist, as a sign of good will
[23:57] <ubitux> and register {ffmpeg,libav}-devel to it
[23:57] <kierank> ubitux: so you contact all libav and ffmpeg people
[23:57] <ubitux> i see no problem with that
[23:57] <kierank> to notify them and discuss the issue
[23:57] <kierank> ...
[23:57] <kierank> this is what discussing things in person is good for
[23:57] <ubitux> how would that help?
[23:57] <ubitux> i can send a mail to both ml if you want (but :effort:)
[23:57] <kierank> you're basically proving my point here
[23:58] <ubitux> i wouldn't have the courage to even participate in such talk in real life
[23:58] <ubitux> i'd avoid the thing
[23:58] <Case> why do some people care about libav at all?
[23:58] <kierank> because by some definition it is ffmpeg upstream
[23:58] <kierank> and controls much of the api
[23:58] <ubitux> because it's packaged on debian
[23:58] <ubitux> and so users need to support both
[23:59] <Case> debian needs to nuke it asap
[23:59] <iive> sure
[23:59] <ubitux> it doesn't need to nuke libav
[23:59] <iive> do you know a debian ftp master?
[23:59] <ubitux> really that's not what we are trying to achieve here
[23:59] <kierank> 10:58 PM <"ubitux> i wouldn't have the courage to even participate in such talk in real life --> on the mailing list you even said you talked with libav poeple
[23:59] <Case> no because michael is too kind
[00:00] --- Sun Aug 24 2014