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

[burek]

[00:03] <ubitux> akira4: no
[00:03] <ubitux> the problem with your original code was *ptr+1
[00:03] <ubitux> you fixed that, but it should stay in the loop
[00:03] <ubitux> in the *same* loop
[00:04] <akira4> right. I'll fix it.
[00:09] <akira4> ubitux,  is this better? http://pastebin.com/znEGA2R6
[00:10] <ubitux> why do you skip the =?
[00:12] <akira4> skipping = is also required right?
[00:12] <ubitux> akira4: i don't know, that's why i'm asking
[00:12] <ubitux> it's not a trap question
[00:13] <akira4> well from the link regarding the STL file format you gave there was no = in the document
[00:13] <akira4> I thought it would be better to skip it
[00:14] <ubitux> well, you're suppose to exit if you find something that doesn't match the stl format
[00:14] <ubitux> right now, if you have a line starting with a bunch of =, it will be ignored
[00:15] <ubitux> while it's not expected at all in a stl, so it probably isn't a stl
[00:15] <akira4> exit as in return 0?
[00:15] <ubitux> yes, of course
[00:15] <ubitux> exit the function i meant, yeah
[00:16] <ubitux> akira4: http://pastie.org/9621050
[00:16] <ubitux> with your code, this will be recognized as stl
[00:16] <ubitux> while it probably isn't, these = don't belong here
[00:17] <akira4> hmm
[00:17] <ubitux> http://pastie.org/9621054 this alos
[00:17] <ubitux> also*
[00:17] <ubitux> and you don't want that :)
[00:17] <ubitux> unless of course, = means something at the beginning of a line in stl
[00:18] <ubitux> you can on the other hand look for a '=' in the line if you have a '$' at the beginning
[00:18] <ubitux> (to make sure it matches the "$foo = bar" pattern)
[00:18] <ubitux> but you can oversee that, it should be reliable enough that way
[00:18] <akira4> hmm
[00:19] <akira4> I ignore the = starting with $
[00:19] <akira4> but I exit if I have one starting with =
[00:19] <akira4> that's the bottom line right?
[00:20] <ubitux> basically if you have *ptr=='$' you could check in the following if there is a '=' on the same line, and return 0 if not
[00:20] <ubitux> but as i said, it's not really mandatory
[00:20] <ubitux> that's a bit more complex
[00:20] <ubitux> you can just ignore that
[00:21] <ubitux> the *ptr=='$' should be a good enough heuristic
[00:21] <ubitux> you're doing a proper sscanf check later for the important part
[00:21] <ubitux> anyway :)
[00:22] <akira4> true. but the = at the start of a line has to be dealt right?
[00:22] <ubitux> it will be
[00:22] <ubitux> just like any other character
[00:22] <ubitux> your code already returns 0 if you have a line that starts with, let's say, a bunch of '#'
[00:24] <akira4> that is because of the return 0 at the end
[00:24] <ubitux> yes
[00:24] <akira4> so if instead of skipping the = 
[00:24] <akira4> I dont do anything
[00:24] <akira4> then I'll get a 0 even for the =
[00:24] <ubitux> right
[00:24] <ubitux> so the question is why you would want to make a special case for the '=' in the first place :p
[00:24] <ubitux> you probably don't want to
[00:25] <akira4> yeah. My bad. thanks for pointing that out :)
[00:25] <akira4> btw
[00:25] <akira4> how do you exactly test such things?
[00:26] <ubitux> what do you mean?
[00:26] <ubitux> testing if the probing works correctly?
[00:26] <akira4> yeah
[00:27] <ubitux> you can add prints i guess
[00:27] <wm4> you can feed the prober random data with probetest
[00:27] <wm4> but that might actually not be that useful
[00:28] <ubitux> i'm not exactly sure about a proper way of debugging probe functions
[00:28] <akira4> I see.
[00:28] <ubitux> printing stuff was generally good enough when i add to write such code
[00:29] <ubitux> but yeah you can play with probetest
[00:29] <akira4> I'll do that as well. Using gdb makes my head ache :(
[00:29] <akira4> I'lll keep it in mind. thanks :)
[00:29] <ubitux> i still haven't find a way of making use of gdb in the context of C code
[00:29] <ubitux> but that is probably very personal
[00:30] <ubitux> unless doing complex stuff, valgrind and printf/av_log work just fine
[00:30] <wm4> gdb is terrible, but can be useful to debug certain things
[00:30] <ubitux> gdb is useful when dealing with asm though, even if it's a PITA to use
[00:31] <akira4> I couldn't agree more :)
[00:31] <ubitux> yeah it can be useful when doing complex stuff like making a conditional breakpoint on a random callback or whatever
[00:31] <ubitux> but really that doesn't happen that often
[00:31] <ubitux> valgrind --db-attach can be fun, but my experience with ffmpeg was always painful because of the termcaps stuff
[00:32] <wm4> termcaps?
[00:32] <wm4> ffmpeg uses it?
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:31baa6f199ed: Changelog: fix sws typo
[00:32] <cone-44> ffmpeg.git 03Bernd Kuhls 07release/2.4:0cda7baa8b22: Fix compile error on arm4/arm5 platform
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:a88a57cd2442: avcodec/asvenc: fix AAN scaling
[00:32] <cone-44> ffmpeg.git 03Pascal Massimino 07release/2.4:ff6d440d107d: avcodec/webp: fix default palette color 0xff000000 -> 0x00000000
[00:32] <cone-44> ffmpeg.git 03Benoit Fouet 07release/2.4:7a02b9cb2d03: avformat/riffenc: Filter out "BottomUp" in ff_put_bmp_header()
[00:32] <ubitux> wm4: look at term_init() in ffmpeg.c
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:b8d34604ff16: tests/fate-run.sh: Cat .err file in case of error with V>0
[00:32] <cone-44> ffmpeg.git 03Philip DeCamp 07release/2.4:9d79848f841d: libavutil/opt: fix av_opt_set_channel_layout() to access correct memory address
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:16c3d6d3927e: avformat/img2dec: fix error code at EOF for pipes
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:76a5cf1f80a2: avformat/img2dec: pass error code and signal EOF
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:1d1099748809: avformat/img2dec: initialize pkt->pos for image pipes
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:e1fd837888ce: avformat/img2dec: enable generic seeking for image pipes
[00:32] <cone-44> ffmpeg.git 03lvqcl 07release/2.4:da5e52010ce8: avutil/x86/cpu: fix cpuid sub-leaf selection
[00:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:a9b9751bc88a: avcodec/ac3enc_template: fix out of array read
[00:33] <cone-44> ffmpeg.git 03Reimar Döffinger 07release/2.4:6099d1ca0e60: configure: add noexecstack to linker options if supported.
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:1d987a34d8b5: avformat/hlsenc: export inner muxer timebase
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:b29f9897e329: avcodec/jpeglsdec: Check run value more completely in ls_decode_line()
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:6f5c5051096a: avcodec/mjpegdec: check bits per pixel for changes similar to dimensions
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:f7c0f8355e5d: avcodec/utils: Add case for jv to avcodec_align_dimensions2()
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:853a27e345f4: avcodec/h263dec: Fix decoding messenger.h263
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:03d30d4c2c4d: avcodec/mmvideo: Bounds check 2nd line of HHV Intra blocks
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:f6476944e1a7: avcodec/tiff: more completely check bpp/bppcount
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:4b4ed88e8920: avcodec/pngdec: Calculate MPNG bytewidth more defensively
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:d9bef14e41a4: avcodec/pngdec: Check bits per pixel before setting monoblack pixel format
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:71f0a3c4adcf: avcodec/cinepak: fix integer underflow
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:7f90eef87ac8: avcodec/gifdec: factorize interleave end handling out
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:b89f279cd624: avcodec/qpeg: fix off by 1 error in MV bounds check
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:c0c24bc9b324: avcodec/smc: fix off by 1 error
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:506368f563b8: avcodec/svq3: Dont memcpy AVFrame
[00:33] <cone-44> ffmpeg.git 03Thomas Volkert 07release/2.4:a16558e12204: sdp: add support for H.261
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:eefc3ca7bed6: avcodec/vorbisdec: Fix off by 1 error in ptns_to_read
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:32dbd1f3428b: avformat/mpegts: Check desc_len / get8() return code
[00:33] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:32e8922faf2e: avformat/mpegts: use a padded buffer in read_sl_header()
[00:34] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:67991f3a3e5a: avcodec/h264: Check mode before considering mixed mode intra prediction
[00:34] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:1d99adc95317: avcodec/hevc: fix chroma transform_add size
[00:34] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:84d26ab6eb07: avcodec/on2avc: Check number of channels
[00:34] <ubitux> heh
[00:34] <wm4> ubitux: ah, ffmpeg.c uses it
[00:34] <wm4> but that's termios
[00:35] <ubitux> i meant term capabilities in general
[00:43] <akira4> ubitux,  removed the '=' . http://pastebin.com/9Bh8eg9t
[00:54] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:09256527be47: Update for 2.4.2
[00:57] <ubitux> akira4: alright, i'll make a proper review tomorrow (it's 1am here)
[00:57] Action: ubitux afk
[00:58] <akira4> thanks :) 
[01:01] <cehoyos> michaelni: did you already release? If not, did you see ticket #3977?
[01:16] <michaelni> cehoyos, i think this is already fixed
[01:17] <michaelni> cehoyos, see 16c3d6d3927ef4b8e8f5fb58d5fef064957edce2
[01:25] <cehoyos> michaelni: Doesn't that mean that you backported tickets #3948 and #3976 to 2.4 ?
[01:28] <michaelni> cehoyos, would beastds patch from "[FFmpeg-devel] [PATCH] avformat/img2dec: fix glob pattern detection." fix this ?
[01:37] <cehoyos> michaelni: I don't think that patch can fix ticket #3976 (but didn't test)
[01:38] <michaelni> what do you suggest (ill try to fix 3976)
[01:38] <michaelni> ?
[01:55] <cone-44> ffmpeg.git 03Michael Niedermayer 07master:684508ba15ca: avformat/img2dec: Support -loop with pipes
[01:55] <michaelni> cehoyos, fixed 3976, ill backport that one
[02:10] <michaelni> cehoyos, ive a slightly better fix for 3948
[02:14] <beastd> michaelni: Your fix for 3948; you send it on ffmpeg-devel?
[02:20] <michaelni> beastd, patch sent
[02:25] <michaelni> beastd, if you prefer i can apply yours instead, there is probably not a real differecnce between them
[02:29] <michaelni> also if people wants me to wait with releasing 2.4.2 or revert the image2 related fixes instead of trying to quickly fix it all, speak now
[02:30] <beastd> michaelni: 3976 was not related to 3948, right?
[02:31] <michaelni> they woth where regerssions since b3fd2b17
[02:32] <beastd> I see, but fixing one of the regressions would never help the other.
[02:34] <michaelni> reverting b3fd2b17 might fix both
[02:34] <michaelni> it would cause 3901 to reappear though
[02:35] <michaelni> with the last patch i posted or your patch all _should_ be fixed ... 
[02:36] <michaelni> should if murphies law doesnt hit ..
[02:36] <beastd> so one question is if  b3fd2b17 (fix 3901) is worth it. it was something about a "mis-named" image file that was not decoding
[02:38] <beastd> i do not really understand the fix to 3901, so i cannot really comment on that.
[02:38] <beastd> i will look at your patch now to see if i prefer it to mine
[02:42] <beastd> michaelni: i was thinking about the pattern_type solution too. it was the first thing i wanted to try.
[02:42] <michaelni> the 3901 fix is very simple, before it .png was sent to the img2 demuxer without its content being inspected afterwards the content is inspected and its send to the png_pipe demuxer instead
[02:43] <michaelni> the difference of the demuxer causes the bugs as it lacked some features
[02:46] <michaelni> also if the png file actually represents several concatenated pngs then the png_pipe choice will work alot better id assume
[02:47] <beastd> but then after thinking about it I came to the conclusion that even if we could check for pattern_type, it would still not be quite right. imagine a demuxer specific option that is named identically for 2 different muxers. so matching for demuxer options in the probe would cause kind of unstable behaviour depending on the existence and preference of demuxer options.
[02:47] <beastd> anyway, that is rather theoretical as we can't check. i just wanted to exchange thoughts on this as i considered it too.
[02:48] <michaelni> 2 demuxers should not use the eqally  named option for different things 
[02:48] Action: wm4 thinks image2 demuxer shouldn't even exist and should be a protocol instead
[02:49] <beastd> michaelni: in an ideal world maybe. and still you it might cause problems even if it uses the option for the same thing. think of 2 demuxers that support globbing for the input 
[02:53] <beastd> michaelni: so do i understand correctly that since b3fd2b17 we always prefer the *_pipe muxers too image2 (if the input is not a sequence/glob pattern)
[02:54] <michaelni> yes if their probe function detects the file content
[02:59] <beastd> michaelni: that is may indeed be preferable. but do we want it for this release? Else there might be the option to postpone it by reverting b3fd2b17 in the release branch
[03:01] <michaelni> the question is which way its more likey less buggy, and we have insufficient information to really awnser  that
[03:04] <michaelni> so in absence of any strong oppinions ill pick one and make the release in an hour or 2, delaying it is not a good idea, it contains alot of important fixes
[03:04] <beastd> michaelni: yes. no strong opinion here.
[03:05] <michaelni> and a weak oppinon maybe ?
[03:06] <beastd> michaelni: i will sent another 3948 fix based on your patch (you copied my \0 typo)
[03:06] <cone-44> ffmpeg.git 03Luca Barbato 07master:68211c70afcf: vc1: Do not assume seek happens after decoding
[03:06] <cone-44> ffmpeg.git 03Michael Niedermayer 07master:de52af901721: Merge commit '68211c70afcfd4d675029cc85fba7dee8de53bdf'
[03:09] <beastd> michaelni: i cannot really estimate how likely the switch to the image pipes could cause trouble. despite that potential for disruption i would probably choose to go forward and not revert.
[03:11] <beastd> though reverting will not be much worse from a user perspective in comparison to prior ffmpeg releases. so it might be the safer choice for this release
[03:16] <michaelni> beastd, ok, ill retest a bit and then pick one
[03:16] <michaelni> thx
[03:20] <cone-44> ffmpeg.git 03Luca Barbato 07master:89fa2b561627: x11grab: Check for XFixes availability at runtime
[03:21] <cone-44> ffmpeg.git 03Michael Niedermayer 07master:98baa8151a50: Merge commit '89fa2b5616274194d90bde0aeebf6adbd1245193'
[03:32] <cone-44> ffmpeg.git 03Luca Barbato 07master:5b9c817dc757: x11grab: Check XFixesGetCursorImage return value
[03:32] <cone-44> ffmpeg.git 03Michael Niedermayer 07master:8e5be0fffe9f: Merge commit '5b9c817dc7577b6d44acc94d73b9c77c52cda489'
[03:45] <beastd> michaelni: sent another 3948 fix based on your variation. should produce the same object code despite the removed extra NUL
[03:52] <cone-44> ffmpeg.git 03Antonio Ospite 07master:2a5ac99e6e06: x11grab: Check the XQueryPointer return value
[03:52] <cone-44> ffmpeg.git 03Michael Niedermayer 07master:345160a9cdf2: Merge commit '2a5ac99e6e06078713f684fee2466c91f677b303'
[03:53] <michaelni> beastd, ok thx, will apply it
[03:53] <michaelni> unless you want to apply it
[03:58] <cone-44> ffmpeg.git 03Alexander Strasser 07master:e079d43af86c: avformat/img2dec: Attempt to detect non-escaped glob patterns too (-pattern_type glob)
[03:59] <beastd> michaelni: thx. i was brushing my teeth. so i didn't immediately see your reply.
[04:04] <cone-44> ffmpeg.git 03Michael Niedermayer 07release/2.4:b02e4faa3ef9: avformat/img2dec: Support -loop with pipes
[04:04] <cone-44> ffmpeg.git 03Alexander Strasser 07release/2.4:d61454e7c1de: avformat/img2dec: Attempt to detect non-escaped glob patterns too (-pattern_type glob)
[04:36] <cone-44> ffmpeg.git 03Alexander Strasser 07fatal: ambiguous argument 'refs/tags/n2.4.2': unknown revision or path not in the working tree.
[04:36] <cone-44> Use '--' to separate paths from revisions
[04:36] <cone-44> refs/tags/n2.4.2:HEAD: avformat/img2dec: Attempt to detect non-escaped glob patterns too (-pattern_type glob)
[04:51] <Compn> sid now, wow
[09:46] <pross> Compn: baby steps
[10:12] <hima> hi ubitux
[10:13] <hima> i was going through both srtdec.c and vplayerdec.c 
[10:13] <hima> vplayer is also another format of subtitle like srt is it? 
[11:57] <hima> ubitux:hi 
[11:57] <ubitux> hima: hi
[11:58] <ubitux> yes vplayer is yet another format of subtitles
[11:58] <hima> where can i get some examples?
[11:58] <hima> of vplayer
[11:58] <ubitux> hima: did you rsync the fate samples ?
[11:58] <ubitux> https://ffmpeg.org/fate.html
[11:59] <ubitux> you'll find one in the sub directory in the fate samples 
[12:00] <hima> ohh okkay i am seeing 
[12:07] <pa> hi. i have a question regarding how ffmpeg accesses mkv files over http (also since ffmpeg is used by 80% of the players)
[12:08] <pa> so what i noticed is the following:
[12:09] <pa> i feed a mkv file over http to a player (say mplayer or mpv-player, i think both use ffmpeg), and what i can see server side is that a t the first seek, the player tries to download the cues of the video, and then seeks at one of the cue points.
[12:09] <pa> so fine. makes sense i thought
[12:11] <pa> then i tried to feed the player with a fake cue block, where the offsets for the cue points were arbitrary. What i noticed then was that the players weren't even trying to use these offsets, but started trying to discovery the keyframe offset starting with small seek offsets and gradually increasing it. The question is: why this? why wouldnt ffmpeg honor the offset it gets in the cue points?
[12:13] <hima> ubitux: reading the logs with akira. You asked to output in "text" format. srtdec.c and vplayerdec.c use a different codec id . So similarly for .LRC i use the text codec id?
[12:14] <ubitux> hima: yes, for now you can do that
[12:14] <hima> okay 
[12:15] <ubitux> i'm not sure there is actually support for multiline in .lrc
[12:15] <ubitux> you'll need to add a codec if you find lrc with multiline support marked with characters such as |
[12:15] <ubitux> but text should be fine currently
[12:16] <ubitux> i looked at all the .lrc from the github repository, and only one has one '|'; and i'm not sure it's actually supposed to translate to a new line
[12:17] <ubitux> the complexity in your qualification task will be to handle the duration of the events, and the duplicated timestamps per line
[12:18] <ubitux> you'll see that when you'll have a working version for simple cases
[12:18] <hima> okay. regarding the log ffmpeg -i in.stl out.srt . For my qualification task i should be able to do this ffmpeg -i in.lrc out.srt is it?
[12:18] <pa> or, if nobody here is familiar with the networking part, do you know who are the guys who did this part? :)
[12:18] <ubitux> hima: yes
[12:19] <ubitux> pa: i think BBB did the original matroska demuxer
[12:19] <ubitux> Aurelien Jacobs reworked it according to the file, but we haven't heard of him in a while
[12:19] <ubitux> you might want to ask the mailing list if no one is answering
[12:19] <pa> ubitux, do you know whether the demuxer would behave the same on a local file or on a http file?
[12:19] <pa> it might, right?
[12:20] <nevcairiel> yes
[12:20] <nevcairiel> most things behave the same, no matter where the file coems from
[12:20] <pa> ok thanks! then i could try to write on the mailing list
[12:20] <ubitux> the http protocol might behave differently in case the server doesn't support range requests though for example
[12:21] <ubitux> but the code in the demuxer has no knowledge of it
[12:21] <pa> exactly. but luckily in my case it does
[12:21] <ubitux> it's using the avio API, it opaque
[12:21] <ubitux> it's*
[12:21] <nevcairiel> note that for your issue at hand, the cue points are only used for actually seeking in t he v ideo, normal playback doesnt use them otherwise
[12:22] <cone-799> ffmpeg.git 03Matthew Oliver 07master:e81eca0ce59a: configure: Set large address aware.
[12:22] <pa> nevcairiel, yes exactly. i have the problem arising when i seek
[12:23] <nevcairiel> well, send a patch to improve it!
[12:23] <pa> so normally, with a correct cue block, players more or less follow it (the most accurate being mpv player, that i think still uses ffmpeg)
[12:23] <pa> but when i try to feed a made up cue block, the players completely ignore it
[12:23] <nevcairiel> maybe your made up block is wrong
[12:23] <pa> nevcairiel, i could, but i guess first i have to understand what's going on
[12:24] <pa> nevcairiel, well, so , the way i made it up is as following
[12:24] <pa> i copied the number of cue points in the original block, as well as the cue times for the points
[12:24] <pa> i simply changed the offsets, from the original to multiples of 100000
[12:25] <pa> first point being 100000, second 200000 and so on
[12:25] <pa> (i tried different sized too)
[12:25] <pa> but the result is that these offsets are being ignored
[12:54] <cone-799> ffmpeg.git 03Pascal Massimino 07master:19fb47684193: avcodec/webp: add optimization: use local palette with extra padding
[13:22] <Compn> pa : mplayer, if using -demuxer mkv, will not use any ffmpeg code to access an http stream (aside from decoder). only mplayer -demuxer lavf ffmpeg://http:// will use ffmpeg demuxer and network code.
[13:23] <Compn> but since mplayer and ffmpeg shared a lot of developers, they may act in similar manner :P
[13:24] <cone-799> ffmpeg.git 03Michael Niedermayer 07master:436206c1756c: avcodec/webp: add assert to ensure palette is not larger than 256
[14:20] <cone-799> ffmpeg.git 03Diego Biurrun 07release/2.2:f13f5a7d4b6c: Add some bug references to the changelog
[14:20] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:ac0dea5dd76f: Merge commit 'f13f5a7d4b6c57a11c63ba5e4f972f0bff5f306a' into release/2.2
[14:43] <cone-799> ffmpeg.git 03Gianluigi Tiesi 07release/2.2:b0937dd61d76: avcodec/libilbc: support for latest git of libilbc
[14:43] <cone-799> ffmpeg.git 03Pascal Massimino 07release/2.2:a1605af9b559: avcodec/webp: fix default palette color 0xff000000 -> 0x00000000
[14:43] <cone-799> ffmpeg.git 03Benoit Fouet 07release/2.2:fe12b3a7a68c: avformat/riffenc: Filter out "BottomUp" in ff_put_bmp_header()
[14:43] <cone-799> ffmpeg.git 03Philip DeCamp 07release/2.2:fe0fd3de226a: libavutil/opt: fix av_opt_set_channel_layout() to access correct memory address
[14:43] <cone-799> ffmpeg.git 03lvqcl 07release/2.2:be894938c44f: avutil/x86/cpu: fix cpuid sub-leaf selection
[14:43] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:f1dd34300709: avcodec/ac3enc_template: fix out of array read
[14:44] <cone-799> ffmpeg.git 03Reimar Döffinger 07release/2.2:9726c1a5f89e: configure: add noexecstack to linker options if supported.
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:53330b30fd2c: avcodec/jpeglsdec: Check run value more completely in ls_decode_line()
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:6287107eae40: avcodec/mjpegdec: check bits per pixel for changes similar to dimensions
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:e5ccd894d1c1: avcodec/utils: Add case for jv to avcodec_align_dimensions2()
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:8acfae690111: avcodec/h263dec: Fix decoding messenger.h263
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:f2c6e2c3b4ee: avcodec/mmvideo: Bounds check 2nd line of HHV Intra blocks
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:f8bd98ae4d69: avcodec/tiff: more completely check bpp/bppcount
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:64be1a45eb26: avcodec/pngdec: Check bits per pixel before setting monoblack pixel format
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:d1e71ecbb017: avcodec/pngdec: Calculate MPNG bytewidth more defensively
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:42bdcebf3360: avcodec/cinepak: fix integer underflow
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:43881c773277: avcodec/gifdec: factorize interleave end handling out
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:d8fda618d01d: avcodec/qpeg: fix off by 1 error in MV bounds check
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:b0964918d882: avcodec/smc: fix off by 1 error
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:653329dfcb43: avcodec/vorbisdec: Fix off by 1 error in ptns_to_read
[14:44] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:23fdcd3b0a75: avformat/mpegts: Check desc_len / get8() return code
[14:45] <cone-799> ffmpeg.git 03Michael Niedermayer 07release/2.2:26da47a09be8: avcodec/h264: Check mode before considering mixed mode intra prediction
[15:05] <cone-799> ffmpeg.git 03Benoit Fouet 07master:904cfd257db5: avcodec/h264_mp4toannexb_bsf: reset the new IDR flag when SPS/PPS is seen.
[16:44] <pa> Compn, thanks, i try both then.. i wonder what it uses by default
[16:45] <pa> i think maybe it uses mkv by default
[16:45] <pa> anyway, the impression is that these players do not use the cues.. they rather uses the file size, and try to guess where the desired position is in the file
[16:46] <wm4> pa: no
[16:47] <wm4> btw. mpv uses its own demuxer, but you can make it use libavformat with --demuxer=lavf
[16:47] <wm4> pa: if they don't find the cues, they will scan the file linearly
[16:47] <pa> wm4, what if they find the cues?
[16:47] <wm4> and they stop once they find the target timestamp
[16:48] <wm4> if they find the cues they will do a direct seek
[16:48] <pa> wm4, but so why dont they, with my mangled cues?
[16:48] <wm4> maybe something is wrong with the cues
[16:48] <pa> i would expect at least an attempt to my fake offset
[16:49] <pa> hm.. maybe.. maybe immissing some field.. mkvinfo opens them correctly though
[16:52] <wm4> mkvinfo doesn't seek
[16:53] <wm4> and I think the file offset could still be wrong
[16:53] <wm4> and the timestamps
[17:53] <pa> wm4, what do you mean the file offset could still be wrong? it's certainly wrong... but the point is: how does the player know without even trying?
[17:54] <pa> anyway, my cue is generated by the mkvgenerator script in here https://github.com/paoletto/mediastreamer  , in case you want to have a look :)
[18:06] <pa> the only thing i have left to try is to add a second seek head at the end, like x264 does
[18:29] <hima> ubitux: hi
[18:30] <hima> i was going through the files in libavformat. And i saw that lrcdec.c has already been written. I ran it trying to convert lrc to srt and it worked perfectly fine
[18:32] <ubitux> oh god
[18:32] <ubitux> how could i have missed that
[18:33] <hima> yeah. umm so now?
[18:33] <ubitux> alright give me 20 minutes, i'm going to find you another one
[18:33] <hima> okay that is fine :)
[18:34] <hima> umm i have a few doubts from lrcdec.c should i ask now?
[18:35] <ubitux> sure
[18:37] <hima> why is the structure of lrc different as in we have taken a variable offset?
[18:37] <hima> and there is a comment as offset metadat item 
[18:38] <hima> whereas in vplayer or srt we just defined the queue in its structure
[18:38] <ubitux> that ts_offset thing could have been made local to lrc_read_header
[18:39] <ubitux> i suppose it was meant to be shared between the other callbacks
[18:39] <ubitux> but there is no real reason for having it in the context
[18:39] <hima> other callbacks?
[18:40] <ubitux> yeah, for example accessing it in lrc_read_seek for some reason
[18:41] <hima> ohh okkay 
[18:41] <ubitux> mmh maybe i could ask you to make a very basic kate file format support
[18:42] <ubitux> let me check for a sample
[18:42] <hima> okay cool 
[18:43] <ubitux> https://wiki.xiph.org/Kate#The_Kate_file_format  it looks like this
[18:43] <ubitux> i can't find a sample right now
[18:43] <ubitux> Compn: would you have one?
[18:44] <ubitux> hima: btw, i'm really sorry about that, i really didn't realized we had this
[18:45] <hima> its okay. Not a problem anyways i was just learning and exploring about it. Had not coded much 
[18:45] <ubitux> http://www.filewatcher.com/p/libkate_0.3.7.orig.tar.gz.728239/libkate-0.3.7/examples/kate/minimal.kate.html
[18:45] <ubitux> alright
[18:45] <ubitux> this one is minimal
[18:46] <ubitux> it can get really complex, but i'm obviously not asking for the full support
[18:46] <hima> okkay i will try it out 
[18:46] <ubitux> http://www.filewatcher.com/p/libkate_0.3.7.orig.tar.gz.728239/libkate-0.3.7/examples/kate/demo.kate.html this is a very complex example typically
[18:46] <ubitux> for the exercise, i'm just asking for the support of the event
[18:46] <ubitux> the simple text one
[18:47] <ubitux> as in minimal.kate
[18:47] <hima> okay. Ubitux 
[18:53] <wm4> <hima> i was going through the files in libavformat. And i saw that lrcdec.c has already been written. I ran it trying to convert lrc to srt and it worked perfectly fine <- oh god I'm sorry too
[18:53] <wm4> the file header says it's from 2014, so I guess it wasn't there yet when I checked last time...
[18:54] <wm4> oh it was even 3 months ago
[18:55] <hima> wm4 not a problem. i am learner and newbie. so i did learn and in the way found it :P
[18:57] <wm4> I recall two other subtitle tasks (but which had people working on it, but stalled now): implementation of 2 separate transport stream closed caption codecs
[18:57] <jamrial> https://www.sendspace.com/file/m2sg2s here's another kate sample. probably much simpler than the above
[18:58] <ubitux> isn't this muxed?
[18:58] <ubitux> jamrial: minimal.kate is trivial
[18:58] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:70eba7695cdf: configure: add -lrt to libavutil when needed for nanosleep
[18:59] <ubitux> wm4: yeah well, we still don't know how we are going to implement the cc, so while it could be nice after the selection, as a qualification task it's probably a bit hard
[18:59] <wm4> sure
[18:59] <jamrial> yeah, it's muxed
[19:01] <ubitux> it's incredible we now actually support almost every stupid subtitles format
[19:01] <ubitux> we can't find any more!
[19:02] <ubitux> hima: note that while this is a qualification task, your patch will probably not be applied as is even if you succeed; the minimal.kate really is a too small subset (kate really is a big complex format)
[19:03] <wm4> why not... smi is also a complex format and actually renders really badly with common real world files with rhe lavc decoder
[19:04] <wm4> *the
[19:04] <ubitux> well ok maybe;
[19:05] <ubitux> in this case we should probably make sure it's tolerant enough to skip the unknown section
[19:06] <ubitux> define bitmap { source "sample.png" }
[19:06] <ubitux> ahaha
[19:06] <ubitux> yeah, of course. :)
[19:06] <wm4> yep
[19:07] <wm4> I remember how it could do graphics
[19:07] <ubitux> i wonder how they achieve the muxing in ogg
[19:08] <hima> ubitux:  i understand. i am trying this then 
[19:08] <ubitux> hima: so yeah ideally, if you want it applied, you would have to make sure demo.kate does at least raise the few recognized event and ignore the rest
[19:08] <ubitux> but now just focus on minimal.kate
[19:10] <hima> okay. ubitux is akira done with .stl format else even i would have tried that instead of kate?
[19:10] <ubitux> i think she's done
[19:10] <ubitux> at least she has some working code
[19:11] <ubitux> it needs polishing and i need to review what she's done
[19:11] <ubitux> but well, it should be soon kind of ready
[19:11] <ubitux> maybe i can find another simpler format
[19:11] <ubitux> it would be interesting to compare with vlc
[19:12] <ubitux> they might support one or two extra lost formats
[19:12] <ubitux> do you want me to have a look?
[19:12] <hima> lemme try minimal.kate as it seems simple and as you say. if i fail then you do . Is that fine?
[19:13] <wm4> btw. kate has an associated library
[19:13] <ubitux> i have to go right now, i'll have a look in maybe 2 or 3 hours for simpler formats if you want to wait
[19:14] <hima> okay lemme start working with minimal.kate then 
[19:45] <cehoyos> Compn: You wrote yesterday "hey its our official spokesperson" - did you mean me? Because it seems I only understood the joke today...
[20:23] <Compn> cehoyos : lol , yes i meant you ... it seems like some people think you speak for the entire project when you speak 
[20:56] <cehoyos> Compn: As said, I only realised that today... - Sorry that I find this so absurd.
[21:49] <Compn> cehoyos : as do i.
[21:55] <cone-408> ffmpeg.git 03Michael Niedermayer 07master:c02ea58c5f0a: avformat/options_table: add FF_COMPLIANCE_UNOFFICIAL
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:42111bb960b5: avcodec: remove obsolete FF_API_FAST_MALLOC cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:1abb77285cff: avutil: remove obsolete FF_API_GET_BITS_PER_SAMPLE_FMT cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:71718de81447: avutil: remove obsolete FF_API_FIND_OPT cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:3e5752098275: avutil: remove obsolete FF_API_SAMPLES_UTILS_RETURN_ZERO cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:e524a9b1ff3d: avutil: remove obsolete FF_API_INTFLOAT cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:903a0acba46e: avformat: remove obsolete FF_API_ALLOC_OUTPUT_CONTEXT cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:cc787709ee6f: avformat: remove obsolete FF_API_FORMAT_PARAMETERS cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:a578b93c73a1: avformat: remove obsolete FF_API_NEW_STREAM cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:3bd9f17b8af9: avformat: remove obsolete FF_API_SET_PTS_INFO cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:ecf457f3ac49: avformat: remove obsolete FF_API_CLOSE_INPUT_FILE cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:ddc376816161: avformat: remove obsolete FF_API_READ_PACKET cruft
[22:19] <cone-408> ffmpeg.git 03James Almer 07master:fb7d8d50bc24: swscale: remove obsolete FF_API_SWS_FORMAT_NAME cruft
[22:50] <wm4> so libavformat reads about 5MB of data when reading a .ts... and then it wants to seek back to position 0... why?
[23:29] <Compn> wm4 : probe for more streams (audio, sub)
[23:29] <wm4> no
[23:33] <rcombs> anyone have advice on debugging ffmpeg with gdb on Win32?
[23:33] <wm4> [x] suicide
[23:33] <wm4> [X] build with msvc
[23:34] <JEEB> rcombs, https://x264.fushizen.eu/builds/gdb/
[23:34] <JEEB> "enjoy"
[23:34] <wm4> I mean, it does build with msvc (even natively now), and msvc's debugger is said to be good
[23:34] <wm4> while gdb on win32 never ever worked for me
[23:35] <rcombs> it's acting as if this was a stripped binary :/
[23:35] <JEEB> well good luck with that then
[23:36] <beastd> rcombs: stupid question: did you use ffmpeg_g ?
[23:36] <rcombs> beastd: yup
[23:36] <rcombs> and configured with `--enable-debug --disable-stripping`
[23:38] <Daemon404> no debug symbols?
[23:39] <rcombs> http://puu.sh/c0P9l/bc367b2cbb.png beautiful stack traces
[23:39] <wm4> null pointer deref?
[23:40] <rcombs> looks like it, it's SIGSEGV
[23:41] <beastd> rcombs: Did you try to set a break point on main to see if the source level debugging works in normal conditions (before a crash)?
[23:41] Action: rcombs tries that
[23:42] <rcombs> uh& that did nothing
[23:42] <rcombs> 0.o
[23:43] <beastd> you did not reach main() ?
[23:43] <beastd> or setting the break point didn't work?
[23:43] <rcombs> it set the breakpoint, but it didn't break
[23:45] <rcombs> uh& `b register_exit` -> http://puu.sh/c0PD1/93e0bcec0f.png but then `r` -> http://puu.sh/c0PEs/4d62560116.png
[23:46] <beastd> hmm, seems your gdb is indeed not doint all that well. i am afraid i can help you any more ATM
[23:47] <rcombs> same behavior with both mingw gdb and the newest build on the page JEEB linked
[23:48] <beastd> normally a "b main" followed by "r" should drop you right at main. trying to find out why it does not work may yield more results.
[23:49] <rcombs> yeah, that's weird as all hell
[23:52] <beastd> rcombs: Good luck with getting gdb to work or otherwise debug your problem! I need to go to sleep now.
[23:52] <rcombs> 'night
[23:52] <rcombs> thanks
[23:54] Action: J_Darnley half suggests using cygwin
[00:00] --- Mon Oct  6 2014