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

[burek]

[00:03] <cone-774> ffmpeg.git 03Carl Eugen Hoyos 07master:985e93a86518: Do not fail for mixed interlaced / non-interlaced YUV4MPEG streams.
[00:35] <teratorn> if im generating synthetic audio/video frames for testing, what timestamp-related invariants/constraints should I adhere to in order to keep the muxer happy interleaving the packets?
[00:36] <teratorn> oh, err, I meant to ask on #ffmpeg :/
[00:58] <tg2> anybody know where to start looking to override the -RE
[01:00] <tg2> to set it more than 1:1?
[01:09] <tg2> rate_emu ffmpeg.c line 1642 ?
[01:11] <saste> tg2: what's your final goal?
[01:12] <tg2> the end goal is to render an mp4 being written to disk to flv so it can be streamed while it is encoding
[01:12] <saste> tg2: what's wrong with -re?
[01:12] <tg2> can it be made variable?
[01:12] <saste> no
[01:13] <tg2> if (rate_emu) {
[01:13] <tg2> 01643             int64_t pts = av_rescale(ist->pts, 1000000, AV_TIME_BASE);
[01:13] <tg2> 01644             int64_t now = av_gettime() - ist->start;
[01:13] <tg2> 01645             if (pts > now)
[01:13] <tg2> 01646                 usleep(pts - now);
[01:13] <tg2> 01647         }
[01:13] <tg2> seems quite easy to override
[01:13] <saste> sure it could be extended, but we need at least a meaningful use case
[01:13] <tg2> say you wanted to control the speed of encoding
[01:13] <tg2> for resource reasons
[01:13] <saste> usually you can control that at the OS level
[01:14] <tg2> hm
[01:14] <saste> e.g. setting the niceness level
[01:14] <tg2> yeah you can do that
[01:14] <tg2> the goal actually isn't to save rousrces
[01:14] <tg2> since the main encoding process is going as fast as it can
[01:14] <saste> which is a more general approach (can be applied to all processes)
[01:14] <tg2> this is only doing a streamcopy of the mp4
[01:14] <tg2> into flv
[01:14] <tg2> basically rewrapping it
[01:14] <saste> -re is usually used for streaming
[01:14] <tg2> yea
[01:14] <tg2> to simulate a live stream
[01:14] <tg2> but if it was variable
[01:15] <tg2> you could make -re 1.0 by default
[01:15] <tg2> and assigning any other value
[01:15] <tg2> would give you realtime * that value
[01:15] <tg2> in input speed
[01:15] <tg2> this works very well for throttling
[01:15] <tg2> for example, the main encoding goes about 10x realtime
[01:15] <tg2> so 230~fps
[01:15] <saste> tg2: patches are welcome, or open a ticket and discuss
[01:16] <tg2> ok great
[01:16] <tg2> i'll write it up and test it first
[01:16] <tg2> it should be nondestructive in the sense that anybody using -re now will see no difference
[01:16] <saste> nice
[01:16] <tg2> the logic is quite simple
[01:16] <saste> tg2: yes
[01:16] <tg2> change the argiment parse
[01:16] <saste> if you have a meaningful use case it should be fine
[01:16] <tg2> and change the rate_emu to be non-boolean
[01:16] <tg2> as far as I can see
[01:16] <tg2> this is the only place it is used
[01:17] <saste> tg2: but you need a separate option
[01:17] <tg2> -respd ?
[01:17] <tg2> or -refactor ?
[01:17] <tg2> -re -refactor 1.2 ?
[01:17] <saste> otherwise you break syntax and get many angry users
[01:17] <tg2> shouldn't you can just set it to 1.0 if omitted
[01:17] <tg2> that way it acts identical
[01:17] <saste> yes
[01:17] <tg2> ok so you mean make a second case for arg + argv
[01:18] <tg2> with the same switch
[01:18] <tg2> hmm
[01:18] <saste> uhm no i don't think that would be possible
[01:18] <saste> you need a separate option
[01:18] <saste> then -re code will wrap around the new option (will set a specific value)
[01:18] <tg2> ok
[01:19] <saste> we will guide you on ML once you have a working patch
[01:19] <tg2> great
[01:22] <tg2> another quick question, if you will
[01:22] <tg2> actually nvm I'll do some more research first ;)
[01:22] <tg2> thanks
[02:21] <ulatekh> Hello!  I submitted a bug-fixing patch to the mailing-list 6 days ago, but no one commented on it.  Is there anything else you need me to do?  See http://article.gmane.org/gmane.comp.video.ffmpeg.devel/158184
[02:22] <Compn> ulatekh : dunno who checks makefile stuff
[02:22] <Compn> cehoyos does sometimes 
[02:23] <ulatekh> I just didn't want my bug fix to get lost.  And cehoyos seems to have his hands full :-)
[02:24] <Compn> hes a busy guy
[02:25] <ulatekh> Should I just leave my fix to its fate, then?
[02:26] <Compn> 6 days old?
[02:26] <Compn> ffmpeg docs say wait 2 weeks for reply, then ping
[02:26] <Compn> :)
[02:26] <ulatekh> OK...there was a lot to read, I must have missed that...I'll ping later...thanks
[02:26] <Compn> we are all on volunteer time here :)
[02:26] <Compn> no problem
[02:26] <Compn> sorry i cant review, i have no clue ...
[02:27] <Compn> barely have my head screwed on
[02:27] <ulatekh> Still, it's a shame...I'm like a rash on the open-source world.  I track down bugs in myriad projects when I find them, and try to submit fixes...and the vast majority of the time, all I get is apathy.
[02:28] <Compn> well
[02:28] <Compn>  you can ask one guy who works on it 
[02:28] <Compn> ah hes not online atm
[02:29] <Compn> ulatekh : try mailing diego biurrun
[02:29] <ulatekh> I'll mail him in 8 days, how's that.
[02:29] <Compn> or michaelni is the project admin around here too. he can review patches when hes active
[02:29] <Compn> lol ok
[02:34] <iive> actually I like the idea of creating libav<module>.<major_version>
[02:34] <iive> it would allow different api-breaking versions to be installed for the programs that need them. this includes forks too.
[02:34] <Compn> ulatekh : see, iive cares :)
[02:35] <iive> i'm cheap at talk :P
[02:35] <ulatekh> Right now, the --build-suffix option to configure gives you libav<module><buildsuffix>, and --progs-suffix does similarly for the executables.  They work fine, but the pkgconfig files needed a fix.
[02:35] <ulatekh> Nice to see someone cares...the apathy I get when trying to fix bugs in open-source code really does get me down sometimes.
[02:36] <ulatekh> iive: I've got git-master ffmpeg installed on my machine along with the ffmpeg from my dist's yum repos...they coexist just fine.
[02:37] <iive> does buildsuffix separate the include locations too?
[02:37] <ulatekh> Yes.
[02:37] <ulatekh> The only issue left unfixed (if my patch is considered) is the name of man pages.
[02:38] <iive> aha, so your patch is just fixing the pkgconfig files
[02:39] <ulatekh> Yeah, I couldn't figure out how to fix the man pages...the bash scripting was way too tense for me ;-)
[02:40] <ulatekh> I'm fixing the man pages in my rpm .spec file, post buildroot-install.
[02:56] <michaelni> ulatekh, your patch is missing a commit message
[02:57] <ulatekh> "Fix pkgconfig files when ffmpeg built with --build-suffix"?
[02:57] <ulatekh> I dunno, the commit message kinda writes itself... :-)
[02:57] <michaelni> it should start with something like build-sys: or configure:
[02:58] <michaelni> also it should list 
[02:58] <michaelni> what you tested this against
[02:58] <michaelni> it seems working fine on ubuntu
[02:59] <ulatekh> I tested it on Fedora Core 14, 16, and 17.
[03:00] <ulatekh> Sorry, I didn't know all the bureaucratic steps it takes to submit a bug fix.  It seems like most open-source projects treat "outsiders" like this...then the insiders check in something that breaks the code 8 ways from Sunday but that's OK.  (I finally gave up on mono-devel after a few such outrages.)
[03:01] <burek> ulatekh reminds me of me :)
[03:01] <burek> but it all boils down to the thing that people dont have enough of free time
[03:02] <ulatekh> Still, the fish jumped right in the boat, and filleted itself...all you have to do is eat it :-)
[03:02] <michaelni> burek, yep, time is much much more an issue than any bueacrat shit
[03:02] <burek> well, i now understand both sides so i dont get upset that much as before ^^
[03:02] <burek> still, some kind of improvement in that way would be welcomed :)
[03:03] <ulatekh> Mostly, it bugs me when I get the runaround & "insiders' can break code horribly and then give me the runaround on my attempts to fix the bug.  (That hasn't happened to me here, so don't take offense. :-)
[03:04] <michaelni> ulatekh, do you want to join become an insider and take over configure maintaince ?
[03:04] <burek> ulatekh, dont worry that much, if your fix helps anything, it will be applied sooner or later
[03:05] <ulatekh> I'd have a HUGE learning curve to take over something like that.
[03:06] <ulatekh> My frustration with ffmpeg is that the code is so persistently undocumented.  I've tried to trace bugs before, and have encountered nothing but pages and pages of undocumented god-knows-what.
[03:06] <burek> we lack the time to document it while coding stuff
[03:06] <burek> and people to document it after the thing has been coded
[03:06] <burek> consider constant radical changes here and there :) and you get the idea why is it so :)
[03:07] <michaelni> if everyone who didnt understand something would document it once he does figure it out then docs should improve alot
[03:07] <ulatekh> I must say, I completely reject the idea that "there's no time to document".  Documentation SAVES time by reminding you what the heck you were thinking when you wrote it...and telling others what you were thinking when they try to join in.
[03:08] <burek> I agree with you, but how to make the developers agree with you too? :)
[03:08] <burek> their todo lists are scary
[03:09] <ulatekh> I don't know.  My 20-year career has been a nightmare, and lack of programmers commenting their code is the biggest reason.
[03:10] <Compn> ulatekh : so document one file
[03:11] <Compn> :P
[03:11] <Compn> no ones stopping you from adding comments to code
[03:11] <Compn> what i'm tired of is people who stop by our community for one day (or a week tops) and complain about the code, then never return
[03:11] <Compn> its like, put up or shut up
[03:11] <burek> Compn, i believe the idea he is standing behind is for developers to document their own code :)
[03:11] <Compn> and the developers say no.
[03:11] <ulatekh> Well, knowing my patches might actually get applied could convince me it's worth my time...and yes, burek, I'm talking about developers documenting their own code.
[03:12] <ulatekh> @compn: and thus my career is a nightmare.
[03:12] <ulatekh> I'll never understand the "no to documentation" mentality if I live to be 1000.
[03:13] <ulatekh> And as far as me adding comments to ffmpeg's code...I'd have to understand it first.  And the lack of any documentation is an insurmountable barrier.  Plus, I have to wonder if anyone on the other side will even care if I do something like that.  Like I said earlier, my usual experience with submitting fixes in the open-source world, is apathy.
[03:14] <Compn> uh oh
[03:14] <Compn> no offense
[03:14] <Compn> but i am detecting open source troll
[03:14] <Compn> my warning flags have gone up
[03:15] <ulatekh> "open source troll"?
[03:15] <Compn> yes
[03:15] <ulatekh> Define?
[03:15] <Compn> comparing open source world to commercial software world comes next
[03:15] <ulatekh> I hate commercial software.  I run it as little as possible.
[03:16] <Compn> oh good, then i was wrong :)
[03:16] <burek> wait Compn, the guy has got a point
[03:16] <burek> no need to flame him
[03:16] <Skyler_> the documentation could be improved in many places, patches are probably welcome
[03:16] <Compn> patches are always welcome :)
[03:16] <Compn> i got a better one
[03:16] <ulatekh> Are you suggesting I'm somehow anti-open-source?  Dude, Google my username...I'm like a rash all over the open-source world.  Mostly I get ignored, but I'm there in the devel mailing lists.
[03:16] <Compn> ulatekh : what code confuses you ?
[03:16] <michaelni> ulatekh, I will apply the pkgconfig suffix patch, i just want to test it a bit more
[03:17] <Skyler_> however video/audio coding has an extra catch that generally people are expected to understand the format before reading the code (unless it's a format where there's no documentation at all, like some proprietary thing), so often it won't document things that are 'obvious' to someone who knows how the format works
[03:17] <Compn> ulatekh : i can almost guarentee someone will comment code that you say is hard to understand :)
[03:17] <ulatekh> @michaelni: Awesome.  All I really wanted was feedback.
[03:17] <Skyler_> e.g. an h264 decoder won't explain the h264 spec
[03:17] <Compn> h264 spec wont explain h264 :P
[03:17] <Compn> ehe
[03:17] <Skyler_> Pfffff
[03:18] <ulatekh> Well, it'd help if e.g. the h264 decoder would explain how parts of the code relate to the spec...when I'm trying to track down a specific bug, I'd like some idea of what the code is doing, so that I don't necessarily have to be an expert in the codec to track the issue I'm dealing with.
[03:18] <Skyler_> yeah, that would help
[03:18] <Compn> Skyler_: i dont see many copyrights in h264*
[03:18] <Compn> hmm i thought someone just added specs to one of the decoders
[03:18] <Compn> but i dont know which one
[03:19] <Compn> well , not 'just' but maybe 2 yrs ago
[03:19] <burek> :)
[03:19] <burek> see what i mean about free time :D
[03:19] <burek> people loose the sense of time coding ffmpeg :)))
[03:20] <ulatekh> Recently I submitted ticket #2190, while I was trying to get raw video packaged so that kdenlive would be able to import it.  Bless cehoyos for knowing what to look for...I would have never been able to find what he did.
[03:20] <Compn> i barely know what date is today :\
[03:20] <Compn> ulatekh : its a lot of code to memorize :)
[03:21] <ulatekh> @compn: for an example of code that confuses me...MPEG 1/2 encode.  One thing I've wanted in ffmpeg for like forever is support for soft telecine, i.e. giving it a 24000/1001 fps video and getting it soft-telecined to 30000/1001.  And being able to transcode soft-telecined video w/o it getting mucked up.  But digging through the source code, I have no idea what is doing what or why, so I get nowhere.
[03:23] <Compn> ulatekh : ehe, ffmpeg -vf mp=telecine or =softskip 
[03:23] <ulatekh> mpeg2enc from the mjpegtools project does a GREAT job of converting analog video to mpeg1/2, but it doesn't do 2-pass encoding, so I'd like ffmpeg to transcode my soft-telecined video so that I can achieve my desired bitrate (i.e. first encode video with mpeg2enc at the maximum bitrate).
[03:25] <ulatekh> If it finally got implemented, that's great...the last time I scoured the Net for how to do that with ffmpeg, what little info I could find seemed to suggest that most ffmpeg developers were non-U.S. and thus didn't care to spend time on soft-telecine.  And last week or so, I was on the #ffmpeg IRC channel, discussing soft-telecine with michaelni, and he didn't seem to know it had been implemented...
[03:26] <ulatekh> In any case, soft-telecine was an example of something I would have been willing to try to implement, if I could understand the source code at all.
[03:27] <ulatekh> And hey, maybe this is a case of "coming home from a bad day at work and kicking the dog"...the programmers ruining my life right now are the ones I have to deal with through my job ;-)
[03:28] <cone-874> ffmpeg.git 03Steven Boswell II 07master:6289a8296a89: build-sys: Fix pkgconfig files when ffmpeg is built with --build-suffix
[03:28] <ulatekh> Hey, my faith is restored partially...nice :-)
[03:29] <ulatekh> Tell you what...let me go get a beer & let's see if I stop whining so much LOL
[03:29] <Compn> michaelni was the one who added mplayer filter support
[03:29] <Compn> but maybe soft-telecine and telecine are different things that i'm confusing ...
[03:30] <ulatekh> Based on what I'm reading in https://ffmpeg.org/trac/ffmpeg/ticket/1782 it seems ffmpeg _does_ support it now.  So...hell yeah!
[03:32] <Compn> yeah, michaelni works hard for ffmpeg :)
[03:33] <ulatekh> My big forays into open-source programming tend to happen when I have time and energy, i.e. when I'm unemployed.  While employed, all I have time/energy for is supplying bug fixes for the stuff I run into while trying to do what I want to do.
[03:36] <ulatekh> y4mdenoise (i.e. http://mjpeg.cvs.sourceforge.net/viewvc/mjpeg/mjpeg_play/y4mdenoise/ ) happened during a nasty period of unemployment.
[06:08] <burek> oh im in gmt+1 so it counts more
[06:08] <burek> :)
[06:16] <burek> ok it works now :)
[06:16] <burek> michaelni, please let me know if something doesn't work as expected, so i can fix it
[09:37] <creep> hi
[09:37] <creep> i have an mkv file taht ffplay hangs in the middle
[09:38] <creep> if a specific part is skipped over, then it will play ok again
[10:00] <wm4> did ffmpeg stop extracting cover art images from .aac?
[10:01] <wm4> (using ID3v2)
[10:01] <wm4> it works with an older version, but not recent git
[10:36] <wm4> cehoyos: what the fuck?
[10:38] <wm4> I guess I'll post a useless paste of ffplay output on all tickets if it makes you happy
[10:39] <wm4> even though it's completely useless, and any developer attempting to reproduce this problem wouldn't get anything out of it (other than wasting his time reading useless crap)
[10:39] <cehoyos> wm4: Only paste ffplay output if the problems are not reproducible with ffmpeg, see http://ffmpeg.org/bugreports.html
[10:39] <cehoyos> And please do not forget your newer tickets
[10:39] <wm4> what's the point?
[10:40] <cehoyos> I don't understand.
[10:40] <wm4> I've provided all information needed to reproduce the problem
[10:42] <cehoyos> I disagree: Either provide the failing ffmpeg command line together with complete, uncut console output (ffplay command line if the problem only affects or is only reproducible with ffplay) or provide minimal source code that allows to reproduce the problem if it is neither reproducible with ffmpeg nor ffplay
[10:44] <wm4> it's an illusion to think that simple ffmpeg or ffplay usage with no interaction could show some of these problems
[10:44] <wm4> or that people would actually bother writing complicated test programs
[10:45] <cehoyos> If this is the case (this is very unusual over the total number of tickets - and issues - ever opened) then please take the time to explain why the problem is not rerproducible with ffmpeg (the application): Very often, this explanation was already sufficient to solve the problem for the reporter
[10:52] <wm4> ffmpeg fails to inject an attached picture in the packet stream when seeking before the start of the file - in libav it works
[10:53] <wm4> cehoyos: how would you report this issue?
[10:54] <cehoyos> Apart from the fact that I don't understand it (and I suspect you don't mean ffmpeg but FFmpeg): What about source code that allows to reproduce this? (I don't think this was ever reported.)
[10:54] <cehoyos> Does this correspond to one of the tickets you opened? Which one?
[10:54] <wm4> the only source to reproduce this is my mplayer fork
[10:55] <wm4> not yet
[11:02] <nevcairiel> wouldnt it be better to announce the machines that have newly joined the group of failed/idle machines?
[11:10] <divVerent> wm4: one idea to make a test case:
[11:11] <divVerent> would it be viable to edit ffmpeg.c to make the issue visible? e.g. a debug print when getting the picture?
[11:11] <divVerent> ffplay.c, actually
[11:36] <cehoyos> bcoudurier, TimNich: I sent a patch that writes the fiel atom independently of the codec_id. Is there anyhting I miss? Ie, should the atom not be written for some codecs?
[11:38] <wm4> cehoyos: is #2010 ok now
[11:38] <cehoyos> still downloading...
[12:04] <michaelni> burek, i think the duron box is too slow for a dumb 24h threshold
[12:29] <ubitux> hey
[12:30] <ubitux> please tell Paul i don't mind any change to showspectrum; i'll review history when i come back, if something is wrong i'll do what's necessary
[12:32] <cone-454> ffmpeg.git 03Carl Eugen Hoyos 07master:b45a3e167f49: Map the interlaced flag of yuv4mpeg streams to AVCodecContext->field_order.
[12:35] <wm4> so how can you set arbitrary avopts with the ffmpeg frontend?
[12:35] <cehoyos> ubitux: If you have time, there are still two patches in ticket #2144
[12:36] <wm4> or rather, how do you know where they end up
[12:45] <ubitux> cehoyos: i thought i "reviewed" them
[12:47] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/137682.html http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/137684.html http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/137686.html
[12:47] <cehoyos> ubitux: Did you review this one? http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/157781/focus=157860
[12:48] <ubitux> oh last version, will look
[12:49] <cehoyos> I did not apply 3/3 because I thought it might be better to apply 2/3 first
[12:50] <ubitux> yep sure
[13:19] <wm4> cehoyos: do you still have any tickets reported by me on your close-soon list?
[13:20] <ubitux> http://superuser.com/questions/545329/automate-running-a-program-when-input-volume-loudness-crosses-a-threshold  would be nice to script this with ebur128 filter
[13:22] <wm4> oh right, ticket 2002
[13:22] <wm4> but how the hell do you demonstrate a bandwidth issue
[13:22] <wm4> maybe there's a program that can measure network bandwidth usage of a single program by playing ld_preload tricks?
[13:23] <cone-454> ffmpeg.git 03Diego Biurrun 07master:76d90125cdc0: vf_hqdn3d: x86: Add proper arch optimization initialization
[13:23] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:0d13a7b786b9: Merge remote-tracking branch 'qatar/master'
[13:23] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:d593f2b2416f: avfilter/x86/vf_hqdn3d_init: fix author attribution & project name
[13:23] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:6726fb653320: avfilter/vf_hqdn3d.h: restore author attribution, history and project name
[14:04] <DEATH> Hi, I'm having some issues building FFmpeg 1.1.1 on MinGW
[14:05] <DEATH> libavcodec/x86/dsputil_mmx.c: In function 'dsputil_init_mmx':
[14:05] <DEATH> libavcodec/x86/dsputil_mmx.c:2309:14: error: 'gmc_mmx' undeclared (first use inthis function)
[14:05] <DEATH> libavcodec/x86/dsputil_mmx.c:2309:14: note: each undeclared identifier is reported only once for each function it appears in
[14:06] <DEATH> Configure line:
[14:06] <DEATH> ./configure --disable-everything --enable-decoder=aac --enable-shared --disable-swscale --disable-network --disable-avdevice --disable-postproc --disable-avfilter --disable-avformat --disable-debug --enable-runtime-cpudetect --disable-swresample --disable-ffprobe --enable-decoder=mp3float --enable-decoder=vorbis
[14:06] <DEATH> Goes away with --disable-mmx but that appears to also kill all CPU specific optimizations, configure shows SSE and such being all disabled after appending --disable-mmx
[14:11] <michaelni> DEATH, cant reproduce this (linux)
[14:23] <cehoyos> wm4: Regarding 2002: You don't have to explain why it makes sense not to request all streams. Just add the console output and explain how ffmpeg should know which stream you want to receive.
[14:57] <cone-454> ffmpeg.git 03Nicolas George 07master:55910e18948d: lavd/alsa: simplify reordering functions definition.
[15:30] <saste> wm4?
[15:30] <wm4> saste: ?
[15:30] <saste> wm4, ping on my lavf/http cookie patch
[15:31] <saste> that should address the first issue
[15:31] <wm4> saste: oh ok... I don't follow the ML
[15:33] <wm4> saste: I think that's not really ideal... IMO it should always return with an error if an error happened, instead of silently ignoring it
[15:33] <wm4> at least on OOM
[15:33] <saste> wm4, that's unrelated
[15:33] <wm4> but then I don't know what ffmpeg's policy is on OOM issues
[15:34] <saste> yes and i don't like how errors are handled there
[15:34] <saste> but at least it avoids the (null)
[15:34] <wm4> hm looks like I git reset --hard'ed the patch I wrote for this
[15:35] <cone-454> ffmpeg.git 03Stefano Sabatini 07master:6032a1c977cc: ffplay: extend doxy for audio_decode_frame()
[15:35] <cone-454> ffmpeg.git 03Stefano Sabatini 07master:fd6b6efbd212: lavfi/crop: fix help message for the keep_aspect option
[15:35] <cone-454> ffmpeg.git 03Stefano Sabatini 07master:6d9c21dc0e82: doc/indevs: add missing final dot in v4l2 option value description
[15:35] <wm4> saste: IMO get_cookies should return whether there is an error (and if there is, return from http_connect too), and the check whether cookies is NULL should be a separate if block entirely
[16:18] <cone-454> ffmpeg.git 03Marton Balint 07master:571ef42dd4eb: ffplay: dynamically allocate audio buffer
[16:18] <cone-454> ffmpeg.git 03Marton Balint 07master:4fd6e5af1e33: ffplay: fix order of setting show_mode
[16:18] <cone-454> ffmpeg.git 03Marton Balint 07master:5de3f724f152: ffplay: remember last window dimensions
[16:18] <cone-454> ffmpeg.git 03Marton Balint 07master:c5eab4bb70cc: ffplay: move up pause functions
[16:18] <cone-454> ffmpeg.git 03Marton Balint 07master:4ea7fbb2ec1a: ffplay: step to next frame if paused when seeking
[16:19] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:4be0b9109421: Merge remote-tracking branch 'cus/stable'
[16:27] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:cdc48860a8cb: h264: silence warning about array index being out of bounds
[16:38] <saste> wow we're fast ;-)
[18:51] <wm4> with ffmpeg I can't play concatenated ogg files, while I can with libav
[18:54] <Daemon404> i've been finding an increasing number of ffmpeg-only bugs recently...
[18:55] <wm4> the end is near
[18:57] <cehoyos> wm4: Please provide a sample
[18:57] <wm4> cehoyos: ffmpeg -i something.mp3 out1.ogg && ffmpeg -i something.mp3 out2.ogg && cat out*ogg > evil.ogg
[18:58] <wm4> cehoyos: I'll test with ffmpeg/avconv later and create a proper ticket just to make sure it's not my fault
[19:04] <cehoyos> wm4: Why do you think concatenating ogg files produces valid ogg files? (I don't know if it is valid.)
[19:04] <michaelni> wm4 works here
[19:05] <michaelni> even with changinhg samplerate & channels between the files
[19:06] <wm4> cehoyos: apparently it's similar to how ogg streaming can work
[19:06] <cehoyos> Daemon404: I find that impressive: Originally (at the time of the 0.7 and 0.8 release) there were around 50 regressions in the fork, perhaps 70. Later, there were a few hundred regressions, now, I can typically not even test new tickets with avconv because it often completely fails to process the given sample
[19:06] <cehoyos> And concerning ogg: The reason I asked for a sample is that FFmpeg supports a number of ogg samples (and features) that simply do not work with avconv
[19:07] <wm4> cehoyos: I tried it because I saw this: https://bugzilla.mozilla.org/show_bug.cgi?id=455165#c29
[19:09] <cehoyos> Yes, you are right: Chained ogg support is missing in avconv
[19:09] <Daemon404> impressive as it may be
[19:09] <Daemon404> it's true
[19:10] Action: Daemon404 goes to see if the known bugs have been fixed and queue some to report later
[19:10] <wm4> cehoyos: who's right? I said it works with libav but not ffmpeg
[19:10] <wm4> cehoyos: though I still haven't tested with ffmpeg/avconv directly
[19:11] <Daemon404> please provide full uncut output...
[19:11] <Daemon404> /troll
[19:12] <cehoyos> Yes, that is exactly what I mean!
[19:12] <wm4> anyway, I still don't know if libavformat handles ogg streams correctly now... does it still add new tracks on track changes with some ogg streams?
[19:21] <michaelni> wm4 it should only create new streams if theres no existing stream with matching codec
[19:21] <cone-454> ffmpeg.git 03Nicolas George 07master:23686c72e5ae: doc: update filter_design.txt to API changes.
[19:21] <michaelni> i tried vorbis in ogg and flac in ogg both work with chained oggs
[19:22] <wm4> michaelni: and how does the application know it has to switch to the new stream, and that the old stream won't have new packets?
[19:22] <michaelni> you have chained oggs that mix different codecs ?
[19:22] <wm4> probably not
[19:23] <wm4> well, the question is whether ogg internet radio streams do this
[19:23] <wm4> but they probably don't
[19:23] <wm4> what about vorbis extradata?
[19:23] <michaelni> will be sent in stream on the point where old swicthes to new
[19:24] <wm4> as part of the packet?
[19:24] <michaelni> yep
[19:25] <wm4> nice
[20:02] <wm4> hm I guess I accidentally tested seeking
[20:02] <wm4> which appears to behave slightly differently between ffmpeg and libav
[20:03] <wm4> ffmpeg still prints a weird message, though: "[NULL @ 0x8ade2c0]Invalid packet"
[20:03] <wm4> and reports a bogus length
[20:06] <wm4> oh wait, the bogus file length is only with libav
[20:08] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:0e9b9a6748aa: flacdec: skip in stream header packets
[21:28] <cone-454> ffmpeg.git 03Michael Niedermayer 07master:695af8eed642: h264: skip error concealment when SPS and slices are mismatching
[22:37] <cone-454> ffmpeg.git 03Carl Eugen Hoyos 07master:a60530e3ee1d: Require at least three frames to autodetect loas.
[00:00] --- Sun Feb  3 2013