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

[burek]

[00:27] <cone-823> ffmpeg.git 03Michael Niedermayer 07master:0bcb040a2ec9: avcodec/mpegvideo_enc: Consider chroma_intra_matrix in dct_quantize_trellis_c()
[00:27] <cone-823> ffmpeg.git 03Michael Niedermayer 07master:98437465704d: avcodec/mpegvideo_enc: correctly initialize chroma_intra_matrix for MPEG1/2
[02:08] <cone-823> ffmpeg.git 03Robert Xiao 07master:60bb893386d4: LICENSE.md: Formatting updates
[09:58] <ubitux> http://zulko.github.io/blog/2015/02/01/extracting-perfectly-looping-gifs-from-videos-with-python-and-moviepy/ nice
[10:25] <j-b> 'lo
[11:29] <michaelni> 'hi
[11:59] <cone-118> ffmpeg.git 03Clément BSsch 07master:e1ca695d2207: README: fix analisys/analysis typo
[11:59] <cone-118> ffmpeg.git 03Clément BSsch 07master:a5c9befbf433: README: add ffserver
[12:23] <wm4> ubitux, Plorkyeran_: fixed the ASS tag stripping (probably)
[14:12] <ubitux> wm4: cool :)
[14:17] <cone-118> ffmpeg.git 03wm4 07master:cac2295b2151: matroska: redo seekhead handling
[14:59] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/1.2:2515907a45a9: Update for FFmpeg 1.2.12
[16:06] <cone-118> ffmpeg.git 03wm4 07fatal: ambiguous argument 'refs/tags/n1.2.12': unknown revision or path not in the working tree.
[16:06] <cone-118> Use '--' to separate paths from revisions
[16:06] <cone-118> refs/tags/n1.2.12:HEAD: matroska: redo seekhead handling
[16:28] <ubitux> btw, i'll apply the color quantization patchset tomorrow
[16:28] <ubitux> unless someone objects
[16:28] <ubitux> i just implemented the selection of the box to split according to variance, i got slightly better results 
[16:45] <ubitux> it's fun how getting a better palette has a nice impact on the overall size as well
[16:47] <ubitux> i definitely get better results with the variance actually, cool.
[16:52] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:cab630253496: avcodec/arm/videodsp_armv5te: Fix linking failure with "g++ -shared -D__STDC_CONSTANT_MACROS -o test.so ... libavcodec.a"
[17:02] Action: ubitux discovers pressing 'h' while ffmpeg is transcoding
[17:09] <cone-118> ffmpeg.git 03wm4 07master:7862325f8084: avformat/matroskadec: fix IGNIDX handling
[17:21] <t4nk378> hi
[17:21] <t4nk378> anyone can help me?
[17:22] <av500> depends
[17:22] <t4nk378> i have a problem with ffmpeg and encoder libx264
[17:22] <t4nk378> http://pastebin.com/amMu1Krx
[17:22] <cone-118> ffmpeg.git 03James Almer 07master:14b44c16142f: x86/hevc_sao: make sao_edge_filter_{10,12} work on x86_32
[17:22] <cone-118> ffmpeg.git 03James Almer 07master:1679d68dbfae: x86/hevc_mc: optimize AVX2 mc functions
[17:23] <t4nk378> do you know why? and how to solve?
[17:23] <t4nk378> i work for an answer for 1 day...
[17:23] <t4nk378> but no
[17:23] <nevcairiel> your problem is with the input file you're trying to give it, its obviously not in the format that you are telling ffmpeg it is
[17:28] <t4nk378> here i get same error
[17:28] <t4nk378> http://pastebin.com/3SKkNVjP
[17:28] <t4nk378> the format is from vncrec
[17:29] <t4nk378> http://panthema.net/2014/vncrec-rgb/
[17:29] <t4nk378> in the example they show works
[17:30] <t4nk378> then nevcairiel what should I do?
[17:39] <t4nk378> which format should be?
[17:53] <Rathann> t4nk378: just look what ffmpeg is telling you
[17:54] <Rathann> you have to specify correct parameters for input file
[17:56] <Rathann> why aren't you using `vncrec -ffinfo -movie file.vnc` to help with that?
[17:56] Action: Rathann grumbles something about people not reading the docs
[18:05] <aetasx> yeah but you guys hide them on the front page of the website
[18:09] <t4nk378> i do that
[18:09] <t4nk378> but it is the same
[18:12] <cone-118> ffmpeg.git 03wm4 07release/2.5:8a6770a21419: qpeg: avoid pointless invalid memcpy()
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:4f8814964ccb: avcodec/hevc: Fix handling of skipped_bytes() reallocation failures
[18:12] <cone-118> ffmpeg.git 03Andreas Cadhalpun 07release/2.5:9e9cde6afab0: configure: enable vsx together with altivec for ppc64el
[18:12] <cone-118> ffmpeg.git 03Vittorio Giovara 07release/2.5:8acbba0ec3b2: vp8: improve memory allocation checks
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:e3b6144e0c51: avdevice: Use av_format_get_control_message_cb()
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:65074a5daebc: avfilter/vf_framepack: Check and update frame_rate
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:edec2a4da38f: avcodec/flac_parser: fix handling EOF if no headers are found
[18:12] <cone-118> ffmpeg.git 03wm4 07release/2.5:7caee172049a: avformat/utils: check for malloc failure
[18:12] <cone-118> ffmpeg.git 03Vittorio Giovara 07release/2.5:28fba553066a: opt: check memory allocation
[18:12] <aetasx> the input is with RGB24.  800 x 600 x 24 = 1440000 which is exactly what its complaining about size its right, thats not a valid frame size
[18:12] <cone-118> ffmpeg.git 03Vittorio Giovara 07release/2.5:7f8d0cf93a98: swscale: check memory allocations
[18:12] <cone-118> ffmpeg.git 03Vittorio Giovara 07release/2.5:4d74bb24e39f: aacenc: correctly check returned value
[18:12] <cone-118> ffmpeg.git 03Martin Storsjö 07release/2.5:5fbf63ea394e: rtpdec_h263_rfc2190: Clear the stored bits if discarding buffered data
[18:12] <cone-118> ffmpeg.git 03Vittorio Giovara 07release/2.5:0bdc64e8b9c1: hevc: always clip luma_log2_weight_denom
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:a45402d4c0af: avformat/mpeg: do not count PES packets inside PES packets during probing
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:a443b48ccfca: avformat/rmdec: Check for overflow in ff_rm_read_mdpr_codecdata()
[18:12] <cone-118> ffmpeg.git 03Andreas Cadhalpun 07release/2.5:a45b8af839fd: libavcodec/ppc/mpegvideoencdsp.c: fix stack smashing in pix_norm1_altivec() and pix_sum_altivec()
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:b62b3e1a25aa: swscale/input: Fix alpha of YA16 input
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:f07e2ff69793: swscale/input: fix rgba64 alpha non native
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:6ac8ac0109de: doc/APIchanges: Fill in some more missing hash values
[18:12] <aetasx> jesus
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:8026606497ea: doc/APIchanges: Add av_find_best_pix_fmt_of_2() and av_get_pix_fmt_loss()
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:164083434e78: doc/APIchanges: fill in and correct some values
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:25fc0faccb01: doc/APIchanges: fill in more missing hash values and dates
[18:12] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:675fb3a8af6b: avformat/utils: Fix number suffixes in tb_unreliable()
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:1e366c15ed59: swresample/dither: Cleanup number suffixes
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:bac6554c74dc: avcodec/dxtory: Use LL instead of L number suffix
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:260e5c6dbe19: avformat/matroskadec: Fix number suffixes
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:a3ef410b9c46: avformat/smacker: Fix number suffix
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:d11bca8043dd: avformat/omadec: fix number suffix
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:979a54ed1833: avcodec/h264_cabac: use int instead of long for mbb_xy
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:2f5c5767d1c3: avcodec/mpegvideo_enc: Fix number suffixes in rc_buffer_size calculation
[18:13] <cone-118> ffmpeg.git 03Rong Yan 07release/2.5:b0b6d8de7ec8: avcodec/ppc/idctdsp.c: POWER LE support in idct_add_altivec()
[18:13] <cone-118> ffmpeg.git 03wm4 07release/2.5:563e542b31e2: avformat/tta: fix crash with corrupted files
[18:13] <cone-118> ffmpeg.git 03wm4 07release/2.5:193440f5662c: avformat/mpc8: fix hang with fuzzed file
[18:13] <cone-118> ffmpeg.git 03wm4 07release/2.5:352d17086fd0: avformat/mpc8: fix broken pointer math
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:657dc91b44fd: avformat/mpc8: Use uint64_t in *_get_v() to avoid undefined behavior
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:0ae93844d0e8: avcodec/mjpegdec: Check escape sequence validity
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:58096b70fa98: avcodec/mjpegdec: Check number of components for JPEG-LS
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:c65a731b6f60: avcodec/mpegvideo_motion: Fix gmc chroma dimensions
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:6252e9141ba5: swscale/utils: Limit filter shifting so as not to read from prior the array
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:0f642909d866: avformat/thp: Check av_get_packet() for failure not only for partial output
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:25da8d84a46e: avcodec/x86/lossless_audiodsp: Make scalarproduct_and_madd_int16 prototypes more similar
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:3572eaaf02f9: avcodec/x86/lossless_audiodsp: Move order&8 fallback into C code
[18:13] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:09425294c97c: Revert "avcodec/x86/lossless_audiodsp: Make scalarproduct_and_madd_int16 prototypes more similar"
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:a75787a71a4b: avcodec/h264_ps: More completely check the bit depths
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:eeab3e1b2045: avcodec/h264: Be more strict on rejecting pps_id changes
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:756d85dc144a: avcodec/h264: Be more strict on rejecting pps/sps changes
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:78c314e39e92: avutil/opt: Fix types used to access AV_OPT_TYPE_PIXEL_FMT
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:137a0003779d: avutil/opt: Fix type used to access AV_OPT_TYPE_SAMPLE_FMT
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:e8058269037b: avcodec/h264_slice: Do not change frame_num after the first slice
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:7997ec54c9d2: avcodec/h264_slice: Check picture structure before setting the related fields
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:b20409c6907c: avcodec/h264_slice: ignore SAR changes in slices after the first
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:0cbf53bdf516: avcodec/h264_slice: assert that reinit does not occur after the first slice
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:345962121d76: avcodec/mjpegdec: Skip blocks which are outside the visible area
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:0f671dfeac1f: avcodec/arm/videodsp_armv5te: Fix linking failure with "g++ -shared -D__STDC_CONSTANT_MACROS -o test.so ... libavcodec.a"
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:48ae72e50193: avformat/os_support: Use av_freep() to avoid leaving stale pointers in memory
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:bd78b9416d54: avformat/riffdec: Use av_freep() to avoid leaving stale pointers in memory
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:5262c88bb077: avformat/rtmpproto: Use av_freep() to avoid leaving stale pointers in memory
[18:14] <cone-118> ffmpeg.git 03Michael Niedermayer 07release/2.5:c7e967a7cb0c: Update for 2.5.4
[18:16] <aetasx> cant you guys space out your fixes more so this doesnt happen :p
[18:19] <aetasx> here, I've got a question.  if I grab the PTS of an I-frame of an h264 stream and then seek to it as an output option with -ss, why does x264 complain about a bad picture? (using cgop too)
[18:19] <aetasx> should add, this is why stream copying
[18:28] <ubitux> michaelni: i guess i should backport the dctdnoiz fix too
[18:29] <michaelni> dont forget updating the Changelog
[18:30] <ubitux> can we decide on a way to mark potential commit for backports?
[18:33] <michaelni> if the people backporting changes prefer that
[18:34] <michaelni> atm it is "you want something backported" -> "you backport it", i cant handle backporting all commits to all releases 
[18:35] <wm4> solution: don't maintain a shitload of releases
[18:35] <michaelni> yes
[18:49] <kierank> wm4: can't have enough releases
[18:49] <kierank> all those new features
[18:52] <ubitux> michaelni: how do you know which commit to potentially backport?
[18:52] <ubitux> you crawl the whole history?
[18:52] <ubitux> would be nice to have a tag or something
[18:52] <ubitux> or keyword or whatever
[18:55] <durandal11707> how is this awk thing working in fate coverage
[18:55] <durandal11707> i cant genenerate simple wavpack encoder coverage
[18:56] <ubitux> what awk thing?
[18:56] <durandal11707> awk: syntax error at source line 1
[18:57] <ubitux> while doing what?
[18:57] <durandal11707> writing tests/fate/wavpackenc.mak
[18:57] <ubitux> with GEN=1 ?
[18:57] <ubitux> (related to d47eeff2741a9ad9eb4398c1d844dd4f638d6ee4 ?)
[18:58] <durandal11707> nope, it should not be related with bc
[18:59] <ubitux> so you're doing something like make fate-wavpack-enc GEN=1?
[18:59] <durandal11707> yes
[19:00] <ubitux> not sure what this awk is, try with V=1 for details on what is run
[19:02] <michaelni> ubitux, do you want to help maintaining a release ? or do you know someone who wants to help maintain a release ?
[19:04] <michaelni> ubitux, also please check the gsoc page to make sure its accurate
[19:05] <llogan> why are we wasting our time on GSOC?
[19:05] <michaelni> ubitux, i mean you are listed as mentor on that page
[19:05] <michaelni> llogan, is that a troll?
[19:06] <llogan> no
[19:06] <michaelni> well, gsoc potentially could fund several students to do work on ffmpeg
[19:06] <llogan> i honestly believe they will never choose FFmpeg
[19:07] <JEEBcz> well, if you can try then you can try, but it seems like they have a perma-nope for videolan things and similar
[19:07] <kepstin-laptop> which would be a pity, seeing how much google seems to rely on the software :/
[19:08] <michaelni> llogan, trying doesnt cost much
[19:08] <llogan> it's always more work than it seems
[19:08] <michaelni> these discussions likely will exceed the work
[19:09] <llogan> you can of course apply
[19:09] <llogan> i will not be a part of anything related to GSOC though
[19:09] <JEEBcz> kepstin-laptop, according to the discussions I've overheard they seem to be paying for specific work instead
[19:10] <aetasx> what exactly did you guys do to them?
[19:10] <JEEBcz> well, it's a long story beginning with x264 not exactly doing according to the rules regarding the high-schooler GSoC-like thing
[19:11] <JEEBcz> aka they wanted everything pre-noted, but when you have students writing asm for random functions that could be optimized I don't see how that could be pre-noted
[19:11] <JEEBcz> so they then banned x264 from it and from GSoC due to "not following rules"
[19:12] <michaelni> llogan understood, ill try anyway, i dont really expect that we get accepted but i see no reason why we should try
[19:12] <michaelni> shouldNT try :)
[19:14] <aetasx> Im not sure I'd want HS kids coding parts of my app with asm
[19:18] <jamrial> JEEBcz: why would that x264 ban affect ffmpeg? because of developer overlap?
[19:18] <aetasx> wait, x264 got you both banned?
[19:19] <nevcairiel> its more like a videolan ban
[19:19] <nevcairiel> which affects like everyone :p
[19:19] <kierank> no it's because of ffmpeg libav fighting ban
[19:20] <kierank> the x264/videolan ban has a gravitational influence, yes 
[19:20] <kierank> but it's not the main body
[19:20] <JEEBcz> as for FFmpeg and Libav, around 2012 there was some herp and derp on why one of them got in and the other didn't - and it seems like GSoC just doesn't want to go anywhere close these two projects
[19:20] <JEEBcz> and later when discussed IIRC they just gave some random reason for it  in order to not have to redact an earlier decision
[19:20] <JEEBcz> so you are at this point now :P
[19:20] <JEEBcz> yes
[19:20] <JEEBcz> the ball got kind of rolling with the x264/videolan thing
[19:20] <JEEBcz> and then the ffmpeg/libav thing in 2012 sealed it
[19:21] <kierank> someone went a bit nuts at them from ffmpeg or whatever
[19:22] <durandal11707> what about hate mails?
[19:22] <JEEBcz> aetasx, it was a tightly controlled environment and there were people reviewing that code. it wasn't like in some other projects where those kids were just translating documentation or something, you actually had to have an idea and knowledge (or at least readiness to learn quite quickly)
[19:23] <aetasx> true but I would've expected something at C level, not asm
[19:23] <kierank> why
[19:24] <aetasx> lot of the programmers I've worked in the past can't even name an instruction
[19:24] <kierank> yes and that was kind of the point
[19:24] <kierank> highschoolers can write asm
[19:24] <JEEBcz> yup
[19:25] <aetasx> be nice to meet one some day ;)
[19:30] <michaelni> anyone knows the "end of life" dates for openmandriva ? or some list of fixed CVEs from which it could be inferred?
[19:30] <jamrial> michaelni: http://fate.ffmpeg.org/log.cgi?time=20150212181000&log=compile&slot=x86-opensolaris-gcc4.3-n2.5 recently ran using updated 2.5 branch
[19:31] <aetasx> thats probably the first time Ive heard that name in 6 years
[19:33] <jamrial> backporting kurosu's final fix should deal with this (46e2afa4 and 691b7f5e)
[19:35] <aetasx> what all distros are you guys on anyway?
[19:43] <michaelni> ubitux, btw if you want to add a keyword or tag to commits which you belive should be backported, by all means do it if it helps you somehow. What i meant is that if i have to add a keyword and then only i do backports it would add a burden, it would not help
[19:45] <llogan> aetasx: Downsteams on wiki has a partial? list
[19:46] <cone-118> ffmpeg.git 03James Almer 07release/2.5:2a6d16ba5f84: x86/swr: add missing alignment check to pack_6ch functions
[19:46] <cone-118> ffmpeg.git 03James Almer 07release/2.5:9bc62da98033: avutil/opencl: don't include config.h
[19:52] <aetasx> actually I was more curious about what you guys yourselves use specifically
[19:52] <aetasx> good page to keep though
[19:52] <ubitux> michaelni: yeah, but the thing is, i believe everyone prefers to do the backport for a release once, and not after every fix
[19:53] <ubitux> so if everyone marks potentially backportable fixes that might help
[19:53] <ubitux> michaelni: yeah no i don't really want to mentor GSoC
[19:54] <ubitux> (nor anything anymore)
[19:54] <aetasx> what exactly is it?  just code review and hand holding?
[19:54] <llogan> aetasx: i use arch
[19:55] <JEEBcz> hand holding mostly
[19:55] <aetasx> I love their little PKGBUILDs
[19:56] <wm4> arch is infected with the systemd devil
[19:57] <JEEBcz> at this point trying to fight against systemd as an init system is pretty futile
[19:57] <JEEBcz> unless you specifically want a lot of work
[19:57] <aetasx> I stay out of that whole matter
[19:57] <wm4> no - just use a sane OS
[19:57] <wm4> like windows
[19:57] Action: JEEBcz high-fives wm4 
[19:57] <aetasx> lol
[19:59] <aetasx> if windows either worked better vmed or I had an alt system, I would ditch it completely
[20:04] <Daemon404> actual non-dev users who care about systemd: 0
[20:07] <wm4> until said users find out that systemd ate 10% of their hard disk for log files
[20:07] <michaelni> ubitux, removed you from libavfilter & subtitles for which you where listed as (backup) mentor
[20:08] <kepstin-laptop> hey, users are just as surprised when their existing syslog ate 100% of their hard disk for log files :/
[20:08] <aetasx> theres a nice bit of debian drama added onto the end of systemd's wikipedia page
[20:10] <aetasx> wonder how much screaming it takes for a debian maintainer to lose their voice
[20:12] <cone-118> ffmpeg.git 03James Almer 07release/2.5:ee902d3d2d78: x86/lossless_audiodsp: fix compilation with --disable-yasm
[20:14] <compn> aetasx : it was bitexact asm code. you think they can mess up bit-exact ? :)
[20:14] <compn> its possible of course, but bit exact! :P
[20:15] <compn> and presumably benchmarked
[20:20] <ubitux> michaelni: thank you
[20:20] <Daemon404> [19:08] < kepstin-laptop> hey, users are just as surprised when their existing syslog ate 100% of their hard disk for log files :/ <-- this happened to me
[20:20] <kepstin-laptop> and to another guy I know; he had a system with a screwed up rtc and it messed up the logrotate saved state :/
[20:22] <aetasx> think you can hand a teenager anything and assume its at least partially destroyed by the time they're done
[20:23] <cone-118> ffmpeg.git 03Clément BSsch 07release/2.4:2c1d5f43cfaa: avfilter/dctdnoiz: fix slice_h computation
[20:23] <cone-118> ffmpeg.git 03Clément BSsch 07release/2.5:3429714f3d04: avfilter/dctdnoiz: fix slice_h computation
[20:25] <ubitux> http://lucy.pkh.me/ffgif/outputs3/gunkanjima_dither_sierra2_4a.gif starting to get relatively pretty
[20:25] <ubitux> no dither before: http://lucy.pkh.me/ffgif/outputs/gunkanjima_dither_none.gif
[20:25] <ubitux> no dither after:  http://lucy.pkh.me/ffgif/outputs3/gunkanjima_dither_none.gif
[20:25] <aetasx> what is that place?
[20:26] <ubitux> gunkanjima
[20:26] <aetasx> which is what
[20:26] <ubitux> an artificial island
[20:26] <ubitux> around a mine
[20:26] <ubitux> in japan
[20:26] <aetasx> interesting
[20:26] <ubitux> https://en.wikipedia.org/wiki/Hashima_Island
[20:27] <ubitux> anyway
[20:27] <ubitux> the recent changes in the palette makes it quite better
[20:27] <ubitux> and almost decent even without dithering
[20:28] <wm4> now we just need a gif-in-mkv mapping
[20:29] <ubitux> now i need to add a gifhd encoder
[20:29] <Daemon404> if ther eis gif in avi, we already have one
[20:29] <ubitux> to do a one pass with many palette instead
[20:30] <ubitux> not sure how i'm going to share the code with the filter though :(
[20:35] <wm4> the filter works for anything, right?
[20:51] <ubitux> wm4: yes
[20:51] <ubitux> there are 2 filters though
[20:54] <ubitux> the thing i want to experiment can not really be in a filter though
[20:54] <ubitux> and i need to put all the code of these 2 filters inside the gif encoder
[20:54] <ubitux> :(
[20:55] <ubitux> but well, maybe that color quantization code could be shared into libavutil...
[20:55] <ubitux> but people are going to hate me for that
[20:55] <ubitux> i guess moving it to lavc, and sharing with avpriv for lavfi will be more OK
[20:57] <kepstin-laptop> seems like it might sort of fit into libswscale?
[21:00] <ubitux> kepstin-laptop: nope
[21:00] <ubitux> well, not as a scaler
[21:00] <ubitux> but maybe as function helpers yeah
[21:00] <Daemon404> we need libavjunk
[21:00] <ubitux> it's called libavutil
[21:01] <Daemon404> then libavutil2
[21:01] <ubitux> Daemon404: hey it's not junk :(
[21:01] <cone-118> ffmpeg.git 03Thomas Volkert 07master:b6f577dbb2af: rtpdec_hevc: correct parsing of aggregated packets
[21:01] <ubitux> the color quant is kind of decent :(
[21:01] <Daemon404> i meant gif is junk
[21:02] <kepstin-laptop> huh, with a gif encoder, I wonder if you could fit it into the existing 2-pass infra, where pass 1 calculates the global palette and saves it, and pass 2 uses it.
[21:03] <ubitux> in libavcodec? no i can't
[21:03] <kepstin-laptop> hmm. well, the idea sounded cool anyways :/
[21:03] <ubitux> first because the pass mechanism is designed for rate control, so using it for palette was clumsy
[21:03] <ubitux> and second because i can't load the image file in the second pass
[21:03] <ubitux> because it would add a lavf dep in the lavc encoder
[21:04] <ubitux> kepstin-laptop: yeah it would have been cool, but unfortunately i can't
[21:29] <wm4> michaelni: so, you're the master of mpegts demuxer hacks; is there a way to make the demuxer (fed from a dvb stream) start up _ fast_?
[21:29] <wm4> or does one need a custom demuxer for this
[21:29] <Daemon404> define start up
[21:30] <Daemon404> arent you pretty much just stuck until you get a pat/pmt
[21:31] <wm4> libavformat spends 20 seconds or so trying to analyze the stream
[21:32] <wm4> other things like tvheadend (which has a custom demuxer) start immediately
[21:32] <wm4> I've never been able to find out why, but it seems clear that it's the fault of this lavf POS
[21:34] <BtbN> all you need is the pat/pmt, and an idr frame.
[21:34] <kepstin-laptop> my understanding is that lavf tries to probe fairly far into the mpegts stream in an attempt to detect all the streams? You could probably reduce the probesize if you know all the streams you care about have first packets near the start of the file
[21:35] <kierank> wm4: the lavf demux is total crap
[21:35] <ubitux> love profusion today again it seems
[21:35] <ubitux> :D
[21:35] <kierank> it's designed to play broken files, not play files with a normal wait time
[21:36] <JEEB> ^
[21:36] <JEEB> this
[21:36] <wm4> and I suppose this is the practical result of this
[21:41] Action: michaelni sees a self fullfiling prophecy, "that bug thats how it is dont report it, or it will be fixed"
[21:41] <michaelni> wm4, how can i reproduce this, it shouldnt take 20sec
[21:42] <nevcairiel> you can tweak the wait time with the analyze duration
[21:43] <wm4> michaelni: will ask (I don't have anything dvb myself)
[21:43] <nevcairiel> for live tv the demuxer is not well suited in any case
[21:44] <wm4> apparently so
[21:44] <Daemon404> you can hack around it if that is your main use case
[21:44] <Daemon404> i worked around it by manually reading the info and intiializing teh stream manually
[21:44] <Daemon404> instead of find_stream_info
[21:44] <Daemon404> <_<
[21:44] Action: Daemon404 runs
[21:45] <wm4> does attempting to read a packet in this state just add streams as it finds them?
[21:45] <nevcairiel> yes
[21:45] <Daemon404> if you have the stream table though, you know how many to wait for
[21:46] <wm4> interesting
[21:46] <nevcairiel> ideally, if it knows pmt/pat, it should just probe those streams and then stop
[21:46] <nevcairiel> but its not that smart
[21:46] <michaelni> find_stream_info should stop once it has all streams from the tabe
[21:46] <michaelni> table
[21:46] <nevcairiel> it doesnt afaik
[21:46] <michaelni> thats a bug
[21:47] <Daemon404> $5 says it was a fix to enable some broken .ts with a corrupt PMT
[21:49] <michaelni> if someone has/finds ts file(s) that behave unreasonable startup wise with lavf, please ping/mail me
[23:22] <cone-118> ffmpeg.git 03Michael Niedermayer 07master:33650e0e42d6: avformat/mpegtsenc: Do not create invalid files from annex b streams without SPS/PPS
[00:00] --- Fri Feb 13 2015