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

[burek]

[02:16] <cone-51> ffmpeg.git 03Supraja Meedinti 07master:6ad749b53354: libavutil: Added twofish symmetric block cipher
[03:18] <cone-51> ffmpeg.git 03Carl Eugen Hoyos 07master:3ea97767e49c: Add an ARES atom to extradata when encoding avui.
[03:18] <cone-51> ffmpeg.git 03Michael Niedermayer 07master:4155f2d7cc6a: Merge remote-tracking branch 'cehoyos/master'
[04:59] <cone-51> ffmpeg.git 03Arwa Arif 07master:a21acd554a25: Fix frame-alignment in PP7
[07:13] <fffan> why av_frame_get_best_effort_timestamp does not work for wmv's audio stream?
[07:16] <fffan> 4 j-b
[10:23] <durandal_1707> so is variable frame rate possible with lavfi?
[10:24] <nevcairiel> that entirely depends on the filters
[10:24] <nevcairiel> it just passes timestamps with the AVFrames
[10:24] <BtbN> stuff like scaling schouldn't care
[10:28] Action: kierank doesn't set timestamps with lavfi and it works
[10:29] <nevcairiel> many filters in lavfi wont care about timestamps or framerate, but your app might want to associate timestamps with frames, unless its strict cfr anyway and you just invent new ones later
[10:30] <durandal_1707> but timestamps depends on timebase and timebase may change with vfr
[10:31] <kierank> Time base isn't meant to change with vfr
[10:31] <nevcairiel> timebase shouldnt change, if it does the format is stupid :p
[10:31] <kierank> The frame interval changes, yes
[11:02] <wm4> some filters actually want a framerate
[11:03] <durandal_1707> but to what set pts when filter works in vfr 
[11:04] <wm4> to the timestamp
[11:04] <kierank> durandal_1707: you have a bigger problem I realised
[11:04] <kierank> because in mpeg2/h264 the PTS of a soft pulldown file is the PTS *after* pulldown
[11:05] <kierank> the filter is broken by design i believe
[11:05] <nevcairiel> yeah soft-telecined h264 streams have crazy pts, 24 fps that fit on timestamps of 30 fps content
[11:06] <kierank> oh wait, it's libmpcodecs it's already broken by design
[11:06] <wm4> kierank: nice
[11:07] <kierank> durandal_1707: just delete the mpcodecs filter
[11:07] <kierank> serious who cares if michaelni is obsessed with them even though they don't work
[11:07] <kierank> seriously*
[11:08] <durandal_1707> i can just set it to NOPTS value
[11:09] <durandal_1707> the filter was designed to be used with mencoder
[11:13] <cone-588> ffmpeg.git 03Stefano Sabatini 07master:d11fcf735f4a: doc/filters: apply some updates to the Filtergraph syntax section
[11:13] <cone-588> ffmpeg.git 03Stefano Sabatini 07master:af7b89e08be8: lavfi: document assumptions about the input and output labels of a filter graph description
[11:13] <cone-588> ffmpeg.git 03Stefano Sabatini 07master:d43c1ec684ce: examples/filtering: extend comments about setting the filter graph endpoints
[11:17] <durandal_1707> michaelni: mp=softpulldown sets all frames pts value to NO_PTS
[11:19] <durandal_1707> michaelni: what you prefer: removal of mp=softpulldown or bug to bug compatible port
[11:22] <wm4> <durandal_1707> the filter was designed to be used with mencoder <- *chuckle*
[11:22] <wm4> mencoder didn't use timestamps
[11:23] <durandal_1707> so how it worked at all?
[11:38] <wm4> durandal_1707: who knows whether it ever did?
[11:39] <wm4> the filter was added in 2003
[11:40] <kierank> just delete the filter
[11:42] <wm4> who is even against it
[11:46] <kierank> nobody apart from the leader
[12:48] <michaelni> durandal_1707, i prefer having softpuldown in libavfilter, we can fix bugs in it later 
[12:50] <durandal_1707> michaelni: so it's ok to push it bug for bug compatible version with unchanged pts
[12:50] <kierank> wow that's a joke
[12:51] <wm4> michaelni: why?
[12:51] <wm4> also "fix bugs later" => project slowly turns into garbage
[12:52] <michaelni> kierank, ?
[12:52] <kierank> the filter is totally broken, doesn't do anything yet you want it in libavfilter
[12:52] <kierank> it's inherently broken
[12:52] <kierank> the only way to make the filter work is to apply the pulldown pattern separately
[12:53] <kierank> I can craft files that have totally insane repeat patterns otherwise and the filter will try to "pulldown" them
[12:53] <kierank> http://git.videolan.org/?p=x264.git;a=blob;f=x264.c;h=2dd819a30414780fd4c931afdfb9d34a6a1bac07;hb=HEAD#l220
[12:54] <kierank> note how x264 only supports sane pulldown
[12:54] <nevcairiel> wtf is euro
[12:54] <kierank> it's for music videos
[12:54] <kierank> where they don't want 4% speedup
[12:55] <nevcairiel> 24->50 in pulldown?
[12:55] <kierank> 24->25
[12:55] <nevcairiel> those pattern look crazy
[12:55] <kierank> it's just repeating a field every 12 frames
[13:02] <michaelni> kierank, if you want to write a filter as you describe, please do so. How is this related to the softpulldown filter?
[13:03] <wm4> michaelni: I still want to know why a broken filter should be added, even though everyone points out how broken it is, and no argument was given so far how it is not broken or useful
[13:04] <wm4> michaelni: or do we have to tolerate this bullshit because you're the leader and you say so?
[13:04] <wm4> (watch by diplomatic skills)
[13:05] <michaelni> wm4, no, we can drop the filter if its useless but the filter does basically what the mpeg2 spec requires IIUC
[13:07] <durandal_1707> filter does not set pts and I dunno how pts can be set
[13:07] <michaelni> durandal_1707, i can fix pts or rather try
[13:08] <durandal_1707> also i'm not sure that default behavior is correct when no repeat_pict is set
[13:08] <kierank> 12:05 PM <michaelni> wm4, no, we can drop the filter if its useless but the filter does basically what the mpeg2 spec requires IIUC --> the *creator* of the file sets up the correct PTSs in the container
[13:08] <kierank> it's not the job of some program to try and guess what the PTSs are 
[13:09] <michaelni> kierank, why do you troll ?
[13:09] <kierank> it's not a troll
[13:09] <kierank> it's a fact
[13:10] <kierank> I implemented it in x264 - I know how it works
[13:11] <michaelni> its a troll because i want to fix the pts and you say the pts need tp be fixed to match the input isnt that what i wanted to do ?
[13:12] <kierank> you can't fix the pts because you don't know how the timebase is meant to change because you can't predict the pattern
[13:12] <kierank> unless you assume the timebase is post-pulldown which means the PTSs are right to begin with
[13:14] <michaelni> kierank, what you call a timebase is if i take your vfr comments not a timebase but the framerate and iam afraid the more i argue the more you argue based on different terninology
[13:14] <kierank> pulldown is inherently cfr yes
[13:22] <durandal_1707> i tried softpulldown with x264 and it returns always repeat_pict = 0
[13:23] <wm4> I know some people who encode DVDs and take deinterlacing issues very seriously, and they'd piss their pants if you told them about the softpulldown filter
[13:24] <michaelni> wm4, thats understandable the filter pretty much adds "interlacing"
[13:26] <michaelni> iam also not sure "softpulldown" is the best name for the filter
[13:27] <wm4> oh, wrong direction then? even more useless...
[13:31] <michaelni> not sure what you mean by direction but possibly yes
[13:46] <durandal_1707> so is it ok to drop mp=softpulldown?
[13:53] <michaelni> durandal_1707, if noone objects i wont object either, i would slightly prefer to have the filter in libavfilter though but if people feel strongly that its better to completely drop so be it
[13:58] <compn> michaelni : apparently people "feel strongly" about getting rid of mpfilters , might as well let them drop it
[13:58] <compn> if someone comes along later they can pull a git revision of before the removal and fix softpulldown 
[13:59] <compn> wm4 / durandal_1707 (and kierank who left) : althought we just had a user in #mplayer who was using pullup in mencoder because it wasnt available in ffmpeg ? 
[13:59] <compn> isnt pullup available in ffmpeg? if its renamed , might want to say that in the docs
[14:00] <durandal_1707> it is available and not renamed, same name - pullup
[14:01] <wm4> if he uses mencoder, whack him
[14:11] <Daemon404> wm4, i hope you mean 'whack' in the mob sense
[14:12] <wm4> is there another sense?
[14:14] <Daemon404> well. the literal sense.
[14:14] <Daemon404> whack someone with a club
[14:14] <wm4> anything is fine against mencoder users
[14:15] <Daemon404> i am fairly certain youtube still uses mencoder in a VM
[14:15] <Daemon404> for a small subset of codecs
[14:15] <Daemon404> liek canopus hq(x)
[14:16] <wm4> but that's google
[14:16] <BtbN> Youtube at least messes up flv with 48kHz aac.
[14:21] <cone-588> ffmpeg.git 03Martin Storsjö 07master:6996fd204a7f: libopenh264: Log debug messages to a non-null context
[14:21] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:d39fa69dfc64: Merge commit '6996fd204a7f28b46a8c3c97bcf223998218c743'
[14:32] <cone-588> ffmpeg.git 03Zhang Rui 07master:038f3a173f59: avformat/concatdec: avoid NULL dereference when failed to open file.
[15:23] <compn> so uh, full html5 on youtube eh
[15:23] <compn> no more 'dobe flash
[15:24] <Daemon404> its default, not gone.
[15:24] <BtbN> html5 was default for non-broken browsers for a while.
[15:24] <compn> iirc dark_shikari was talking about optimizing our h264 decoder , dont remember if coreavc was still faster 
[15:24] <BtbN> So basicaly everything except IE and Firefox(Which is basicaly only Chrome)
[15:25] <wm4> I wonder if this is the death of flash
[15:25] <BtbN> no.
[15:25] <compn> we can only hope.
[15:25] <compn> but no. :(
[15:25] <wm4> youtube is one of the most popular websites (or was), so "everyone" had to have flash installed
[15:25] <BtbN> live streaming still doesn't work without flash.
[15:25] <wm4> but now without this "killer argument" for flash it could fall into disuse
[15:26] <ubitux> do we have color similarity code somewhere i could reuse?
[15:27] <compn> color difference stuff? hmm
[15:27] <compn> yeah , whats it called where you set the blacklevel 
[15:27] <compn> in encoders
[15:27] <compn> or maybe cropdetect
[15:28] <ubitux> i mean sum of squared (or absolute) diff of each r g and b component is kind of shit
[15:28] <ubitux> so i was wondering if we had somethng hsv based or similar
[16:19] <ubitux> i wonder if it will be overkill to rely on xyz+cielab and an advanced cie diff based
[17:14] <durandal11707> michaelni: where i can find nut4cc.txt?
[17:15] <michaelni> svn://svn.mplayerhq.hu/nut
[17:16] <michaelni> theres also a git mirror of it somewhere
[17:22] <durandal11707> michaelni: svn one seems obsolete, i found commits that are not in svn tree
[17:28] <durandal11707> hmm doing git pull fetched rest of changes
[17:53] <durandal11707> michaelni: why is GIF[0] in nut4cc but not in libavformat/nut.c
[17:53] <durandal11707> ?
[18:00] <michaelni> durandal11707, no idea, maybe it was forgotten
[18:29] <ubitux> http://pastie.org/pastes/9871846/text ’ https://en.wikipedia.org/wiki/Ordered_dithering
[18:30] <ubitux> can i have some litterature on this?
[18:30] <ubitux> i don't understand why this particular matrix, and the logic behind it
[18:30] <ubitux> also, i'm surprised how the bayer in sws doesn't seem to use this matrix but still have the expected output
[18:40] <michaelni> ubitux, the standard ordered dither matrix is trivial to generate, just start with a empty square and fill in one value at a time, always pick a spot fartherst away from all other already filled in spots
[18:41] <michaelni> fartherst away in the sense if you would also consider wrap around
[18:43] <ubitux> is there a paper on this?
[18:44] <ubitux> also, i'm surprised that the ordered dithering is all about adding unsigned values; isn't this causing a luma bump? why isn't it made signed?
[18:45] <michaelni> theres probably a paper on it and also probably many other ways to generate the matrix, if its generated by filling in points one could add a slight random component to it though
[18:46] <michaelni> about signed, if one replaces (v + 32) >> 6 by (v + dither) >>6 then dither would have a 0..63 range
[18:46] <michaelni> doesnt mean there are no luma offset bugs of course, if there are any please report
[18:48] <ubitux> i'm not talking about ffmpeg in particular here (i'm actually quite surprised ffmpeg doesn't even use that bayer/ordered matrix (i don't get from where ff_dither_8x8_{32,73,220} comes from nor how they are supposed to be used)
[18:50] <ubitux> OTOH the pp filters seems to have the exact bayer filter
[18:50] <ubitux> (which they seem to scale somehow differently sometimes)
[18:51] <wm4> gradfun has one too
[18:51] <ubitux> here i have a lot better result if i just v + (dither>>3) (so... 0..63 scale to 0..7 scale) for a v in 0..255 range
[18:51] <ubitux> but i'm probably just doing it wrong
[18:51] <ubitux> wm4: not bayer
[18:52] <ubitux> mmh, actually maybe it is with a x2
[18:53] <ubitux> yeah right, bayer * 2 in gradfun
[20:36] <cone-588> ffmpeg.git 03Luca Barbato 07master:1279221cc4d6: lavu: Check av_dict_set allocations
[20:36] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:bcadf5d940e7: Merge commit '1279221cc4d63bc4449df86ae7a98e633f8be425'
[20:44] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:41e03e284ee7: DNxHD: More verbose error messages
[20:44] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:e5b7e2224f62: Merge commit '41e03e284ee7b0d4caa3a5d28681ad46e3105d65'
[21:00] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:598f7d046cbf: DNxHD: Simplify pixel format detection
[21:00] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:64e7cf12532e: Merge commit '598f7d046cbf306706623210c5baafa3b7cd1df3'
[21:34] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:1a07df31128d: DNxHD: Add support for id 1258 (DNx100 960x720 at 8)
[21:34] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:56252a5e0979: Merge commit '1a07df31128da3a0020b66502399989b91770d44'
[21:35] <michaelni> where can i find a DNx100 sample ?
[21:42] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:302ca6b20ed0: mpegvideo_enc: initialize the encoding context
[21:42] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:e18e5ae62ce2: Merge commit '302ca6b20ed01ac584f5b15d5bca3d3a92b7a77a'
[22:01] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:08fa34bf7594: yuv4mpegdec: initialize field_order in yuv4_read_header()
[22:01] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:c2ad22ff9934: Merge commit '08fa34bf75942f66796d770ff42a3721b2e3d2d4'
[22:07] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:c01ccccbb13f: ituh263dec: use macro instead of #if
[22:07] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:c16896f52551: Merge commit 'c01ccccbb13f464e74bb8498a8c573a66c430ca0'
[22:41] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:70d246d5cc3d: flacenc: initialize sums matrix
[22:41] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:89c35b113060: Merge commit '70d246d5cc3d214da11f711d997d8cbd8c3a23d1'
[23:03] <cone-588> ffmpeg.git 03Vittorio Giovara 07master:22b985d59c00: hqdn3d: check memory allocations and propagate errors
[23:03] <cone-588> ffmpeg.git 03Michael Niedermayer 07master:ccccfb59b14f: Merge commit '22b985d59c007c4422aefe3ef3fca0aa0daafa9f'
[23:13] <cone-588> ffmpeg.git 03Lou Logan 07master:961f2e3aace0: doc/indevs: add some XCB info to x11grab
[00:00] --- Fri Jan 30 2015