[Ffmpeg-devel-irc] ffmpeg-devel.log.20141017
burek
burek021 at gmail.com
Sat Oct 18 02:05:02 CEST 2014
[04:21] <rcombs> wm4: poking at that file from yesterday; mpv actually also has trouble seeking in the full version of it
[04:22] <rcombs> it works, but it takes a while, probably because it's reading the entire file instead of using the index/cues to seek
[04:30] <rcombs> looks like the demuxer just never finds any Cues
[04:32] <rcombs> (mpv has no trouble using its internal matroska demuxer)
[05:44] <cone-879> ffmpeg.git 03James Almer 07master:864f9326fb4d: x86/vf_noise: move asm code to a separate file
[06:30] <cone-879> ffmpeg.git 03Moritz Barsnick 07master:bbd8c8526320: doc/filters.texi: fix several typos in the vidstab* sections
[07:13] <rcombs> so, commenting out matroskadec.c:1371 fixes it, but I'm not sure if that has a reason to be there
[07:34] <rcombs> apparently added in a commit from 2008; 13b350a3a4b2f9a04d2d2bcdee5b7f26d96fe34b
[08:00] <jamrial> http://pastebin.com/1KY7kGm7 the power of bmi2's rorx instruction
[08:05] <jamrial> gcc also generates vfm{add,sub} instructions instead of a combination of mulss/{add,sub}ss if you use -fma or -fma4
[08:05] <jamrial> really nice
[08:41] <akira4> I'm trying to add a sample to the fate-suite. How exactly is it done?
[08:48] <jamrial> if you mean locally, follow ubitux's instructions on his latest email. namely just drop the sample inside the folder you rsynced the fate suit, add the relevant entry to subtitles.mak, then run the test adding GEN=1 to create the reference file
[08:48] <jamrial> if you meant to the rsync server, it will be uploaded after the test you wrote is reviewed and accepted
[08:49] <jamrial> rcombs: you forgot to attach the patch :p
[08:50] <akira4> I see. I get an error when I try to rsync http://pastebin.com/tFaiywAx.
[08:50] <rcombs> jamrial: huh? It shows as attached here&
[08:50] <jamrial> rcombs: http://ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164181.html
[08:52] <rcombs> jamrial: well that's certainly strange; just re-sent
[08:54] <rcombs> AND failed again
[08:54] <rcombs> no idea what's going on with that
[08:55] <jamrial> try pasting the patch in the body. as long as your client doesn't break lines it should be ok
[08:56] <rcombs> linked to a gist
[08:57] <jamrial> akira4: try again. that shouldn't happen
[08:58] <jamrial> it may be something with your connection. the rsync server seems to be working for me
[09:00] <akira4> okay. thanks.
[09:45] <j-b> 'morning
[13:03] <wm4> rcombs: can you post the file?
[13:13] <cone-104> ffmpeg.git 03Janne Grunau 07master:f29c226af0ec: fate: add mpeg4 tests for frame size changes
[13:13] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:1aed82846cbc: avformat/m4vdec: mark as possibly containing discontinuities
[13:13] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:a708689fdac6: Merge commit 'f29c226af0ecc34c417b646580a9acd7d8bbaf48'
[13:13] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:c40a1bd253f6: tests/fate/mpeg4: fix samples path
[13:24] <cone-104> ffmpeg.git 03Luca Barbato 07master:cf83c0173917: avplay: Always free find_stream_info options
[13:24] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:019ff7a0c37a: Merge commit 'cf83c0173917a44b89a25ea2b435429bbf9ee767'
[13:34] <cone-104> ffmpeg.git 03Luca Barbato 07master:e58a140cf91d: avplay: Always free opts
[13:34] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:ee73a69020a8: Merge commit 'e58a140cf91d1a9cdfa3115d73c923dab0e9e7dc'
[13:43] <cone-104> ffmpeg.git 03Luca Barbato 07master:aeb23fc4549a: avprobe: Remove a pointless check
[13:43] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:9d1155dae303: Merge commit 'aeb23fc4549a25ef32ff085d2a76227f90caf403'
[14:04] <cone-104> ffmpeg.git 03Vittorio Giovara 07master:c802a2e718fb: avconv: fix leak in filter error
[14:04] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:1dd38e99fd12: Merge commit 'c802a2e718fb3619291f310f851f1a1cdcf4f581'
[14:04] <prachi> i was wondering if anyone could tell me what
[14:05] <prachi> if (sscanf(ptr, "%*d:%*d:%*d.%*d%c", &c) == 1 && strchr(": =", c))
[14:05] <prachi> means
[14:05] <prachi> static int vplayer_probe(AVProbeData *p)
[14:05] <prachi> 35 {
[14:05] <prachi> 36 char c;
[14:05] <prachi> 37 const unsigned char *ptr = p->buf;
[14:05] <prachi> 38
[14:05] <prachi> 39 if (sscanf(ptr, "%*d:%*d:%*d.%*d%c", &c) == 1 && strchr(": =", c))
[14:05] <prachi> 40 return AVPROBE_SCORE_MAX;
[14:05] <prachi> 41 return 0;
[14:05] <prachi> 42 }
[14:06] <prachi> in this function
[14:06] <prachi> I was looking for some help
[14:06] <J_Darnley> Woah! Use pastebin rather than pasting in the channel.
[14:06] <wm4> prachi: use http://sprunge.us
[14:06] <prachi> okay,soory,I am new.will take care in future
[14:07] <J_Darnley> if scanf return 1 it means it read exactly one thing (number, character, string)
[14:08] Action: J_Darnley really hates strings
[14:08] <Daemon404> they're only bad if you use
[14:08] <Daemon404> C
[14:08] Action: Daemon404 runs
[14:10] <prachi> okay!
[14:11] <J_Darnley> Okay, I think this code is checking that the string in ptr has a colon, space, or equals sign following a series of numbers.
[14:14] <J_Darnley> I also hate binary data formats, especially ones that have gone through several rounds of backward or forward compatible extension.
[14:15] <J_Darnley> If I may quote a comment I read last night "size of extended data + 4 cause we fucked up".
[14:21] <cone-104> ffmpeg.git 03Vittorio Giovara 07master:c92965dbfbb7: avconv: check return value
[14:21] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:61c6e69709ca: Merge commit 'c92965dbfbb7e2b49df14db2fd0e23a29295730a'
[14:40] <Daemon404> ARG
[14:40] Action: Daemon404 bitten again by lack of fucking pkg config use in configure for various libs
[14:40] <ubitux> :)
[14:41] <Daemon404> not just x264 this time!
[14:41] <ubitux> which one?
[14:41] <Daemon404> libvpx
[14:41] <ubitux> aaah libvpx
[14:41] <ubitux> and the checks are awesome
[14:41] <Daemon404> its especially misleading
[14:41] <Daemon404> cause it checks for a header and then says "needs >=0.9.1"
[14:41] <Daemon404> as if it had used pkg config
[14:42] <cone-104> ffmpeg.git 03Luca Barbato 07master:0db6bbb24c1a: avformat: Make avformat_free_context handle NULL
[14:42] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:7dba57d1fa6b: Merge commit '0db6bbb24c1a9f6b5527f460361a5a4132248eee'
[14:43] <ubitux> the 7 lines of vpx hacks could be replaced with a check_pkg_config "vpx >= 0.9.7" or something
[14:43] <Daemon404> yea
[14:43] <ubitux> good luck with that
[14:43] <Daemon404> sure ill send it to libav
[14:43] <Daemon404> where carl isnt a huge asswad
[14:43] <ubitux> right now i'm suppose to write a code that use pkg config for x264 and fallbacks on the hack
[14:44] <ubitux> i'm actually not happy with that so i'll probably won't do it
[14:44] <Daemon404> meanwhile at libav, pkgconfig for months
[14:44] <Daemon404> :/
[14:45] Action: Daemon404 seems to remember some ffmpeg guys sayign somethign akin to "no patch is going to be held up by one guy over at ffmpeg"
[14:45] <Daemon404> carl hath become diego
[14:45] <nevcairiel> no, he is actually worse
[14:45] <Daemon404> thats true.
[14:49] <J_Darnley> What was his objection to pkg-config?
[14:49] <J_Darnley> I mean I dislike it for depending on glib
[14:49] <ubitux> "it breaks current configuration"
[14:50] <iive> what does it break?
[14:50] <ubitux> it breaks if you don't have pkg-config
[14:50] <nevcairiel> presumably people who have giant hacks on their system to accomodate the old broken mess
[14:51] <ubitux> and i maintain the idea that documenting a behaviour change is better than adding a shitload of fallback crap in the configure
[14:51] <Daemon404> any sane person would
[14:51] <nevcairiel> why are we listening to him again
[14:51] <Daemon404> nobody ever said why.
[14:51] <ubitux> it's like, "ok let's use pkg-config, but still specify -lx264 just in case"
[14:52] <iive> the person who wrote most of configure is Mans, and he hated pkg-config
[14:52] <iive> that's why it is almost never used...
[14:54] <Daemon404> that's a load of shit, iive
[14:54] <iive> you can blame him for the level of obfuscation in the configure
[14:54] <Daemon404> and also a terrible reason even if it were true
[14:55] <Daemon404> (also irrelevant to teh situation at hand)
[14:55] <iive> it makes the code a lot smaller, but it is insanely hard to customize tests.
[14:55] <Daemon404> not really true if youve actually looked
[14:55] <Daemon404> i can spout cargo culted opinions from 8 years ago too.
[14:56] <iive> you don't even know what that phrase means.
[14:56] <wm4> time to overrule cehoyos?
[14:56] <Daemon404> iive, perhaps you do not
[14:56] <Daemon404> also, as i said, entirely irrelevant to the problem at hand:
[14:56] <Daemon404> 1) a proper fix is there
[14:56] <Daemon404> 2) carl wont let it in
[14:57] <wm4> if, say, at least 5 devs agree to a patch replacing manual checks with pkg-config, and only cehoyos disagrees...
[14:57] <wm4> does he have some magical veto-right?
[14:57] <Daemon404> more than 5 have already agreed
[14:58] <iive> well, the best solution would be to try pkg-config first and if it is not available, fall back to the current method
[14:58] <iive> how easy is to do that?
[14:58] <wm4> isn't this already done for some things
[14:58] <Daemon404> iirc ubitux sent that already
[14:58] <iive> then, there is no breakage.
[14:59] <wm4> of course not
[14:59] <Daemon404> carl had some insane argument along the lines of
[14:59] <wm4> the problem is that cehoyos is a blockhead
[14:59] <Daemon404> if you have two x264 installs
[14:59] <Daemon404> and one is pkg config and one is not
[14:59] <Daemon404> itll break for you by picking up the wrong one
[14:59] <Daemon404> or something
[14:59] <Daemon404> (dotn quote me)
[14:59] <nevcairiel> define "wrong one"
[14:59] <nevcairiel> ie. "whichever he wants it to use"
[15:08] <iive> hum...
[15:08] <iive> i don't see it. I found an x264 one
[15:09] <iive> but the fallback is actually workaround, by asking the user to specify --pkg-config=true and setting the libraries manually
[15:09] <iive> that's not falling back... that's hack.
[15:10] <iive> (aug 28)
[15:10] <nevcairiel> its fine to simply document that we require pkg-config, we already do for a bunch of other libs
[15:11] <ubitux> iive: yes it's a hack to replace another hack
[15:11] <ubitux> if you really don't want to use pkg-confiug
[15:13] <iive> i don't get it... if you don't want to use pkg-config , shouldn't you specify it to `false` to emulate its absence?
[15:13] <benoit-> ubitux: maybe you could use --enable-libx264 vs --enable-libx264-pkg-config, or --enable-libx264 vs --enable-libx264-no-pkg-config?
[15:14] <benoit-> iive: I believe that its absence would make configure fail
[15:14] <benoit-> or other things would have to be done to handle this too, and that would affect other libs configuration
[15:14] <iive> well, the idea of fallback is that, you first check if pkg-config is available/working
[15:14] <ubitux> it's stupid to duplicate that logic
[15:15] <iive> if it is, then use it.
[15:15] <ubitux> i just don't want to keep the hack
[15:15] <benoit-> ubitux: yes
[15:15] <ubitux> it's broken
[15:15] <ubitux> and if we keep it people will use it
[15:15] <iive> if it is not, then fallback to the current method.
[15:15] <benoit-> iive: that was proposed, IIRC
[15:15] <iive> was it implemented?
[15:15] <benoit-> only it was not sufficient
[15:16] <ubitux> i don't want to have the "-lx264" written in configure
[15:16] <benoit-> as it would not allow to discriminate "easily" between x264 pkg-config vs without
[15:16] <ubitux> it's the task of pkg-config
[15:16] <Daemon404> not using pkg-config to begin with was wrong
[15:16] <benoit-> ubitux: the point of iive is that it's its role when it's present
[15:16] <Daemon404> benoit-, the library defines pkg-config as teh way to use it.
[15:17] <ubitux> pkg-config is the only official supported way by libx264 period.
[15:17] <Daemon404> if it's not present, anythign else is a hakc
[15:17] <Daemon404> what ubitux said.
[15:18] <ubitux> it's just like if someone had a project using cmake but prefered to gcc src/*.c
[15:18] <ubitux> cmake might sucks but that's how it is
[15:18] <ubitux> deal with it
[15:18] <Daemon404> except pkg-config is actually useful.
[15:18] <iive> ubitux: you see, it is not about code cleanness and purity
[15:19] <iive> it is about users, and if users need this mess, you have to deliver.
[15:19] <ubitux> they don't
[15:19] <Daemon404> every user i have talked to massively prefrred pkg config
[15:19] <ubitux> they're using the hack because that's the only solution available currently
[15:19] <Daemon404> also that
[15:19] <ubitux> we have tons of tickets in the trac complaining about that
[15:19] <iive> think of it this way. you first have to introduce pkg-config an provide fallback
[15:20] <iive> then a while, remove the fallback
[15:20] <benoit-> just an historic point, though... when x264 support reached ffmpeg tree back in 2005, there was no pkg-config support
[15:20] <iive> then after a while, remove the fallback
[15:20] <benoit-> ubitux: and you already know I'd prefer having pkg-config in place
[15:21] <j-b> Are you still discussing pkg-config?
[15:21] <iive> or, if you demand code purity. rewrite pkg-config without glib
[15:21] <ubitux> alright, so i'm going to had more code in the configure
[15:21] <j-b> iive: there are already 20x of such projects
[15:21] <ubitux> which makes sure the code is disabled at next bump
[15:21] <cone-104> ffmpeg.git 03Luca Barbato 07master:47e3e1097e09: cmdutils: Use the correct guard
[15:21] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:1eda312aca27: Merge commit '47e3e1097e09da7f973908e09df15e3bb7c5e1f4'
[15:21] <j-b> Sorry guys, but pkg-config troll was fought and lost 8 years ago
[15:21] <benoit-> j-b: no, they (we?) discuss the x264 configuration in ffmepg
[15:21] <ubitux> j-b: we all agree with the pkg-config stuff here
[15:21] <j-b> Use pkg-config.
[15:22] <j-b> drop everything else.
[15:22] <ubitux> j-b: we're just trying to workaround cehoyos
[15:22] <j-b> rm -rf cehoyos.
[15:22] <Daemon404> ^ +1
[15:22] <j-b> fuck him
[15:22] <Daemon404> yes.
[15:22] <j-b> http://sourceforge.net/projects/pkgconfiglite/
[15:22] <iive> j-b: is any of these rewrites good enough to put inside ffmpeg?
[15:22] <ubitux> j-b: i'm actually willing to copy that .c in ffmpeg
[15:22] <ubitux> instead of keeping that shitty hack
[15:22] <Daemon404> j-b, freebsd also uses pkgconf
[15:23] <Daemon404> iive, that's teh distro's job
[15:23] <Daemon404> ln -s etc
[15:23] <Daemon404> ffmepg is not mplayer
[15:23] <Daemon404> it shouldnt be inside ffmpeg.
[15:23] <j-b> And we come back to what I've been saying in years: SPLIT YOUR FUCKING REPOS
[15:24] Action: j-b is now an old troll
[15:24] <ubitux> let's not change subject :P
[15:24] <iive> ubitux: do the ugly hack and be done with it.
[15:25] <benoit-> Sorry j-b, but splitting repo troll was fought and lost years ago ;)
[15:25] <ubitux> iive: no it sucks
[15:25] <ubitux> if you want to, do it
[15:25] <iive> ubitux: trust me, it is the better decision.
[15:25] <Daemon404> iive? write code? LOL
[15:25] <ubitux> well, anything can submit that patch, i don't care if it's iive or someone else
[15:25] <j-b> benoit-: :)
[15:26] <ubitux> i don't want to do deal with that anymore
[15:26] <Daemon404> ubitux, if carl is involved i keep a distance.
[15:26] <Daemon404> as do most i imagine
[15:26] <benoit-> ubitux: can you ping your last version so that it's resurrected from where it is, please?
[15:26] <ubitux> i can rebase it for you if you want
[15:26] <ubitux> just a moment
[15:27] <benoit-> ubitux: merci
[15:28] <ubitux> benoit-: might actually take me some time
[15:28] <ubitux> benoit-: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161979.html
[15:28] <ubitux> i need to split and stuff
[15:28] <ubitux> the idea is to make it more obvious that it's using pkg-config etc
[15:29] <ubitux> i could probably start applying the other chunks
[15:30] <ubitux> that was my latest iteration
[15:33] <cone-104> ffmpeg.git 03Uwe L. Korn 07master:324b23dde1bc: rtmpproto: Add function to read a number response
[15:33] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:6cf9d02cea5e: Merge commit '324b23dde1bc8638959eb32419c95a93906db272'
[15:39] <cone-104> ffmpeg.git 03Uwe L. Korn 07master:e65c776d18dc: rtmpproto: Add getStreamLength call to query duration
[15:39] <cone-104> ffmpeg.git 03Michael Niedermayer 07master:3dda0bbe4250: Merge commit 'e65c776d18dc14df8a279e017760862f9fc8763b'
[16:05] <cone-104> ffmpeg.git 03Benoit Fouet 07master:ac1594bc179a: gitignore: add test_copy.ffmeta
[16:23] <cone-104> ffmpeg.git 03Benoit Fouet 07master:242f8bb3a8a1: avformat/id3v2: support buggy id3v2.3 tag length in id3v2.4
[16:36] <benoit-> ubitux: just sent a patch with a "minimal" workaround for x264
[17:24] <ubitux> benoit-: missing versions check
[17:25] <ubitux> but it's insane anyway
[17:25] <ubitux> ah yeah you actually have version check
[17:25] <ubitux> but not with pkg-config
[17:25] <ubitux> derp, that's insane
[17:25] <Daemon404> an insane patch to satisfy an insane person
[18:51] <hawken> Got an answer from Jochen Britz, "My code is under the same license as FFmpeg itself."
[18:51] <hawken> Referred me to this: https://groups.google.com/forum/#!forum/h264mvc
[18:52] <hawken> Pointed me to koda's work
[18:53] <myra> Can someone explain me what is fate folder ? What is it used for ?
[18:53] <wm4> myra: FATE is the ffmpeg automatic test suite
[18:54] <wm4> the scripts are in the ffmpeg git repo itself, the associated test data is on a separate rsync server
[18:54] <wm4> there's some documentation about it
[18:56] <myra> @wm4 : I'll look into it . Thank you !!
[19:07] <Daemon404> dang kids and their out of place @s...
[20:06] <hima> here http://fpaste.org/142955/35686551/ here we define the function and the argument is char ** type
[20:07] <hima> ubitux : but when a value is passed its char* type is not it?
[20:07] <hima> i am getting this error in my code
[20:07] <hima> where i see it runs fine in vplayerdec.c
[20:08] <hima> ubitux
[20:08] <ubitux> that looks correct so far
[20:08] <ubitux> p is a char*
[20:09] <ubitux> and you send the address of p to the function
[20:09] <ubitux> so it becomes a pointer on char*, thus a char**
[20:09] <hima> yeah i know
[20:09] <hima> http://fpaste.org/142958/69378141/
[20:10] <hima> i get this error again and again
[20:10] <ubitux> can you show me the complete code?
[20:10] <hima> yeah just a second
[20:12] <hima> http://fpaste.org/142963/35695271/
[20:12] <hima> here
[20:14] <ubitux> it's about the const
[20:14] <ubitux> i think you have char *const *buf or something
[20:14] <ubitux> or just char **buf
[20:15] <hima> const
[20:15] <hima> ohh i okkk
[20:15] <ubitux> or you can just drop the const
[20:16] <hima> i added the const corrects it..stupid mistake :|
[20:28] <akira4> ubitux, I've attached the revised patch to the mailing list thread. I am getting some error when trying to rsync the fate-suite so couldn't add the stl file
[20:28] <ubitux> akira4: i saw that
[20:28] <ubitux> you can workaround it actually
[20:28] <akira4> really?
[20:28] <ubitux> akira4: try to mkdir -p /tmp/fake-fate-suite/sub
[20:28] <ubitux> copy the sample in the directory
[20:29] <ubitux> then make fate-sub-stl GEN=1 SAMPLES=/tmp/fake-fate-suite/sub
[20:29] <ubitux> (assuming you created that rule
[20:29] <ubitux> /tmp or wherever you want actually
[20:29] <ubitux> you get the idea
[20:29] <akira4> got it.
[20:31] <akira4> is the identation and style problem solved or should I do it again?
[20:32] <ubitux> i'll have a look later
[20:32] <akira4> sure.
[20:33] <ubitux> akira4: you still lack spaces around operators
[20:33] <ubitux> <space>+=<space>
[20:33] <ubitux> <space>=<space> ...
[20:33] <ubitux> etc
[20:33] <ubitux> while<space>(
[20:34] <ubitux> <space>==<space>
[20:34] <akira4> is there some way I could run a test for checking this?
[20:34] <ubitux> not sure if patcheck does that
[20:34] <ubitux> the indent in the "if (pts_start != AV_NOPTS_VALUE) {" block is wrong
[20:35] <akira4> okay. I'll redo it.
[20:35] <ubitux> len=0 and len>0 are wrong as well
[20:35] <akira4> you wouldnt mind if it gets a little delayed right? My midterms are going on
[20:36] <ubitux> i have no problem with that
[20:36] <akira4> alright. I'll fix it. thanks
[20:42] <cone-574> ffmpeg.git 03Omer Osman 07master:b01a2204b5cf: libfdk-aacdec: Enable Decoder Downmix including Downmix Metadata Support
[20:42] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:5a1aa559054b: Merge commit 'b01a2204b5cff7bb920f42fda1bb0103f450fe93'
[20:42] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:e18fc35a07f4: avcodec/libfdk-aacdec: use av_feeep() to avoid leaving stale pointers in memory
[20:52] <cone-574> ffmpeg.git 03Omer Osman 07master:66e9f8395362: libfdk-aacdec: Enable Dynamic Range Control Metadata Support
[20:52] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:45fed258ee6a: Merge commit '66e9f839536238945fbfe9d2041b6891cb150e45'
[21:21] <cone-574> ffmpeg.git 03Vittorio Giovara 07master:bae557edcea9: dump: display codec tags when available
[21:21] <cone-574> ffmpeg.git 03Michael Niedermayer 07master:0b0d47e4b21e: Merge commit 'bae557edcea996328e8ff48b9e074a4210f7e6b4'
[22:17] <cone-574> ffmpeg.git 03Mika Raento 07master:75c8d7c2b497: hlsenc.c, segment.c: propagate defaults to mpegts
[22:57] <hima> can anyone help me with this error http://fpaste.org/143016/35793831/ in this code http://fpaste.org/143015/13579342/ (kate format demuxer)
[23:00] <ubitux> hima: pts are 64 bits
[23:02] <hima> ohh return type ok changing that
[23:02] <J_Darnley> And if you haven't seen them yet, use int64_t or uint64_t
[23:03] <J_Darnley> instead of long.
[23:04] <hima> yeah done thankyou
[23:07] <ubitux> hima: get_pts_start and get_pts_end function looks very much alike
[23:07] <ubitux> you should refactor them
[23:08] <hima> okay doing it. i calculated duration in read_header so okay will make that change
[23:09] <ubitux> what if the timestamps are not on the same line as the event
[23:09] <ubitux> does it work?
[23:09] <ubitux> your probe function use strcmp functions for 1 char, just compare directy with the character instead
[23:09] <hima> yes
[23:09] <hima> find=strstr(ptr,"event");
[23:09] <hima> while(strcmp(find,"\n")==0 || strcmp(find," ")==0)
[23:09] <hima> find++;
[23:10] <ubitux> ok
[23:10] <hima> its a while statement and the pointer goes on increasing
[23:10] <hima> while it gets a \n or a " "
[23:11] <ubitux> but you get only one line at once
[23:11] <ubitux> and this is the probing
[23:11] <ubitux> not the read_header function
[23:11] <hima> yes so suppose its event \n \n \n x:y:z -> p:q:r
[23:12] <hima> so it will run untill it finds the timestamp
[23:13] <hima> and the sample for which u asked me to make it for minimal.kate there was no such ambiguity there
[23:16] <ubitux> i think that code might crash if you add a line return after event {
[23:16] <ubitux> or just not work
[23:16] <hima> there is no { after event
[23:17] <hima> http://fpaste.org/143022/41358062/
[23:17] <ubitux> ok
[23:17] <hima> umm the sample did not have a { after event
[23:17] <ubitux> what if you add a line break after the first "event"?
[23:17] <hima> hm
[23:18] <hima> line break you mean \n ?
[23:19] <hima> find=strstr(ptr,"event"); here now find has the rest of the string after event
[23:19] <hima> while(strcmp(find,"\n")==0 || strcmp(find," ")==0)
[23:19] <hima> find++;
[23:20] <ubitux> events can have { }
[23:20] <hima> this takes care that we skip the line breaks and spaces
[23:20] <hima> you mean event{ and then timestamp?
[23:20] <ubitux> http://git.xiph.org/?p=users/oggk/kate.git;a=blob;f=examples/kate/z.kate;hb=HEAD
[23:22] <hima> sorry i did not see that example the one you gave me did not have
[23:22] <hima> http://www.filewatcher.com/p/libkate_0.3.7.orig.tar.gz.728239/libkate-0.3.7/examples/kate/minimal.kate.html
[23:22] <hima> i will make the change then
[23:22] <ubitux> look at http://git.xiph.org/?p=users/oggk/kate.git;a=tree;f=examples/kate;hb=HEAD
[23:23] <ubitux> i'm just asking to parse the events, and get the text and timestamps out of them
[23:23] <ubitux> so you ignore the rest
[23:23] <ubitux> but they must all be supported
[23:23] <wm4> oh god
[23:23] <wm4> thus format looks almost as bad as ASS
[23:23] <wm4> *this
[23:23] <ubitux> wm4: haha yeah kinda
[23:23] <ubitux> wm4: actually, more painful to parse
[23:23] <hima> yeah i get it i will make the change for including the { after event then
[23:25] <J_Darnley> ubitux: of course it is, it is ogg!
[23:25] <hima> ubitux after including that should i submit this patch in the mailing list?
[23:29] <ubitux> you can do that anytime
[23:29] <ubitux> but i believe there is still work to do
[23:30] <hima> yeah please tell me.
[23:30] <ubitux> then start fixing what we said here
[23:30] <ubitux> we'll iterate from here
[23:31] <hima> okay i am fixing the existence of { after event first
[23:31] <hima> ubitux: bothering you again about the application
[23:32] <hima> are we supposed to propose any idea ?
[23:32] <hima> as there is a section in the format of the application for tasks and you timeline
[23:32] <hima> as you plan to do it
[23:32] <ubitux> there are a lot of work on subtitles stuff
[23:32] <ubitux> the final goal is to get a proper (at least text) subtitles support in ffmpeg
[23:33] <ubitux> and that includes having them in libavfilter for hardsubbing
[23:34] <hima> okay so this would be our goal if we qualify for OPW?
[23:34] <ubitux> yes
[23:36] <hima> ok thanks
[23:40] <hima> ubitux in this example there is almost a nested loop of { and its not always "event" do i include that kind. or just a simple kind where there would be event { ?
[23:41] <hima> http://git.xiph.org/?p=users/oggk/kate.git;a=blob;f=examples/kate/kate.kate;h=da025724817b96d7bc69a824bdd032c76309eced;hb=HEAD
[23:41] <ubitux> i don't see anything textual you could extract here
[23:41] <ubitux> it should not break as invalid data
[23:42] <ubitux> but no recognized event should come out of it
[23:45] <hima> hm i want to know like in the minimal.kate there was only event, but inthese examples there is motions {}curve{} points{} in a kind of nested fashion
[23:45] <ubitux> skip them, properly.
[23:45] <hima> okay
[00:00] --- Sat Oct 18 2014
More information about the Ffmpeg-devel-irc
mailing list