[FFmpeg-devel-irc] IRC log for 2010-04-20

[irc at mansr.com]

[00:12:41] <ramiro> what's a good codec to test threading performance? I'm doing -vcodec mpeg4 -threads x -an -y output.mpg
[00:26:37] <bcoudurier> mpeg-2/mpeg-4/dnxhd I believe
[00:28:51] <ramiro> ok, I'll do fine with mpeg-4 then. any other suggestions? (like high bitrates or whatnot)
[00:29:22] <ramiro> hmm, GetProcessTimes seems to add up all threads' times, which is useless for testing this...
[00:33:57] <astrange> i don't think mpeg4 works
[00:34:15] <astrange> encoding does but not decoding
[00:34:35] <astrange> mpeg2 or dv/dnxhd can always use threaded decoding
[00:40:49] <bcoudurier> Yuvi are you around ?
[00:45:35] <ramiro> should I prefer threaded decoding or encoding?
[01:04:19] <Yuvi> bcoudurier: pong
[01:04:46] <bcoudurier> do you want to write nero chapters by default ?
[01:05:12] <Yuvi> I think so, they're in udta so should be ignored by anything that doesn't recognize them
[01:05:54] <bcoudurier> ok
[01:06:10] <bcoudurier> also I think the fields are better named tref_id
[01:06:21] <bcoudurier> also tref_tag will be needed
[01:06:32] <bcoudurier> because other tracks than chapter can ref
[01:06:48] <bcoudurier> make tref_tag generic if you see what I mean
[01:06:57] <Yuvi> sure
[01:07:14] <bcoudurier> I know that at least timecode track use it
[01:07:42] <bcoudurier> also the arg name is confusing, it is a MOVTrack, so name should be track and not mov
[01:08:03] <Yuvi> just copied the some other function ;)
[01:08:15] <bcoudurier> I figured :)
[01:08:38] <Yuvi> huh, the *one* function that does taht apparently
[01:12:50] <bcoudurier> btw I think I finished the ogg interleaving patch
[01:13:02] <bcoudurier> it was a bit more complicated because the page interleaving
[01:13:12] <bcoudurier> and I wanted to try to achieve the least overhead possible
[01:13:44] <bcoudurier> so I reworked the demuxer to buffer data without using an interleaving function
[01:14:47] <Yuvi> demuxer?
[01:14:53] <bcoudurier> err muxer
[01:15:10] <Yuvi> ah, nice
[01:15:12] <bcoudurier> one annoying thing is that without frame duration
[01:15:21] <bcoudurier> stream copy fails sometimes
[01:15:36] <Yuvi> too much stuff doesn't have frame duration to be able to rely on it
[01:22:41] <bcoudurier> well hopefully ogg won't go to mp4
[01:41:49] <CIA-7> ffmpeg: bcoudurier * r22916 /trunk/libavformat/mp3.c: Set AVFMT_NOTIMESTAMPS flag for mp3 muxer
[01:43:51] <bcoudurier> Yuvi, can you set PARSE_HEADERS in mkv demuxer ?
[01:43:52] <bcoudurier> for audio
[01:44:04] <bcoudurier> also I believe setting frame size to 1024 for aac is reasonable
[01:44:30] <bcoudurier> that should fix many stream copy errors
[02:20:58] <astrange> ramiro: try to measure wallclock time and not user time
[02:21:07] <astrange> it's better for measuring multiple threads
[02:30:11] <ramiro> what's wallclock time and how do I measure it?
[02:30:34] <ohsix> look at a clock on the wall
[02:30:51] <ramiro> I can't read the pointers =(
[02:30:54] <ohsix> or the realtime clock in your pc :>
[02:33:01] <ramiro> good night...
[02:33:53] <ohsix> i hope he didn't take that the wrong way
[02:36:06] <astrange> er, av_gettime is wallclock time
[02:36:08] <astrange> i guess that solves that
[03:02:17] <bcoudurier> Yuvi, are you dead ?
[03:23:26] <drv> the wiki small tasks page still has a task about making the GIF encoder use LZW
[03:23:30] <drv> i thought somebody wrote that already
[03:31:17] <bcoudurier> drv, yes it's been done
[03:38:28] <drv> ok, removed, thanks
[03:39:13] <bcoudurier> you're welcome
[04:11:39] <ohsix> :O https://launchpad.net/ubuntu/+source/ffmpeg/4:0.5+svn20090706-2ubuntu2.1
[06:47:26] <Dark_Shikari> http://rs162.rapidshare.com/files/377917771/Chase_sample.avi  <--when decoding this video with lavf, the last frame has a timestamp of -1.
[06:47:51] <Dark_Shikari> this probably shouldn't happen given that it's a CFR AVI.
[07:03:07] <av500> hmm, not here
[07:04:12] <av500> 9976ms with lavf
[07:05:08] <Dark_Shikari> both ffms and x264's lavf modules have this issue
[07:05:10] <Dark_Shikari> how did you measure it?
[07:05:47] <Dark_Shikari> oh, we're using reordered_opaque
[07:07:01] <Dark_Shikari> i.e. c->reordered_opaque = pkt->pts; before decode_video2
[07:07:15] <Dark_Shikari> then later on
[07:07:16] <Dark_Shikari> if( frame->reordered_opaque != AV_NOPTS_VALUE ) p_pic->i_pts = frame->reordered_opaque;
[07:07:51] <tetsuo--> ohsix is that still relevant?
[07:08:31] <ohsix> tetsuo--: just posted today
[07:09:00] <tetsuo--> i just noticed
[07:10:09] <tetsuo--> but if that is really based on the old version of ffmpeg those fixes could be backports from current head
[07:10:27] <ohsix> could, but the cves are from 2009 too
[07:11:41] <tetsuo--> good point
[07:13:07] <superdump> cves?
[07:16:01] <ohsix> superdump: numbers assigned for security issues http://cve.mitre.org/ the link i posted was a package update for ffmpeg in ubuntu
[07:16:16] <superdump> ah
[07:18:10] <peloverde> It looks like a lot of them reference branch commit numbers
[07:18:54] <tetsuo--> this is the patch: http://launchpadlibrarian.net/44838080/ffmpeg_4:0.5%2Bsvn20090706-2ubuntu2_4:0.5%2Bsvn20090706-2ubuntu2.1.diff.gz
[07:19:40] <ohsix> woo 2010
[07:20:49] <av500> Dark_Shikari: if you run it through the decoder, its another story, but what comes out of lavf seems ok to me
[07:21:16] <Dark_Shikari> av500: well the decoder shouldn't change pts...
[07:21:29] <Dark_Shikari> also, what's a good way to sum up a list of numbers in bash?
[07:21:38] <thresh> expr?
[07:21:53] <Dark_Shikari> I mean a very long list of numbers in a file, without +s
[07:21:56] <av500> excel?
[07:22:02] <Dark_Shikari> millions of numbers
[07:22:05] <Dark_Shikari> excel maxes at 2^16
[07:22:22] <Dark_Shikari> I could use sort and uniq and sum manually but there must be a better way
[07:24:19] <av500> Dark_Shikari: where is above src code line from?
[07:24:40] <Dark_Shikari> x264's lavf input module
[07:24:46] <Dark_Shikari> it's a very very trivial lavf/lavc wrapper
[07:25:00] <Dark_Shikari> that basically does things The Way You're Supposed To Write a Generic Lavf Wrapper
[07:25:16] <Dark_Shikari> ffms has the same problem, so I don't think it's our mistake
[07:25:20] <Dark_Shikari> since they were developed independently
[07:28:50] <hyc> re: summing numbers, use a (while loop; read x; sum=exprsum+x) < list_of_numbers
[07:29:06] <hyc> obviously that's just the vague idea
[07:29:35] <Dark_Shikari> is there a way to make that into a piped expression?
[07:29:38] <Dark_Shikari> i.e. app | sumnumbers
[07:29:46] <Dark_Shikari> i.e. is there a "while read standard input"?
[07:30:00] <ohsix> perl has @_
[07:30:01] <hyc> shell "read" only reads from stdin
[07:30:10] <hyc> so that's already what you want
[07:30:37] <Dark_Shikari> so I can do "while read x" ?
[07:30:41] <hyc> no
[07:30:52] <hyc> like I said, that was only the vague idea. you'll need to get the correct syntax yourself.
[07:31:03] <hyc> sounds like you need to spend some quality time with the sh manpage
[07:31:05] <ohsix> the ()'s matter too
[07:31:44] <Dark_Shikari> blegh
[07:31:53] <Dark_Shikari> anyways, already confirmed my results via manual summing with uniq/osrt
[07:31:55] <Dark_Shikari> *sort
[07:31:59] <Dark_Shikari> since it's like 8 different values
[07:34:55] <av500> Dark_Shikari: so frame->reordered_opaque comes back with -1?
[07:35:21] <CIA-7> ffmpeg: mstorsjo * r22917 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c):
[07:35:21] <CIA-7> ffmpeg: Revert svn rev 21857, readd first_rtcp_ntp_time in RTPDemuxContext
[07:35:21] <CIA-7> ffmpeg: In order to sync RTP streams that get their initial RTCP timestamp at
[07:35:21] <CIA-7> ffmpeg: different times, propagate the NTP timestamp of the first RTCP packet
[07:35:21] <CIA-7> ffmpeg: to all other streams.
[07:35:22] <CIA-7> ffmpeg: This makes the timestamps of returned packets start at (near) zero instead
[07:35:23] <CIA-7> ffmpeg: of at any random offset.
[07:35:58] <Dark_Shikari> av500: I think so.  let me make sure
[07:36:02] <Dark_Shikari> x264 actually does the following:
[07:36:06] <Dark_Shikari> if( frame->reordered_opaque != AV_NOPTS_VALUE )
[07:36:06] <Dark_Shikari>             p_pic->i_pts = frame->reordered_opaque;
[07:36:06] <Dark_Shikari>         else if( pkt->dts != AV_NOPTS_VALUE )
[07:36:06] <Dark_Shikari>             p_pic->i_pts = pkt->dts;
[07:36:12] <Dark_Shikari> i.e. if pts is invalid, it uses dts instead
[07:36:20] <Dark_Shikari> because AVI files return junk pts with lavf
[07:36:48] <Dark_Shikari> (sometimes, not sure if it's always)
[07:37:05] <av500> me "wrapper" uses dts
[07:37:11] <av500> my
[07:37:22] <Dark_Shikari> isn't that rather wrong?
[07:37:44] <av500> maybe, but I dont use the wrapper :)
[07:38:23] <Dark_Shikari> lol
[07:38:34] <Dark_Shikari> I suspect this is just an issue of packed b-frames
[07:38:42] <Dark_Shikari> and the resultant pts/dts munging
[07:39:48] <CIA-7> ffmpeg: mstorsjo * r22918 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c):
[07:39:48] <CIA-7> ffmpeg: Reset RTCP timestamps after seeking, add range start offset to the packets timestamps
[07:39:48] <CIA-7> ffmpeg: If these aren't reset, the timestamps make a huge jump when the next RTCP
[07:39:48] <CIA-7> ffmpeg: is received.
[07:39:49] <av500> for last frame I get from lavf:  dts/pts     9976/       0
[07:40:00] <Dark_Shikari> 0 sounds like a problem
[07:40:31] <Dark_Shikari> I really don't want to have to swap to haali's splitter for avi here
[07:40:40] <Dark_Shikari> lavf shouldn't suck this much
[07:42:50] <av500> who does handle packed B in lavf/c? the format or the decoder?
[07:42:54] <av500> ok, looks like lavf outputs the whole P+B frame
[07:43:08] <av500> well, its not lavf, lavf does not return -1
[07:43:31] <superdump> Dark_Shikari: look up munging on urbandictionary
[07:43:55] <av500> http://pastebin.com/LGgp2k6g
[07:43:59] <Dark_Shikari> "obfuscation"
[07:44:01] <Dark_Shikari> oh, munging, not munge
[07:44:02] <av500> this is what I get from lavf on this file
[07:44:06] <Dark_Shikari> LOL
[07:44:17] <Dark_Shikari> gotta love urbandict
[07:44:20] <superdump> mmm
[07:44:22] <superdump> :)
[07:45:41] <Dark_Shikari> av500: that's retarded
[07:45:52] <Dark_Shikari> wait. 599 packets?
[07:45:56] <Dark_Shikari> the video has 300 frames.
[07:46:30] <av500> yes, and a bunch of nocodes for the packed-bs
[07:46:37] <av500> all those 7 byte ones
[07:47:25] <Dark_Shikari> weee, more code outside of lavf to work around lavf deficiencies
[07:47:48] <av500> you want lavf to drop the nocode frames?
[07:48:18] <Dark_Shikari> lavf should never, ever, ever, ever, ever
[07:48:20] <Dark_Shikari> ever ever ever ever ever
[07:48:23] <Dark_Shikari> return non-monotonic pts after reorder
[07:48:24] <av500> ever?
[07:48:29] <Dark_Shikari> it is completely nonsensical
[08:02:54] <av500> Dark_Shikari: http://pastebin.com/feVVeWdA
[08:03:06] <av500> this is a printf from ffplay, pre and post decode_video2
[08:03:19] <av500> I dont see the ts going to -1
[08:03:48] <Dark_Shikari> isn't -1 AV_NOPTS_VALUE?
[08:04:18] <Dark_Shikari> or wait, that big thing is right
[08:05:05] <Dark_Shikari> either way regardless of the specifics, things are borken =p
[08:15:27] <av500> -9223372036854775808 is 0x800000000.... and is AV_NOPTS_VALUE
[08:20:39] <merbanan> av500: I'm in estonia now
[08:20:52] <superdump> ?
[08:21:02] <av500> merbanan: glad you made it :)
[08:21:08] <superdump> why?
[08:21:49] <av500> the ship made it through the ash cloud
[08:22:10] <superdump> i would think boats would be somewhat below the ash cloud
[08:23:25] <av500> sneaky ash cloud these days :)
[08:26:06] <thresh> you never know where it will strike next.
[08:27:49] <jai> lol
[09:45:00] <siretart> hi DonDiego
[09:58:07] <Dark_Shikari> google's resident village idiot on why they refuse to report bugs to ffmpeg
[09:58:10] <Dark_Shikari> 17:57 <@Dark_Shikari> you need legal approval to upload freely available video files?
[09:58:14] <Dark_Shikari> 17:57 <@Dark_Shikari> Even creative commons video files?
[09:58:16] <Dark_Shikari> 17:57 < fbarchard> yes
[09:58:19] <Dark_Shikari> 17:57 < fbarchard> yes
[09:58:21] <Dark_Shikari> 17:57 <@Dark_Shikari> Even public domain video files?
[09:58:24] <Dark_Shikari> 17:57 < fbarchard> yes
[09:58:34] <Dark_Shikari> "We'll complain about sync issues all day but we'll never upload any test samples or report any bugs!"
[09:58:42] <Dark_Shikari> fucking hell.
[09:59:55] <bilboed-pi> erf
[09:59:59] <bilboed-pi> google or youtube ?
[10:00:02] <Dark_Shikari> google
[10:00:21] <Dark_Shikari> also, this is the resident idiot who thinks you can measure audio quality with psnr
[10:00:49] <bilboed-pi> ...
[10:01:05] <Dark_Shikari> also, he did a vp8 - x264 comparison and screwed up in about 10 different ways, getting 10 contradictory results
[10:01:25] <bilboed-pi> was gonna ask, do they actually have any competent multimedia guy in house ?
[10:01:45] <Dark_Shikari> Sure, they have pascal, at yotuube at least
[10:01:48] <Dark_Shikari> but this guy is a complete moron
[10:02:00] <Dark_Shikari> worse than merely stupid, no common sense and an unwillingness to listen to people who know more than he does
[10:02:05] <Dark_Shikari> refuses to even learn
[10:02:33] <av500> Dark_Shikari: this comparison, where?
[10:02:41] <Dark_Shikari> not published, I just walked him through it over irc
[10:02:47] <Dark_Shikari> he managed to screw up everything from fps to luma levels
[10:03:14] <av500> VP8 fps is better than h264 luma level? :)
[10:03:26] <Dark_Shikari> every day I trust google less to do anything right
[10:03:32] <Dark_Shikari> it seems they've screwed themselves over by hiring idiots
[10:04:07] <av500> I guess all the google interview riddles are known by now :)
[10:04:49] <Dark_Shikari> 18:00 < Tjoppen> then just grab something from archive.org? they're bound to have something in the public domain
[10:04:53] <Dark_Shikari> 18:03 < fbarchard>  Tjoppen: thanks for the suggestion.  I'll bounce that off our lawyer, but I suspect no
[10:05:00] <Dark_Shikari> *headdesk*
[10:05:04] <av500> gee
[10:05:08] <bilboed-pi> ROFL :)
[10:05:08] <Tjoppen> heh
[10:05:10] <kierank> he is just paranoid
[10:05:13] <Dark_Shikari> no, he is stupid
[10:05:19] <Dark_Shikari> he has proven at least half a dozen times that he is a clueless retard
[10:05:32] <Dark_Shikari> who can be told something 20 times and still not even remember that you told him it
[10:05:58] <Tjoppen> lunch. I'll see how this unfolds later
[10:06:04] <Dark_Shikari> oh it'll unfold as usual
[10:06:06] <Dark_Shikari> he'll complain about bugs in ffmpeg
[10:06:07] <Dark_Shikari> report no bugs
[10:06:08] <Dark_Shikari> and then leave
[10:06:12] <Dark_Shikari> and then come back one week later and repeat the process
[10:06:16] <Dark_Shikari> until someone bans him
[10:06:18] <Kovensky> kind of unrelated: is there any audio metric other than 'sounds good' btw?
[10:06:22] <Dark_Shikari> PEAQ
[10:06:43] <Dark_Shikari> re audio quality, we literally got the xiph devs to tell him he was an idiot
[10:06:47] <Dark_Shikari> and he still ignored them
[10:07:15] <av500> you cant blame him for that :)
[10:07:40] <Dark_Shikari> well you know, they're only the developers of the best open source audio encoder
[10:07:44] <Dark_Shikari> but hey, what would they know
[10:14:43] <merbanan> yeah they are real audio noobs
[10:16:23] <superdump> the public domain / creative commons content thing is completely stupid
[10:17:08] <bilboed-pi> superdump, you mean that google guy wanting to go through lawyer to use it ? :)
[10:18:47] <bilboed-pi> Dark_Shikari, considering I couldn't find a single open-source/free implementation of PEAQ... I'm guessing nobody's using it :)
[10:20:08] <mru> who wrote the vorbis encoder?
[10:20:21] <av500> al gore?
[10:20:36] <mru> no, he invented the internet
[10:20:47] <av500> which he needed to spread vorbis!
[10:20:48] <bilboed-pi> that was on the first day
[10:20:55] <bilboed-pi> on the second day he wrote vorbis
[10:21:05] <j-b> on the third he wrote Linux ?
[10:21:21] <mru> and then he invented global warming
[10:21:44] <bilboed-pi> j-b, tss, he *conceived* Linus
[10:22:09] * bilboed-pi thought he invented global warming on sunday
[10:22:12] <j-b> bilboed-pi: how silly I am
[10:22:16] <bilboed-pi> :)
[10:23:19] <superdump> hang on... what day is it?
[10:27:01] <av500> 110
[11:54:09] <towolf> Hello, Attila Kinali has blocked my ISP HanseNet from accessing ffmpeg.org. It’s been three weeks. He told me the ban (some guy leeched samples, or something) would be lifted next time the server is rebooted, which might be no earlier than next year. What kind of network administration habits is this?
[11:55:20] <merbanan> towolf: you have to email him
[11:55:33] <merbanan> we have no power over the server
[11:55:58] <merbanan> and we need to protect our server against abuse
[11:56:11] <merbanan> or we might need to pay for the hosting
[11:59:04] <towolf> merbanan, i mailed him. he told me to wait for next reboot or use proxy and didn’t follow-up otherwise.
[11:59:31] <merbanan> ok
[12:00:10] <towolf> Isn’t it odd that someone might want to look at www.ffmpeg.org, but it only comes back with an error? HanseNet is not that small.
[12:00:39] <mru> complain to them
[12:00:53] <mru> tell them abusive customers are causing disruptions for everybody
[12:01:03] <mru> and suggest they do something about such people
[12:01:05] <jai> hmm
[12:01:07] <jai> elenril: ping
[12:01:08] <kierank> contact their abuse email
[12:01:20] <kierank> and get the time and ip of the abuser
[12:01:33] <towolf> kierank, why me? i’m impartial to abuse. i just want to pull from git repo.
[12:01:46] <elenril> jai: pong
[12:01:52] <towolf> kierank, how would i do that? that’s the job of the admin???
[12:02:05] <kierank> towolf, you could use mru's git if he doesn't have a problem with that
[12:02:07] <peloverde> towolf, there are plenty of mirrors of the git repo
[12:02:21] <jai> elenril: do you have any plans of adding uslt parsing to our id3 code :)
[12:02:22] <peloverde> mru's is actually better in many ways
[12:02:28] <towolf> peloverde, have a url?
[12:02:38] <elenril> jai: what's uslt ;)
[12:02:40] <peloverde> http://git.mansr.com/
[12:02:45] <towolf> peloverde, merci.
[12:02:54] <elenril> ah, lyrics
[12:02:59] <jai> elenril: stores lyrics without sync info
[12:03:17] <jai> elenril: fyi, https://roundup.ffmpeg.org/issue1772
[12:04:52] <jai> bbl
[12:16:47] <Kovensky> http://repo.or.cz/FFmpeg-mirror.git
[12:20:49] <BastyCDGS> greetings
[12:22:19] <Kovensky> saluton
[12:22:59] <thresh> The requested URL /FFmpeg-mirror.git was not found on this server
[12:23:28] <peloverde> siretart, Do you know if Canonical's MPEG protection licenses cover PPAs or just Ubuntu proper?
[12:23:31] <Kovensky> oh
[12:23:32] <Kovensky> git://
[12:23:33] <Kovensky> not http://
[12:23:57] <thresh> fatal: The remote end hung up unexpectedly :D
[12:26:15] <Kovensky> :V
[12:28:07] <DonDiego> Dark_Shikari: btw, frank barchard is also the guy who keeps top-posting every other time he posts to ffmpeg-devel..
[12:28:19] <siretart> peloverde: what MPEG protections are you talking about?
[12:28:38] <peloverde> I'm using "protection" as a euphemism for patent licenses
[12:29:16] <av500> hmm, where would a mortal find the sample file mentioned here: https://roundup.ffmpeg.org/issue1772
[12:29:17] <Kovensky> DonDiego: well, that's a perfect match for D_S's definition of barchard =p
[12:29:19] <iive> peloverde: somebody removed the wording "extortion" from ffmpeg site.
[12:29:43] <siretart> I have no inforamtion that canonical had anything mpeg related licensed
[12:30:12] <peloverde> I see them on the list of license holders at both Via and MPEG-LA
[12:30:21] <peloverde> thanks anyway
[12:30:50] <siretart> peloverde: do you have an url to that list?
[12:31:05] <av500> peloverde: do they ship something mpeg-la related in stock ubuntu?
[12:31:50] <peloverde> http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
[12:31:51] <av500> siretart:  http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
[12:32:24] <DonDiego> interesting
[12:32:35] <siretart> I'm... suprised
[12:32:50] <peloverde> I guess they aren't AAC licensees: http://www.vialicensing.com/licensing/AAC_Licensees.cfm
[12:32:58] <peloverde> though the Queen is
[12:33:03] <DonDiego> http://www.mpegla.com/main/programs/VC1/Pages/Licensees.aspx
[12:33:25] <DonDiego> http://www.mpegla.com/main/programs/M4V/Pages/Licensees.aspx
[12:33:26] <siretart> need to write the TB for clarification
[12:33:47] <siretart> DonDiego: when shall we create the 0.6 branch?
[12:34:02] <DonDiego> TB == ??
[12:34:16] <peloverde> av500, IIRC FFmpeg is in main, though not on the CD
[12:34:46] <DonDiego> siretart: i'd say any moment that fate turns green
[12:34:51] <siretart> TB == ubuntu technical board
[12:35:23] <DonDiego> right now i see quite a few tests failing, i'm not sure if they're supposed to fail or not
[12:35:42] <siretart> DonDiego: we don't need to take HEAD, we can also take  arevision where fate was green
[12:36:05] <kierank> [13:33] <@peloverde> though the Queen is --> lol
[12:36:46] <DonDiego> siretart: well, but the ogg and theora fixes went in just a short while ago
[12:37:01] <siretart> DonDiego: backportable...
[12:37:19] <DonDiego> peloverde: just to doublecheck: anything aac-related pending?
[12:37:26] <DonDiego> http://fate.multimedia.cx/index-v3.php
[12:37:39] <mru> right now one of the tests is failing on all big endian machines
[12:37:43] <peloverde> DonDiego, nope
[12:37:46] <siretart> hm. make: *** [regtest-mxf] Error 1 - on linux x86
[12:37:57] <mru> compiler?
[12:38:11] <DonDiego> ouch
[12:38:21] <DonDiego> mru: can you fix it? :)
[12:38:25] <peloverde> Once the branch is made I will run conformance again, but after the last AAC related commit it was passing
[12:38:36] <mru> DonDiego: I don't know what's wrong
[12:38:42] <mru> but it looks like something swscale related
[12:38:51] <mru> if you can fix that, I'll buy a beer
[12:39:00] <DonDiego> just one?
[12:39:01] <DonDiego> ;)
[12:39:13] <mru> for that, you can have two
[12:39:15] <DonDiego> if somebody can localize the failing revision..
[12:39:47] <DonDiego> also, i'm supposed to bisect a regression right now
[12:39:56] <siretart> well, TBH, this x86_32 / Linux / gcc svn 156187 (built 2010-01-22) looks like the only one I'd worry about remotely. The other fate regressions don't look like they're going to hit any debian architecture
[12:40:01] <DonDiego> but on hipl (work), not ffmpeg..
[12:40:17] <mru> did debian drop all big endian?
[12:40:17] <superdump> Dark_Shikari: i don't suppose you know of any algorithms that would be suited to identifying images that make use of digital zoom would you?
[12:45:06] <Kovensky> debian still works on ppc no? isn't ppc wrong-endian?
[12:45:39] <pengvado> superdump: fft?
[12:45:57] <peloverde> Dark_Shikari, do you know of any simple video editing software (ala Windows Movie Maker) for Windows that can export with x264?
[12:49:17] <siretart> Kovensky: you're right, I missed that line. seems the test 'mtv' is broken on powerpc: http://fate.multimedia.cx/index.php?test_result=54717668
[12:49:38] <mru> yes, that test fails on all big endian
[12:49:50] <siretart> is that intended or a bug?
[12:49:59] <mru> of course it's a bug
[12:50:16] <mru> we're not in the intentional breakage business
[12:50:24] <siretart> and how severe is it? what's exactly broken?
[12:50:44] <mru> I know only what the error message says
[12:51:03] <siretart> swScaler: rgb565le is not supported as input pixel format
[12:51:05] <siretart> hm
[12:56:35] <Quentar> Greetings, is there and option for ffmpeg to write PID file ? if not, would a patch be welcomed ?
[12:57:29] <av500> what for?
[12:58:07] * Kovensky wonders if libswscale still doesn't work on win64
[12:58:18] <kierank> Quentar: PID file?
[12:58:43] <Quentar> kierank: file with process id , I am trying to automate some streaming services using ffmpeg and pidfile would help greatly .
[12:58:44] <av500> ps | grep ffmpeg?
[12:58:51] <Kovensky> Quentar: ffmpeg $PARAMS & echo $! > /var/run/ffmpeg.pid && wait %%
[12:58:55] <kierank> oh that kind of PID
[12:59:21] <Kovensky> well, the wait is optional :>
[13:00:55] <Quentar> oh, thanks, I don't like bash that much, but I cannot definitely grep them cause there is a bunch of them running
[13:03:12] <BastyCDGS> one small question regarding AVFormatContext::duration
[13:03:34] <BastyCDGS> docs say in AV_TIME_BASE
[13:04:06] <elenril> Quentar: you should ask this kind of questions in #ffmpeg
[13:04:08] <mru> btw, pid files are inherently unsafe
[13:04:08] <BastyCDGS> the thing is that each frame is always 1/60th a second in IFF ANIM
[13:04:32] <BastyCDGS> can i just do a: s->duration += AV_TIME_BASE;
[13:04:41] <BastyCDGS> and at the end divide it by 1/60th at a second
[13:04:56] <BastyCDGS> for each FORM...ILBM chunk in IFF-ANIM (it's one frame)
[13:05:01] <Quentar> elenril: ok, I am sorry, but I also wanted to know if the patch for such a small thing would be ok/worth it
[13:05:51] <BastyCDGS> hey BBB how are u?
[13:06:26] <BBB> howdy
[13:06:30] * BBB needs coffee
[13:06:54] * BastyCDGS teleports a cup of coffee to BBB
[13:07:15] <BBB> I'll make some actual fresh :)
[13:07:16] <BBB> hi jai
[13:07:23] <BastyCDGS> heyho jai
[13:07:32] <av500> jai: how do I access the 1772 sample file?
[13:09:52] <BastyCDGS> jai or BBB, i have a small problem with setting duration...
[13:09:59] <BastyCDGS> I'm not clear about AV_TIME_BASE
[13:10:05] <Kovensky> also, I now know why my repo.or.cz link wasn't working
[13:10:09] <Kovensky> whoever made that repo on repo.or.cz typoed the project's name
[13:10:12] <BastyCDGS> in IFF-ANIM a frame is always 1/60th a second
[13:10:16] <Kovensky> and called it FFMpeg-mirror :V
[13:10:35] <BastyCDGS> just coding that for each FORM...ILBM chunk i add AV_TIME_BASE...
[13:10:41] <BastyCDGS> and at the end I want divide by 1/60th second
[13:11:15] <BastyCDGS> #define AV_TIME_BASE            1000000
[13:11:23] <BastyCDGS> this is 1 microsecond, right?
[13:13:31] <Kovensky> forgot the name
[13:13:40] <Kovensky> but it's 1/1000000th of a second :>
[13:14:30] <bilboed> microsecond
[13:14:58] * elenril throws http://en.wikipedia.org/wiki/SI_prefix at Kovensky 
[13:15:39] <BastyCDGS> for each frame i did a: s->duration += AV_TIME_BASE;
[13:15:45] <BastyCDGS> at the end s->duration /= 60;
[13:15:48] <BastyCDGS> should be fine then...
[13:20:27] <merbanan> bbl, of to the boat
[13:22:17] <Kovensky> time base math is weird :(
[13:23:15] <av500> but its a good excuse when you are late... :)
[13:23:28] <av500> ---sorry, wrong timebase...
[13:24:48] <BastyCDGS> ;)
[13:25:15] <BastyCDGS> well I've finished most of the chunk reading stuff
[13:26:43] <BBB> huh?
[13:26:49] <BBB> why do you want to set duration?
[13:26:55] <BBB> our iff demuxer does that already
[13:27:02] <BBB> you only should decode iff frames
[13:28:49] <BBB> oh, spyfeng, good timing ;)
[13:28:54] <BBB> we sent the same msg at the same time ;)
[13:31:12] <BastyCDGS> don't see a line where it sets the duration...
[13:32:04] <BastyCDGS> the iff decoder in libavformat (that's what I'm editing right now) doesn't handle IFF-ANIM
[13:32:15] <BastyCDGS> since it simply skips the FORM-ILBM chunks inside
[13:32:32] <peloverde> BBB, what's the status of ffmtech.org?
[13:32:53] <BBB> we're looking for a volunteer to write the website :(
[13:32:57] <BastyCDGS> i have added:
[13:32:59] <BastyCDGS> if ( AV_RL32(d)   == ID_FORM &&
[13:32:59] <BastyCDGS>          (AV_RL32(d+8) == ID_8SVX || AV_RL32(d+8) == ID_PBM || AV_RL32(d+8) == ID_ILBM || AV_RL32(d+8) == ID_ANIM) )
[13:33:11] <BastyCDGS> in static int iff_probe(AVProbeData *p)
[13:33:17] <BastyCDGS> so it recognizes IFF-ANIM
[13:33:30] <BastyCDGS> now I'm dealing with iff_read_header
[13:33:41] <BastyCDGS> i guess this func is called on very first read only
[13:33:51] <BBB> yes
[13:34:00] <BBB> probe is to see the type of file you're dealing with
[13:34:02] <BBB> mp3? avi? etc.
[13:34:13] <BBB> in this case, you're probing to see whether the file is iff
[13:35:07] <BastyCDGS> that's clear i already added the ID_ANIM stuff
[13:35:10] <BastyCDGS> as you see ;)
[13:35:14] <BastyCDGS> that isn't the problem
[13:36:09] <BastyCDGS> but i don't see a line in the iff stuff which does any duration calculation
[13:36:28] <BBB> I think many "game" demuxers don't do stuff like that, or seeking
[13:36:33] <BBB> it's more or less just a means to transcode it
[13:36:43] <BBB> I'd focus on decoding first, in libacodec/iff.c
[13:39:03] <BastyCDGS> do you think i should do a dryrun with the make test codec command after adding the codec?
[13:39:10] <BastyCDGS> with the stub decoder and then go on?
[13:40:01] <BBB> if you think it might break things, yes
[13:40:05] <BBB> but I don't think it'll break things
[13:40:09] <Kovensky> <+av500> but its a good excuse when you are late... :) <+av500> ---sorry, wrong timebase... <-- I wish my professors even knew what a timebase was :P
[13:40:15] <Kovensky> maybe the more math inclined ones might now, but...
[13:40:21] <BBB> BastyCDGS: just make sure it reads the proper chunks in the iff demuxer
[13:40:24] <BBB> then move on to the decoder
[13:40:25] * Kovensky is always late anyway :(
[13:40:30] <BBB> don't bother with timestamps too much for now
[13:40:33] <BBB> we can do that later
[13:40:37] <BBB> the task is to write the decoder ;)
[13:42:31] <Kovensky> yeah, timestamps...
[13:42:47] <Kovensky> I'll have some chatting to do later today about timestamp handling between demuxer and decoder :v
[13:44:52] <BastyCDGS> then it's probably the best way to simply check at the beginning in libavformat/iff.c if it's IFF-ANIM and then jump straight into the first FORM...ILBM sub chunk
[13:45:06] <BastyCDGS> and just add the new chunks
[13:45:11] <BastyCDGS> and go on to the demuxer
[13:45:25] <BastyCDGS> well that sounds a lot more easier than the approach I did for now
[13:45:32] <BBB> too complex, don't "jump", simply follow the existing structure of the demuxer
[13:45:40] <BBB> it already reads iff files
[13:45:44] <BBB> make it recognize iff/anim
[13:45:54] <BBB> then go into iff_read_packet() (I think that's what it's called)
[13:46:05] <BBB> change that function so it recognizes anim chunks, whatever they're called
[13:46:12] <BBB> and hand them to the demuxer
[13:46:19] <BBB> in iff_read_header(),set the correct CODEC_ID_
[13:46:23] <BBB> for the video stream
[13:46:27] <BBB> and that's all you need to do
[13:48:57] <BastyCDGS> investigating the code, it can't handle recursive IFF chunks
[13:49:28] <jai> hey there BBB
[13:49:28] <BastyCDGS> the structure of IFF ANIM contains a sub-FORM chunk
[13:49:54] <jai> av500: do you have access to incoming.mphq?
[13:50:12] <BBB> BastyCDGS: ok, so then try to make minimal changes so it handles recursive chunks for iff/anim
[13:50:22] <BBB> BastyCDGS: but don't "rewrite" the whole demuxer, that's generally not necessary
[13:50:24] <BBB> make small changes
[13:50:27] <av500> jai: I dont think so
[13:53:21] <BastyCDGS> i will make it recognize sub-FORM chunks and put a while into it that should to it
[13:53:37] <BastyCDGS> although I'd copy some of the code
[13:55:03] <BastyCDGS> av_get_packet(pb, pkt, iff->body_size);
[13:55:08] <BastyCDGS> does this call the demuxer?
[13:55:37] <BBB> no
[13:55:44] <BBB> you are in the demuxer now
[13:55:49] <BBB> libavformat/iff.c is the demuxer
[13:55:56] <BBB> it creates a packet to put the data in
[13:56:06] <BBB> and then reads the data into i
[13:56:07] <BBB> t
[13:57:33] <BastyCDGS> sorry meant does this call the decoder
[14:01:51] <jai> av500: http://www.mediafire.com/?gmyhlfttmj2
[14:02:45] <BastyCDGS> i think that could do the trick (note the missing break):
[14:02:49] <BastyCDGS> case ID_FORM:
[14:02:49] <BastyCDGS>             chunk_id = get_le32(pb);
[14:02:49] <BastyCDGS>             data_size = get_be32(pb);
[14:02:49] <BastyCDGS>             padding = data_size & 1;
[14:03:30] <BastyCDGS> it will ensure that reaching the default will not skip over the whole sub FORM-chunk but just the first entry of the sub-chunk
[14:04:12] <BastyCDGS> is that small enough? ;)
[14:06:02] <av500> jai: thx
[14:10:04] <DonDiego> mru: i have a commit pending for which you will love me so much that you really should consider looking into that mtv regression on big-endian
[14:10:06] <BBB> BastyCDGS: does it work? I like it - btw add a comment that it is a list-schunk then
[14:10:07] <DonDiego> :)
[14:10:18] <DonDiego> just give me a few more minutes..
[14:10:41] <BastyCDGS> I'm just adding the remaining chunks...
[14:10:45] <BastyCDGS> one moment plz
[14:11:01] <BastyCDGS> i think i have now understand the concept of your iff decoder
[14:11:16] <BastyCDGS> it's a very unusual approach but very clever
[14:12:55] <BBB> DonDiego: can you do the blind qcelp listening?
[14:13:02] <BBB> dondiego: I want to apply that patch badly
[14:13:08] <BBB> it blocks +/- 6 other patches in my tree
[14:13:18] <BBB> (little unfortunate ordering)
[14:13:42] <DonDiego> right now is not a good moment, i'm already misusing some work time for ffmpeg ;)
[14:13:59] <mru> what's your change about?
[14:14:28] <DonDiego> let's maintain the suspense
[14:14:39] <mru> vp8 decoder?
[14:14:43] <DonDiego> it's something you've always hated..
[14:14:47] <DonDiego> lol
[14:14:53] <DonDiego> no, it's small but neat
[14:14:58] <DonDiego> you will like it, promised
[14:17:02] <BBB> he's asking for a wildcard
[14:17:07] <BBB> I'm sure it's something pkg-config related
[14:17:13] <BBB> I'd better get my popcorn
[14:21:07] <DonDiego> nope, not pkg-config
[14:23:54] <CIA-7> ffmpeg: diego * r22919 /trunk/libavcodec/libtheoraenc.c: cosmetics: Switch Doxygen comments to JavaDoc style.
[14:24:51] <BastyCDGS> what do yout think about using the avi demuxer as base for iff?
[14:25:05] <BastyCDGS> after all IFF is the same as RIFF just IFF is big endian and word aligned
[14:25:53] <BastyCDGS> not want to do this yet, but as a general idea
[14:26:01] <BastyCDGS> it looks to me the RIFF code base is cleaner
[14:29:49] <Tjoppen> does IFF have the same peculiar handling of odd-length atoms as RIFF/AVI?
[14:30:46] <BastyCDGS> if the chunk size is odd in IFF one byte is skipped in the IFF file (so each chunks starts on 2 byte boundary)
[14:30:48] <Tjoppen> according to wikipedia: yes
[14:31:09] <BastyCDGS> reason for this is that old plain 68000 can only do word/dword access on even addresses
[14:31:25] <BastyCDGS> so you can read a whole IFF file straight into memory and don't have to deal with such issues
[14:31:40] <Tjoppen> sounds like how quake handles model and map loading :o
[14:33:06] <Tjoppen> well, refactoring them to share code doesn't sound too bad. reading the AVI demuxer a while back it looked like it might be possible to get it out of alignment with some strategically placed odd-length atoms (there's a hack in there for just such a case)
[14:33:16] <scaphilo> anyone knows whats the problem with long motion vectors when restricted motion vectors are not allowed?
[14:33:32] <scaphilo> i copy the motion vectors from mpeg2 to mpeg4
[14:33:41] <scaphilo> there must be a difference i dont understand
[14:36:19] <Tjoppen> ah, there it is. avidec.c:563: if (size%2) /* 2-aligned (fix for Stargate SG-1 - 3x18 - Shades of Grey.avi) */
[14:37:43] <DonDiego> hmm
[14:37:44] <DonDiego> libavformat/dvenc.c:82: warning: implicit declaration of function ‘brktimegm’
[14:38:19] <BastyCDGS> wouldn't if (size&1) be better? ;)
[14:39:19] <BBB> probably
[14:39:38] <BBB> BastyCDGS: send a patch, it'll be accepted
[14:39:45] <BBB> although most likely the compiler does it right already
[14:40:12] <BastyCDGS> ok, one moment...
[14:41:11] <BastyCDGS> the compiler does this only for unsigned if i'm not wrong since mod differs from and in that case
[14:41:30] <BBB> that's /
[14:41:34] <BBB> for %, it's the same
[14:42:44] <CIA-7> ffmpeg: diego * r22920 /trunk/libavformat/dvenc.c:
[14:42:44] <CIA-7> ffmpeg: Add missing internal.h #include for brktimegm(), fixes the warning:
[14:42:44] <CIA-7> ffmpeg: libavformat/dvenc.c:82: warning: implicit declaration of function ?brktimegm?
[14:43:18] <BastyCDGS> can I merge the size&1 patch with the basic IFF-ANIM demuxer/decoder registration?
[14:44:08] <DonDiego> 480 files changed :)
[14:44:08] <Tjoppen> most likely: no
[14:44:18] <BBB> holy shit
[14:44:23] <BBB> BastyCDGS: no
[14:44:49] <BBB> DonDiego: if your patch screws up my patches, I will so kill you
[14:45:05] <BastyCDGS> btw, shall I fix the comment, too?
[14:45:09] <DonDiego> haha
[14:45:14] <BBB> BastyCDGS: if you wish
[14:45:20] <BastyCDGS> a concrete avi file in here?
[14:45:22] <DonDiego> wow, this is taking long to go through..
[14:45:44] <BBB> BastyCDGS: I'd leave the comment alone
[14:45:49] <BBB> just fix the % -> &
[14:45:57] <BastyCDGS> ok then I'll post it to ml now
[14:46:07] <Tjoppen> if you were to change it, I'd say provide better documentation
[14:46:23] <av500> "Remove explicit filename from Doxygen @file commands."
[14:46:54] <CIA-7> ffmpeg: diego * r22921 /trunk/ (479 files in 11 dirs):
[14:46:54] <CIA-7> ffmpeg: Remove explicit filename from Doxygen @file commands.
[14:46:54] <CIA-7> ffmpeg: Passing an explicit filename to this command is only necessary if the
[14:46:54] <CIA-7> ffmpeg: documentation in the @file block refers to a file different from the
[14:46:55] <CIA-7> ffmpeg: one the block resides in.
[14:48:25] <DonDiego> mru: so? :)
[14:48:41] * BBB grabs popcorn just in case
[14:49:03] <mru> that was it?
[14:49:17] * mru neither reads nor writes documentation
[14:49:23] <DonDiego> bah
[14:49:35] <DonDiego> you've complained about this time and again!
[14:49:48] <mru> I'm mentioned it once or twice
[14:50:07] <BastyCDGS> patch commited to mailing list
[14:51:01] * av500 expected spaces to tabs conversion...
[14:51:01] * DonDiego is disappointed
[14:51:04] <DonDiego> bah
[14:51:33] <jai> BastyCDGS: don't compilers do that already
[14:52:24] <BastyCDGS> I'm not sure they do this with modulo when data type is signed
[14:52:29] <BBB> DonDiego: will you now do my blind qcelp listening test?
[14:52:50] <BastyCDGS> or with -O0
[14:53:26] <DonDiego> BBB: sorry, now i need to do a bit of the work i get paid for ..
[14:53:35] <BBB> who needs pay anyway?
[14:54:10] <jai> BastyCDGS: size should be unsigned in this case, if it isn't then that should be fixed
[14:54:44] <jai> BastyCDGS: also, unless you are debugging you probably shouldn't be using -O0 :)
[14:56:04] <BastyCDGS> ahh good that you're mentioning it
[14:56:13] <BastyCDGS> it's declared as unsigned int !!!
[14:56:17] <BastyCDGS> should be uint32_t
[14:56:19] <BastyCDGS> or?
[14:56:29] <BastyCDGS> just do another patch one moment...
[14:56:50] <jai> why uint32_t?
[14:57:02] <BastyCDGS> because int can be 16 bits or 64 bits
[14:57:07] <BastyCDGS> but avi size is always 32 bit
[14:57:17] <BastyCDGS> causes unneccesary conversions on 64 bit architectures
[14:57:22] <jai> we dont support 16bit arches :)
[14:57:33] <BastyCDGS> same to:
[14:57:36] <BastyCDGS> unsigned int tag, tag1, handler;
[14:57:40] <BastyCDGS> i saw a:
[14:57:53] <BastyCDGS> tag1 = get_le32(pb);
[14:59:06] <jai> meh, bbiab
[14:59:21] <BastyCDGS> may I fix that?
[15:00:37] <BastyCDGS> changed to:
[15:00:39] <BastyCDGS> uint32_t tag, tag1, handler;
[15:00:47] <BastyCDGS> all 3 are read with get_le32(pb)
[15:03:38] <BastyCDGS> hmm looking around in the same function shows me it's mostly used in conjunction with uint64_t
[15:08:51] <BBB> BastyCDGS: unsigned int is fine, it's in fact faster on some systems than uint32_t
[15:08:56] <BBB> so please leave it as unsigned int
[15:09:03] <BBB> these patches are generally not accepted
[15:09:09] <BastyCDGS> ok
[15:09:28] <BBB> we want it to be 64-bit on systems where it's that, because then math is faster
[15:16:49] <astrange> what systems do we support with 64-bit int?
[15:17:02] <mru> none
[15:17:34] <mru> but the basic types should still be used where the exact size doesn't matter
[15:19:48] <BBB> peloverde: do you have some time for my blind qcelp listening test?
[15:20:18] <peloverde> my ears are pretty crappy
[15:20:32] <BBB> you're our in-house audio expert! they surely are better than mine
[15:20:48] <BastyCDGS> better don't ask me about my ears ;)
[15:20:56] <peloverde> There are pre-echo artifacts that are deemed severe that I cannot hear
[15:21:09] <peloverde> and anyway I need to finish PS before I go to Florida on Thursday
[15:21:15] <BBB> ok ok :)
[15:22:34] <astrange> i can do an abx now if you don't mind ipod earbuds
[15:22:53] <kierank> BBB: I can try if you want as well
[15:27:02] <DonDiego> BBB: ping me about the listening test later
[15:35:29] <BastyCDGS> so just compiling to see if it works now
[15:41:13] <BBB> dondiego: ok
[15:41:15] <BBB> oops, he's gone
[15:41:28] <BBB> kierank: that'd be great, did you see the email on-list?
[15:42:01] <BBB> http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107976
[15:42:03] <BBB> see that email
[15:50:21] <BastyCDGS> just running make test, hope it works
[15:52:43] <BastyCDGS> could someone explain me how the tests actually work I mean i'm wondering how the codecs do verify themself and what files they use
[15:52:51] <BastyCDGS> have I prepare some IFF-ANIM files for testing?
[15:53:20] <Compn> which test ?
[15:53:25] <Compn> oh make test
[15:53:33] <Compn> you can read makefile to see what it does
[15:53:40] <astrange> can't distinguish r1.wav / r2.wav (p = .75)
[15:56:07] <BastyCDGS> make test is already running just want to know if I have to setup a test for a new codec manually (providing IFF-ANIM files etc.)
[15:57:45] <BastyCDGS> the tests went successfully itself after applying my code but didn't see a test for iff
[15:59:39] <astrange> BBB: i can't tell the difference between any of them in a mildly noisy environment
[16:00:01] <kierank> I can't tell any difference either
[16:00:13] <kierank> possibly r3 is every so slightly better
[16:02:43] <Dark_Shikari> bilboed: I know the celt guys use it sometimes
[16:03:02] <Dark_Shikari> peloverde: dunno
[16:03:04] <bilboed> Dark_Shikari, ok, I'll ask derf
[16:10:33] <BastyCDGS> just sent a RFC of my patch to mailing list
[16:10:44] <BastyCDGS> could someone take a look and give me some advice based on this?
[16:15:10] <BastyCDGS> hey dark shikari, how are u?
[16:16:04] * mru glares at Dark_Shikari
[16:16:10] <mru> BastyCDGS: he's frightened :-)
[16:18:28] <BastyCDGS> or just busy ;)
[16:19:57] <BastyCDGS> mru, could you review my rfc patch?
[16:23:18] <BastyCDGS> when I try to play an IFF-ANIM
[16:23:33] <BastyCDGS> it says:
[16:23:36] <BastyCDGS> [IFF @ 0x8b2f790]iff: unknown compression method
[16:23:57] <BastyCDGS> so the file is detected correctly
[16:24:18] <BastyCDGS> ./ffplay ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows
[16:24:22] <BastyCDGS> that was my cmd line
[16:25:00] <BastyCDGS> but it doesn't out the stub debug info
[16:25:38] <BastyCDGS> is that because libavformat doesn't forward to libavcodec on cases like unknown compression?
[16:28:05] <BastyCDGS> oh I forget one line, after:
[16:28:24] <BastyCDGS> the unknown compression method, it says: ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows: Operation not permitted
[16:30:31] <BBB> uh...
[16:30:36] <BBB> astrange: what do these mplayer commandlines do?
[16:36:34] <BastyCDGS> damn I've forgotten the compression methods in the cases
[16:43:12] <BastyCDGS> thanks for reviewing...
[16:43:27] <BastyCDGS> will fix now the stuff you've been complaining
[16:52:25] <jai> elenril: ping
[16:52:28] <BastyCDGS> mru the iff.h file was just a naive C++ class to C conversion that's why it looks strange
[16:52:38] <BastyCDGS> made protected methods static funcs
[16:52:42] <BastyCDGS> and public normal
[16:54:09] <astrange> BBB: plays the first 3 seconds of the file
[16:54:30] <astrange> with abxtest from madplay
[16:56:05] <BastyCDGS> mru, i changed my typedef you've been complaining to following, ok?
[16:56:07] <BastyCDGS> typedef enum {ANIM_LONG_DELTA, ANIM_SHORT_DELTA,
[16:56:07] <BastyCDGS>               ANIM_GENERAL_DELTA, ANIM_BYTE_VERTICAL_DELTA, ANIM_STEREO_BYTE_DELTA,
[16:56:07] <BastyCDGS>               ANIM_BYTE_VERTICAL_DELTA_WORD, ANIM_BYTE_VERTICAL_DELTA_LONG,
[16:56:07] <BastyCDGS>               ANIM_ERIC_GRAHAM = 74} anim_compression_type;
[16:57:20] <mru> one name per line, please
[16:57:27] <mru> like everywhere else
[16:57:35] <mru> the two enums above it are the ugly exceptions
[17:02:05] <elenril> jai: pong
[17:03:06] <BastyCDGS> ok then I'll change the two enums, too...
[17:03:45] <jai> elenril: hi, quick question : why does the txxx frame parsing code have a 512 byte limit?
[17:03:46] <mru> not in the same patch
[17:05:50] <BastyCDGS> ok, is it okay when I change the two enums and the indentiation in one patch?
[17:05:55] <CIA-7> ffmpeg: rbultje * r22922 /trunk/libavformat/avidec.c: Change a %2 to &1. Patch by Sebastian Vater <cdgs DOT basty googlemail com>.
[17:06:27] <BastyCDGS> merci
[17:06:59] <BBB> welcome
[17:07:02] <elenril> jai: dunno
[17:07:07] <BBB> or, well, since you're belgian
[17:07:08] <BBB> de rien
[17:07:15] <elenril> probably because whoever wrote it thought it was enough for everyone ;)
[17:08:20] <BastyCDGS> i thought 640KB are enough for everyone :D
[17:08:26] <jai> elenril: well, we would need to be able to parse variable length strings
[17:08:51] <jai> elenril: though at this point i'm not sure which would be the cleaner way of doing this
[17:09:01] <elenril> yeah, i guess yuo'd need that for long things like lyrics
[17:09:10] <jai> elenril: exactly :)
[17:09:13] <elenril> malloc(len);?
[17:09:25] <jai> also i all these miley cyrus lyrics are BS
[17:09:26] <jai> but whatever
[17:09:32] <jai> -i
[17:09:55] <jai> elenril: theoretically length could be 32 bits
[17:15:27] <BBB> more people interested in blind qcelp audio quality test?
[17:15:32] <BBB> kierank: did you test?
[17:15:46] <kierank> yes
[17:15:51] <kierank> couldn't hear any difference
[17:16:03] <BBB> ok
[17:16:15] <BBB> astrange: can you add mplayer -endpos 3 r[23].wav?
[17:16:19] <BBB> just so we have a complete list
[17:17:37] <astrange> if 1==2 and and 1==3 then 2==3
[17:17:39] <astrange> i think
[17:17:57] <BBB> I want the percentages and differences
[17:21:01] <astrange> um, i went faster and got more accurate results than last time, how'd that happen
[17:21:05] <astrange> still wasn't significant though
[17:21:05] <astrange> correct: 7/10 (70%)
[17:21:05] <astrange> probability (p) of result being the same as random guesses = .1718742
[17:21:10] <BastyCDGS> bbb french is not my native language...it's german, but since I'm now living in french spoken part of be I changed my ubuntu to fr-BE locale
[17:21:25] <BastyCDGS> so i learn it faster and on-the-fly ;)
[17:25:13] <BastyCDGS> indent patch commited to ml
[17:27:48] <BBB> astrange: I still don't know what it tests :)
[17:28:24] <BBB> ah, I see from wikipedia now
[17:28:26] <BBB> ingenious
[17:29:07] <astrange> needs to be p = .05 (95% accurate)
[17:29:18] <BBB> right
[17:29:49] <BBB> ok, I'll take that as random then
[17:31:35] <BBB> BastyCDGS: look at enum codecID in avcodec.h to see how to declare enums
[17:31:39] <jai> BastyCDGS: could you avoid the cosmetics stuff
[17:31:43] <BBB> the second part of the patch is ok
[17:31:55] <BBB> jai: his patch = cosmetics :)
[17:32:08] <BBB> typedef enum {\n
[17:32:18] <BBB> space space space space COMP_NONE,\n
[17:32:21] <BBB> etc.
[17:32:22] <BBB> };
[17:32:39] <BBB> actually, make that } bla_type;
[17:34:13] <BastyCDGS> so drop the typedef in front too?
[17:34:38] <BastyCDGS> ah ok I see indent is 4
[17:35:34] <BBB> don't drop the typdef, then it wouldn't compile
[17:35:59] <jai> BBB: yeah, what's the point :)
[17:36:03] <BastyCDGS> but  bitmap_compression_type etc.?
[17:36:44] <jai> ease of maintenance is probably the only consideration here
[17:38:03] <CIA-7> ffmpeg: rbultje * r22923 /trunk/ (doc/ffmpeg-doc.texi ffmpeg.c):
[17:38:03] <CIA-7> ffmpeg: Allow setting the environment variable FFMPEG_DATADIR to locate preset files.
[17:38:03] <CIA-7> ffmpeg: Patch by Robert Kr?ger <krueger signal7 de>.
[17:38:18] <BBB> hmm...
[17:39:17] <jai> i'd suggest sticking to just functionality related code right now
[17:39:51] <BBB> I don't mind such fixes
[17:40:00] <BBB> but yes, make sure you finish some iff/anim-related code also ;)
[17:41:08] <BastyCDGS> i'm debugging iff-anim stuff right now
[17:41:19] <BastyCDGS> the 3rd chunk being read is complete null
[17:42:00] * BBB goes for lunch
[17:42:15] <BastyCDGS> bon appetit :)
[17:45:56] <BastyCDGS> fixed indent patch commited to ml
[17:49:38] <BastyCDGS> serious problem
[17:49:49] <BastyCDGS> the existing code is broken
[17:50:12] <BastyCDGS> reading BMHD
[17:51:02] <BastyCDGS> using the same code with an IFF-ANIM doesn't work on reading BMHD
[17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x4d524f46, size: 0x0000a736
[17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x44484d42, size: 0x00000014
[17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x0000474d, size: 0x00040000
[17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: reading chunk 0x00000000, size: 0x00000000
[17:51:21] <BastyCDGS> [IFF @ 0x8b2f790]iff: unknown compression method
[17:51:28] <BastyCDGS> (added this for debug)
[17:51:39] <BastyCDGS> 0x44484d42 is BMHD
[17:52:25] <BastyCDGS> iff-anim hexdump of first 4 lines:
[17:52:30] <BastyCDGS> 00000000  46 4f 52 4d 00 03 0d 38  41 4e 49 4d 46 4f 52 4d  |FORM...8ANIMFORM|
[17:52:30] <BastyCDGS> 00000010  00 00 a7 36 49 4c 42 4d  42 4d 48 44 00 00 00 14  |...6ILBMBMHD....|
[17:52:30] <BastyCDGS> 00000020  01 40 00 c8 00 00 00 00  06 00 01 00 00 00 0a 0b  |. at ..............|
[17:52:30] <BastyCDGS> 00000030  01 40 00 c8 43 41 4d 47  00 00 00 04 00 00 48 00  |. at ..CAMG......H.|
[17:52:44] <BastyCDGS> that's the file it was trying to read
[17:53:04] <BastyCDGS> after all the iff reading code is not standard conform at all
[17:53:23] <BastyCDGS> because it expects the known chunks to be a specific size
[17:53:54] <BastyCDGS> that's the first problem, the second problem is that the existing code assumes wrongly that BODY is the last chunk (while breaks then)
[17:54:23] <BastyCDGS> although almost all IFF files follow the latter rule the IFF standard doesn't require this
[17:56:53] <BastyCDGS> I'll create a separate patch now for making the old IFF code standard comforming, ok?
[18:00:01] <BastyCDGS> it doesn't even check if a known chunk is large enough to hold the data it wants to read
[18:11:23] <BBB> BastyCDGS: that sounds like a good idea, yes, if there's size elements that we don't conform to, then you want to fix this
[18:11:35] <BastyCDGS> just doing it ;)
[18:11:38] <BastyCDGS> VHDR already fixed
[18:11:39] <BBB> great
[18:11:41] <BBB> keep it going
[18:12:08] <BastyCDGS> sorry I could have noticed this earlier...just have forgotten this after such a long time
[18:12:28] <BastyCDGS> (I was considering that when loading TuComposer Module which does it right)
[18:14:51] <BastyCDGS> in ANNO stuff there the padding skip is completely missing
[18:15:09] <BastyCDGS> so your original code breaks on any IFF file which has an odd annotation string length
[18:23:05] <BBB> feel free to add padding skips where you feel it's necessary
[18:24:33] <BastyCDGS> finished all chunks
[18:24:39] <BastyCDGS> just checking if it compiles
[18:26:43] <BastyCDGS> yes it does ;)
[18:28:33] <BastyCDGS> can i merge that patch with the indent stuff?
[18:29:37] <BastyCDGS> if not it would be good if someone at least commits that to svn since the diff I got doesn't delimit both
[18:31:48] <BBB> use git, or quilt
[18:32:03] <elenril> git++
[18:32:24] <kierank> git#
[18:32:27] <kierank> or objective git
[18:32:39] <BastyCDGS> I have no experience with git yet...
[18:33:45] <BBB> what was the way to check for non-whitespace changes again?
[18:33:54] <BBB> svn diff -xyz or so?
[18:34:02] <janneg> -x b
[18:34:10] <janneg> or -x w
[18:35:00] <janneg> maybe -x -b|w
[18:36:22] <BastyCDGS> -x b doesn't work with svn diff
[18:36:27] <BastyCDGS> neither does -x w
[18:36:52] <BBB> well I applied it anyway
[18:37:00] <BBB> svn up to continue
[18:37:10] <BBB> and become a git master, it's useful
[18:39:01] <BastyCDGS> not yet arrived here...do i have to wait until CIA-7 says it here?
[18:40:43] <BastyCDGS> ok is here
[18:41:04] <BastyCDGS> but the typedef enum stuff?
[18:41:14] <kierank> does anyone else keep thinking of turkey basters when reading BastyCDGS's comments?
[18:41:25] <BBB> I committed it all
[18:41:37] <CIA-7> ffmpeg: rbultje * r22924 /trunk/libavformat/iff.c:
[18:41:37] <CIA-7> ffmpeg: Reindent / reformat some code with broken indenting.
[18:41:37] <CIA-7> ffmpeg: Patch by Sebastian Vater <cdgs DOT basty googlemail com>.
[18:42:02] <BastyCDGS> kierank which comments you mean exactly?
[18:42:22] <kierank> your username
[18:42:58] <BastyCDGS> CDGS = Coders Develop Glorious Stuff ;)
[18:43:15] <BBB> I always thought we were hackers, not coders
[18:48:58] <BastyCDGS> #define HACKER CODER :P
[18:52:14] <drv> is there any way to filter the bug tracker to show only non-license-violation bugs?
[18:52:34] <BastyCDGS> patch commited for 100% IFF standard compliance
[18:52:37] <BastyCDGS> at ml
[18:54:08] <elenril> 110% when
[18:55:03] <drv> when the marketing department arrives ;)
[18:59:08] <BBB> drv: uh, they have their own bug status
[18:59:14] <BBB> drv: so select all other bug statuses
[18:59:17] <BBB> then click search
[18:59:23] <jai> drv: license violation related issues are piling up like crazy
[18:59:33] <jai> time to let the lawyers loose? :)
[18:59:53] <drv> well, they have their own topic, but you can only search by one topic at a time, unless there's another search page i'm missing
[19:00:01] <BBB> rly?
[19:00:11] <drv> looking at https://roundup.ffmpeg.org/issue?@template=search
[19:00:19] <jai> roundup's interface is a pos imho
[19:00:36] <drv> it's rather slow too, or maybe that's just because i'm on the other side of the ocean ;)
[19:00:51] <kierank> it's slow anyway I think
[19:00:52] <BastyCDGS> wtf??? i just read the mail I sent and the annotation stuff was still in?
[19:01:03] <BastyCDGS> indentation sry
[19:01:18] <BBB> drv: you're right
[19:01:19] <BBB> that sucks
[19:01:21] <BBB> file a bug :)
[19:01:32] <BastyCDGS> will resent the patch, I probably did choose the wrong file (older one)
[19:02:56] <BastyCDGS> done
[19:03:04] <BBB> where are the iff samples on samples.mphq.hu?
[19:03:23] <jai> BBB: btw, you are reviewing the iff stuff right?
[19:03:29] <BBB> yes
[19:03:34] <jai> nice :)
[19:03:38] * jai goes to watch a movie
[19:04:36] <BastyCDGS> which movie?
[19:05:11] <_av500_> BBB?
[19:05:26] <BBB> screw you :)
[19:05:29] <BBB> ;)
[19:05:58] <BBB> jai: but any help is appreciated
[19:06:35] <BastyCDGS> just forgot to add the copyright note to the iff stuff, should I add this as a single patch?
[19:09:29] <BBB> do it at the end
[19:09:33] <BBB> is generally the recommended approach
[19:09:43] <janneg> _av500_: ~4 scenes remaining, 3600 frames
[19:28:42] <BBB> BastyCDGS: download http://samples.mplayerhq.hu/image-samples/ASH.LBM
[19:28:50] <BBB> BastyCDGS: after your patch, make sure that frame still displays
[19:28:54] <BBB> that's a good test
[19:29:11] <BastyCDGS> I've made an error in the BODY chunk
[19:29:15] <BastyCDGS> just fixing that
[19:29:26] <BastyCDGS> was skipping one byte always without reading the body stuff
[19:43:46] <BBB> make sure to test your changes
[19:44:03] <BBB> this sort of stuff should generally not happen :) we expect you to check your changes if you can
[19:50:50] <BastyCDGS> Input #0, IFF, from '../patches/ASH.LBM':
[19:50:51] <BastyCDGS>   Duration: N/A, bitrate: N/A
[19:50:51] <BastyCDGS>     Stream #0.0: Video: iff_byterun1, pal8, 320x240, PAR 5:6 DAR 10:9, 90k tbr, 90k tbn, 90k tbc
[19:50:51] <BastyCDGS> 1271793003.07 A-V:  0.000 s:0.0 aq=    0KB vq=    0KB sq=    0B f=0/0
[19:50:58] <BastyCDGS> with my correction...
[19:53:15] <BBB> but do you see the image? and is it identical?
[19:54:40] <BastyCDGS> there is just this console output ;)
[19:54:47] <BastyCDGS> no window with an image
[19:55:09] <BBB> ok, remove your changes and try again - you should see a window pop up with an image
[19:55:26] <BBB> good way to remove your changes: svn diff file > patch; svn revert file
[19:55:41] <BBB> then figure out why
[19:56:57] <mru> git does it better
[19:57:12] <mru> "git stash" to hide away all your local changes
[19:57:18] <mru> "git stash pop" to put them back
[19:57:43] * BBB cries because he doesn't "get" git
[19:58:29] <mru> think of it as something that does all the things you ever wished svn would and none of the things you wished it didn't
[19:58:49] <BBB> I know... I just wish I knew how to use it
[19:59:05] * mru wasn't born with that knowledge
[19:59:29] <BBB> mru: can you do my blind qcelp listening test?
[19:59:30] <BastyCDGS> do I have to set configure flags to get graphical output with ffplay under linux?
[19:59:36] <BBB> BastyCDGS: no
[19:59:38] <BastyCDGS> sth. like with-sdl?
[19:59:49] <BBB> BastyCDGS: try any other video file
[20:00:08] <BBB> you need sdl-devel though
[20:00:17] <BBB> or whatever it's called on your distro
[20:00:40] <BastyCDGS> video works
[20:03:51] <BastyCDGS> what is exactly required for a window to be opened?
[20:04:03] <BastyCDGS> i mean what the demuxer has to initialize for it?
[20:05:28] <BBB> nothing, you broke the demuxer (I think) so it doesn't output any video packets
[20:05:31] <BBB> then, no video window is shown
[20:05:32] <BBB> :)
[20:05:44] <BBB> so figure out what you broke and fix it
[20:05:49] <BBB> e.g., remove your local changes
[20:05:53] <BBB> then re-apply them one by one
[20:05:55] <BBB> and see what breaks it
[20:20:20] <BastyCDGS> removing done = 1 from the BODY part causes the trouble
[20:20:49] <BBB> BastyCDGS: right, I can explain you why but maybe it's better if you figure it out yourself ;) it's a good lesson
[20:20:58] <BBB> f you can't figure it out, let me know :-p
[20:21:20] <BBB> I can also help suggest some fixes
[20:21:42] <BastyCDGS> well I think I have it
[20:21:51] <BastyCDGS> the file position has to be at the start at the chunk ;)
[20:21:56] <BastyCDGS> BODY
[20:22:04] <BastyCDGS> to the decoder can directly read it
[20:22:24] <BastyCDGS> done ensures that it leaves the loop immediately
[20:22:47] <BBB> not decoder, it's actually the demuxer itself
[20:22:49] <BBB> but you're close
[20:22:56] <BBB> you're looking at iff_read_header(), right?
[20:23:06] <BastyCDGS> yes I'm looking there
[20:23:40] <CIA-7> libswscale: diego * r31050 /trunk/libswscale/swscale.h:
[20:23:41] <CIA-7> libswscale: Remove explicit filename from Doxygen @file commands.
[20:23:41] <CIA-7> libswscale: Passing an explicit filename to this command is only necessary if the
[20:23:41] <CIA-7> libswscale: documentation in the @file block refers to a file different from the
[20:23:41] <CIA-7> libswscale: one the block resides in.
[20:23:55] <BBB> ok, that's called once to open the file
[20:24:04] <BBB> the actual data is transferred to the decoder in iff_read_packet()
[20:24:06] <BBB> the next function
[20:24:07] <BBB> look there
[20:24:16] <BBB> your logic is correct, but this is all still part of the demuxer
[20:24:18] <BastyCDGS> I just did ;)
[20:24:23] <BBB> good, so continue there :0
[20:24:25] <BBB> :-p
[20:24:36] <BastyCDGS> and seen that you read the buffer there
[20:24:45] <BBB> the function looks crappy by the way
[20:25:05] <BBB> "pkt" is the packet that will be sent to the demuxer at the end of this function call
[20:25:14] <BBB> so the function is called repeatedly
[20:25:18] <BBB> ocne per video frame
[20:26:55] <BastyCDGS> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[20:27:16] <BastyCDGS> so I have just to ftell to the BODY part?
[20:27:25] <BastyCDGS> after leaving the IFF reading loop
[20:27:40] <BastyCDGS> so the packet decoder reads the correct part
[20:31:18] <BastyCDGS> what was me wondering when I remove the done=1 the start time isn't 0.0 but some "random" value
[20:31:23] <BastyCDGS> why is this?
[20:36:07] <BastyCDGS> yeah my patch works now
[20:36:24] <BastyCDGS> just readded done and did a data_size_skip = 0
[20:36:34] <BastyCDGS> (renaming data_size_padding to data_size_skip sounds better)
[20:40:28] <bcoudurier> hi guys
[20:41:04] <BastyCDGS> hi bcoudurier
[20:41:41] <Dark_Shikari> hi bcoudurier's onjoin script
[20:42:09] <bcoudurier> :)
[20:42:21] <bcoudurier> how do you do a good stereo to mono downmix ?
[20:42:27] <Dark_Shikari> average the two channels?
[20:43:45] <bcoudurier> is it the best ?
[20:43:54] <bcoudurier> because it seems to me that it would lower the volume
[20:44:16] <Dark_Shikari> you can't amplify it, that would cause clipping
[20:44:24] <BastyCDGS> I do it by (left+right+1) >> 1;
[20:44:30] <mru> that's average
[20:44:35] <astrange> that's not the best way
[20:44:37] <BastyCDGS> but with rounding up
[20:44:52] <mru> arithmetic average doesn't conserve power
[20:44:57] <astrange> the two channels could be opposite phase and it would sound different
[20:44:58] <mru> or energy or something
[20:45:10] <bcoudurier> indeed
[20:45:15] <astrange> pretty much everything uses linear operations on audio
[20:45:43] <mru> what is a good way to deal with phase shifts?
[20:46:13] <astrange> not sure, i just know the problem exists and may not be worth dealing with in realtime
[20:46:14] <bcoudurier> Yuvi, are you around ?
[20:47:23] <mru> sound from two speakers also sounds differently depending on listening position
[20:47:31] <mru> a single speaker always sounds the same
[20:48:51] <BBB> you're suggesting to not convert to mono
[20:48:54] <BastyCDGS> well you could cubic spline resampling
[20:48:56] <BBB> but he wants to convert to mono :)
[20:49:26] <BBB> what happens if you do the FFT, add these two up and IFFT it?
[20:49:30] <BBB> I suppose you get garbage?
[20:49:33] <mru> the ultimate mono downmix has to take listening position into account
[20:49:49] <BBB> for mathematical simplicity, let's assume "center"
[20:50:24] <mru> and a single ear?
[20:50:46] <wbs> do a van gogh and chop one off :-)
[20:51:01] <wbs> just for mathematical simplicity :-)
[20:51:06] <BBB> BastyCDGS: yes, url_ftell() is a good way of solving it
[20:51:10] <mru> oh, that's why he did it...
[20:51:32] <BastyCDGS> lol
[20:52:04] <BastyCDGS> and what's with the remaining one? do that to and you save the mono conversion completely...
[20:52:09] <BastyCDGS> just stream /dev/zero :D
[20:52:15] <BastyCDGS> faaaaaaaaaaast
[20:52:36] <BastyCDGS> if that isn't mathematical simplicity I don't know...;)
[20:58:02] <Dark_Shikari> mru: QOTD
[20:58:04] <Dark_Shikari> "Ogg wasn't "designed", it was thrown together in the same fashion that a 4 year old cleans up his room by hiding all the toys in the closet. "
[20:58:11] <BastyCDGS> I just updated the patch in ml
[20:58:14] <mru> Dark_Shikari: lol
[20:58:17] <BastyCDGS> this one is working now
[20:58:25] <mru> Dark_Shikari: source?
[20:58:35] <thresh> so you're friends again?
[20:58:41] <Dark_Shikari> mru: a post on the internets
[20:58:51] <BastyCDGS> thresh, looks like ;)
[20:59:27] <mru> gotta love those internets
[21:05:14] <BBB> http://forums.thedailywtf.com/forums/p/16477/220422.aspx
[21:05:17] <BBB> gotta love google
[21:05:22] <BBB> I seriously love google so much
[21:05:27] <BBB> if I weren't married, I'd marry google
[21:05:39] <Dark_Shikari> Yeah, I reposted it there
[21:06:05] <Dark_Shikari> Good to know that the understanding of ogg's horribleness is widespread even outside of the video community ;)
[21:06:51] <Dark_Shikari> oh by the way, mru, any conclusion on the pthread configure check?
[21:08:26] <BBB> Dark_Shikari: can you do my blind qcelp audio test?
[21:08:35] <Dark_Shikari> I can try, I don't have golden ears though
[21:08:40] <Dark_Shikari> poke me in 20 minutes
[21:08:43] <BBB> ok
[21:09:34] <BastyCDGS> bbb, I got it working with ftell yeah
[21:10:05] <BBB> good work
[21:10:10] <BBB> I'll review the patch later
[21:10:13] <BBB> doing something else now
[21:10:30] <BBB> does it play files from http://www-user.tu-chemnitz.de/~womar/projects/iffanim/iffanim_samplepack.zip now?
[21:10:33] <BBB> none of them work :(
[21:12:21] <bcoudurier> ooooaaaah
[21:12:35] <bcoudurier> I can't believe nobody activated audio stream header parsing for mkv
[21:12:46] <bcoudurier> no wonder why it's been a long standing issue
[21:14:27] <BastyCDGS> bbb, how it can play iffanim? that's a patch fixing an issue with the original iff demuxer
[21:14:41] <BastyCDGS> I'll apply the new stuff now to iffanim and see how it works
[21:14:56] <BBB> I guess...
[21:15:02] <BBB> make them work ;)
[21:20:18] <CIA-7> ffmpeg: bcoudurier * r22925 /trunk/libavformat/matroskadec.c: parse stream headers for audio streams in mkv, needed for frame size
[21:22:08] <BBB> bcoudurier: should that be vertically aligned? </nag>
[21:23:39] <bcoudurier> what should  ?
[21:24:04] <BBB> the statements around the code in the patch you just applied
[21:24:38] <CIA-7> ffmpeg: bcoudurier * r22926 /trunk/libavformat/matroskadec.c: seems aac gets screwed up by the parser so disable it
[21:24:43] <bcoudurier> yes indeed, though nobody aligned the H264 one
[21:25:13] <BBB> until I understand h264, I'll pretend it's black magic that I should not look at
[21:25:37] <Dark_Shikari> bah it isn't that hard =p
[21:26:19] <bcoudurier> the specs give headache
[21:26:31] <mru> h264 isn't so bad
[21:26:35] <mru> the spec is almost readable
[21:26:40] <mru> and it mostly makes sense
[21:26:45] <mru> compare that to the mpeg4-2 spec
[21:26:46] <BBB> it takes 10 years to read
[21:26:49] <mru> yuck
[21:27:42] <Dark_Shikari> well, the spec loves copy-pasting
[21:27:45] <Dark_Shikari> see svc
[21:28:05] <Dark_Shikari> bcoudurier: the best parts of the spec are those that seem basically designed to mislead you about subtle things
[21:28:10] <Dark_Shikari> Something we discovered recently, for example
[21:28:41] <Dark_Shikari> the spec would lead you to believe that it is impossible to have two consecutive duplicate reference frames in a reference list post-reordering
[21:28:55] <Dark_Shikari> because the syntax element is difference_between_frame_nums_minus1 or whatever
[21:28:58] <Dark_Shikari> and is an unsigned exp-golomb code
[21:29:06] <Dark_Shikari> .... But if you make a really really large value
[21:29:10] <Dark_Shikari> in particular, (max_frame_num-1)
[21:29:13] <Dark_Shikari> it'll wrap around and go back to zero.
[21:29:25] <Dark_Shikari> Thus allowing two consecutive frames of the same frame_num in the reference list.
[21:29:35] <Dark_Shikari> One of my stream analyzers bitches like crazy because it doesn't realize this is valid.
[21:29:38] <kierank> they just talked about it on jvt-experts as if it was a normal thing to do
[21:29:39] <BBB> bcoudurier: oh, for AAC fun, check http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/rdt_8c-source.html line 428
[21:29:42] <kierank> even though it's a bit weird
[21:29:50] <BBB> bcoudurier: that works for me
[21:29:55] <Dark_Shikari> kierank: yeah
[21:29:57] <Dark_Shikari> that too
[21:30:49] <bcoudurier> WHAT ?
[21:30:53] <bcoudurier> BBB please...
[21:31:03] <bcoudurier> this issue should have been fixed _years_ ago
[21:31:22] <Dark_Shikari> lol what
[21:31:23] <bcoudurier> as a developper I would have expected more motivation ;)
[21:31:28] <BBB> bcoudurier: I wrote that code long before I had half a clue... I sill have no clue mostly
[21:31:44] <bcoudurier> well 2 options
[21:31:45] <BBB> I still don't know what the issue is, for example
[21:31:50] <BBB> I know this works :)
[21:31:53] <bcoudurier> we cannot compute frame size from extradata
[21:31:58] <BBB> I think aacdec doesn't set framesize
[21:32:03] <bcoudurier> easy, just add a function that parse extradata and compute frame size
[21:32:14] <bcoudurier> otherwise we need to extend the parser
[21:32:23] <BBB> the parser/decoder should set it imo
[21:32:33] <bcoudurier> it does
[21:32:38] <BBB> uh...
[21:32:41] <BBB> then why doesn't it get set?
[21:32:43] * BBB confused
[21:32:44] <bcoudurier> problem is that the parser/decoder is called _after_
[21:32:49] <bcoudurier> the timestamps interpolation
[21:32:52] <bcoudurier> no
[21:32:58] <bcoudurier> the parser is called _before_
[21:33:04] <bcoudurier> the decoder is called _after_
[21:33:14] <bcoudurier> so if the decoders sets it, it's too late for the first frame
[21:33:31] <BBB> so what is the bug?
[21:33:36] <BBB> I can't remember what bug it fixed
[21:33:38] <peloverde> Isn't that what try_decode_frame is for?
[21:33:39] <BBB> but it fixed a bug I was having
[21:33:45] <bcoudurier> peloverde, it is for that
[21:33:50] <bcoudurier> but it is called after the parsing
[21:33:57] <bcoudurier> so if the packet contains multiple frames
[21:34:05] <bcoudurier> and the frame size is not computed in the parser
[21:34:12] <bcoudurier> the first frames will have wrong timestmaps
[21:34:29] <bcoudurier> guys
[21:34:35] <bcoudurier> am I the only one who digged into that code ?
[21:34:47] <bcoudurier> dug ?
[21:34:52] <BBB> I probably digged into it and gave up because it's such a big mess of things I don't get
[21:35:01] <BBB> I apologize for the hack though
[21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=12, dts=-9223372036854775808, size=846, duration=0, flags=1
[21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=846, duration=0, flags=1
[21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=-9223372036854775808, dts=-9223372036854775808, size=887, duration=0, flags=0
[21:35:52] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_intern[matroska @ 0x15a2440]av_read_packet stream=1, pts=12, dts=-9223372036854775808, size=846, duration=0, flags=1
[21:35:54] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=846, duration=0, flags=1
[21:35:54] <peloverde> bcoudurier, the frame size in *time* can be trivially computed from the headers
[21:35:56] <bcoudurier> [matroska @ 0x15a2440]av_read_packet stream=1, pts=-9223372036854775808, dts=-9223372036854775808, size=887, duration=0, flags=0
[21:36:01] <bcoudurier> [matroska @ 0x15a2440]av_read_frame_internal stream=1, pts=12, dts=12, size=887, duration=21, flags=1
[21:36:03] <bcoudurier> al stream=1, pts=12, dts=12, size=887, duration=21, flags=1
[21:36:05] <bcoudurier> this is pretty obvious
[21:36:08] <peloverde> the frame size in *samples* cannot
[21:36:33] <bcoudurier> that's a problem
[21:36:40] <bcoudurier> _but_ if the duration can be set
[21:36:47] <bcoudurier> it should be fine
[21:36:57] <bcoudurier> I mean mkv packet duration
[21:37:23] <bcoudurier> was it _too_ hard to put a frame size field in mkv ?
[21:37:30] <bcoudurier> I mean mov has it since _years_
[21:38:41] <BBB> mkv is like ogg
[21:38:43] <BBB> they first design
[21:38:46] <BBB> then they release
[21:38:48] <BBB> then they wait for bugs
[21:38:51] <BBB> then it's too late
[21:38:57] <BBB> "oops"
[21:38:57] <mru> lol
[21:39:06] <peloverde> The frame size in time is the (1024-64*frame_length_flag)/nominal_sample_rate
[21:39:15] <mru> BBB: one difference
[21:39:24] <mru> the mkv guys at least tried to get it right
[21:39:32] <BBB> I guess
[21:39:44] <saintdev> mru: isn't the difference that ogg never had the "first design" step
[21:39:57] <mru> that too
[21:40:19] <bcoudurier> well they messed up the nomenclature
[21:40:25] <bcoudurier> and I will never forgive them for this
[21:40:40] <bcoudurier> now everybody is confusing time codes and timestamps
[21:41:10] <peloverde> also you can use OutputSamplingFrequency to detect SBR and simplify the whole mess
[21:41:18] <BBB> bcoudurier: it's well possible if you fix your bug in mov, I can remove that crazy code from rdt as well
[21:41:33] <bcoudurier> mov has no bug
[21:41:35] <bcoudurier> ;)
[21:41:38] <BBB> so please allow me to sit back, relax and do nothing while you fix the bug. . . . . <waits to be kicked>
[21:41:59] <bcoudurier> which bug are talking about ?
[21:42:09] <BBB> the part where you need if (.. AAC ..) in mov.c
[21:42:25] <BBB> might not be a bug IN mov.c
[21:42:27] <bcoudurier> peloverde, how is the fastest way to compute the frame size ?
[21:42:29] <BBB> but it's a bug involving mov.c
[21:42:34] <bcoudurier> can it be done in the parser ?
[21:42:50] <peloverde> which parser
[21:42:53] <bcoudurier> aac
[21:42:57] <peloverde> MO!
[21:43:00] <peloverde> *No!
[21:43:03] <peloverde> No no no no no no no
[21:43:07] <peloverde> don't use the AAC parser
[21:43:08] <bcoudurier> if AAC in mov.c is when reading esds
[21:43:20] <bcoudurier> that is no bug
[21:43:25] <BBB> peloverde: is it broken? can you fix it?
[21:43:32] <bcoudurier> well then in the matroska demuxer
[21:43:41] <peloverde> BBB, it's not broken
[21:43:49] <BBB> but...
[21:43:50] <peloverde> it has a specific purpose
[21:44:00] <BBB> which is...?
[21:44:06] <peloverde> it's not some panacea to be cargo culted around
[21:44:11] <bcoudurier> btw, IMHO the parser should not garble the bitstream
[21:44:12] <peloverde> to parse raw ADTS streams
[21:44:31] <peloverde> the parser has to bitstream sync
[21:44:37] <BastyCDGS> sorry was away
[21:44:49] <peloverde> if you are sending wrong data to the parser you should expect funny results
[21:45:16] <peloverde> if you sent h.264 to the ac3 parser you'd get funny results
[21:45:21] <bcoudurier> peloverde, if should support PARSE_HEADERS though
[21:45:25] <bcoudurier> and not search for sync
[21:45:41] <peloverde> the aac_parser should really be called adts_parser
[21:45:53] <bcoudurier> probably
[21:46:04] <peloverde> if you send non adts data to it, it tries to make it adts
[21:46:22] <bcoudurier> ?
[21:46:40] <bcoudurier> it just splits the bitstream on adts headers
[21:46:41] <Yuvi> bcoudurier: pong
[21:46:48] <peloverde> yes
[21:47:06] <bcoudurier> Yuvi, I activated header parsing for audio streams in mkv
[21:47:09] <peloverde> for aac in mkv there are no headers to be parsed
[21:47:14] <bcoudurier> the last goal is to compute aac frame size
[21:47:40] <bcoudurier> indeed, no headers, but mkv sets PARSE_HEADERS
[21:47:43] <bcoudurier> no PARSE_FULL
[21:47:46] <peloverde> if some idiot shoved full adts frames into mkv for some retarded reason, the decoder can deal with that just fine on its own
[21:47:55] <bcoudurier> PARSE_HEADERS must only call "fetch params"
[21:48:00] <Yuvi> full adts in mkv is a spec violation
[21:48:02] <bcoudurier> and not cut the stream
[21:48:13] <peloverde> Yuvi, FFmpeg does it by default
[21:48:17] <bcoudurier> look at other parsers
[21:48:22] <peloverde> then that's a bug in the aac_parser
[21:48:30] <peloverde> which is whomever is the parser mainters problem
[21:48:55] <bcoudurier> nice
[21:49:13] <bcoudurier> are you angry at something ?
[21:49:51] <Yuvi> from what source / isn't GLOBAL_HEADERS supposed to specify raw aac?
[21:49:51] <BBB> I think we bug him too much about aac problems that he didn't cause ;)
[21:49:56] <peloverde> I went though this same exact situation with the gstreamer people for *months*
[21:50:36] <BBB> Dark_Shikari: re-ping
[21:50:39] <Dark_Shikari> pong
[21:50:44] <BBB> Dark_Shikari: qcelp ;)
[21:50:50] <Dark_Shikari> I'm waiting for a link.
[21:50:52] <BBB> (ok, not exactly 20 min, but close enough)
[21:51:11] <BBB> Dark_Shikari: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107976
[21:51:26] <BBB> specifically http://people.gnome.org/~rbultje/ff/ r1-3.wav
[21:51:40] <Yuvi> btw, is there any reason (besides parsers that appear to modify the bitstream) to not make PARSE_HEADERS the default?
[21:51:41] <BBB> if you wish, also look at resampled-dec-qt.wav, but you don't have to
[21:51:48] <Yuvi> for everything
[21:51:55] <Dark_Shikari> BBB: which ones
[21:51:59] <Dark_Shikari> ok, r1-3
[21:52:02] <BBB> yeah
[21:52:47] <bcoudurier> peloverde, I understand the frustration
[21:53:27] <BBB> peloverde: renaming aac_parser would help a lot, I was confused by it also
[21:53:51] <peloverde> I find file renames too bikesheddy to participate in
[21:54:08] <peloverde> plus again I am not the maintainer
[21:54:17] <BBB> hmk
[21:54:25] <BBB> non-maintainers are allowed to submit patches
[21:54:33] <Dark_Shikari> BBB: 2 > 3 > 1
[21:54:49] <peloverde> BBB, then feel free to submit a patch :)
[21:55:06] <bcoudurier> ...
[21:55:15] <astrange> it's impolite to rank samples without abxing first
[21:55:19] <BBB> Dark_Shikari: can you do that on-list?
[21:55:27] <Yuvi> peloverde: ffmpeg -acodec aac blah.mkv seems to do raw aac, is it something else that does adts?
[21:55:45] <peloverde> Yuvi, do a stream copy from an adts file
[21:55:58] <Dark_Shikari> BBB: why
[21:56:08] <BBB> Dark_Shikari: so I have documentation of this test
[21:56:08] <peloverde> Yuvi, ffmpeg -i file.aac -acodec copy blah.mkv
[21:56:20] <Dark_Shikari> mru: very nice bikeshed argument going there btw
[21:56:21] <Dark_Shikari> congrats
[21:56:23] <BBB> Dark_Shikari: alternatively, can I c/p that sentence in an email on-list?
[21:56:38] <Dark_Shikari> sure.
[21:56:50] <Dark_Shikari> oh hmm, just realized I tested with the noise sharpening postprocessor on
[21:56:53] <Dark_Shikari> I wonder if that changes the results.
[21:56:58] <BastyCDGS> IFF-ANIM now reads all chunks
[21:56:59] <peloverde> is there a parser to look at that differentiates between parse_headers and parse_full?
[21:57:16] <Dark_Shikari> hmm, doesn't seem so.  no HF content in the source anyways
[21:57:25] <peloverde> sometimes I really think we should treat adts as a muxed format
[21:57:27] <BastyCDGS> just have now to figure out how to ensure that each frame gets one unique image
[21:57:35] <peloverde> it would solve a ton of problems
[21:57:45] <mru> peloverde: but mpeg-[pt]s carries adts
[21:57:48] <Yuvi> peloverde: I agree, is there any reason (e.g. same problems as latm) not to?
[21:57:54] <peloverde> mru, chaindemux
[21:57:59] <mru> we don't have that
[21:58:11] <Dark_Shikari> we do
[21:58:12] <Dark_Shikari> dv in mov
[21:58:12] <bcoudurier> have fun
[21:58:14] <Dark_Shikari> etc
[21:58:19] <peloverde> dv in mov
[21:58:23] <bcoudurier> dv is fixed frame size
[21:58:23] <BBB> asf in rtsp
[21:58:24] <mru> we don't have proper chaindemux
[21:58:27] <mru> only piles of hacks
[21:58:28] <BBB> mru: true
[21:58:33] <Dark_Shikari> we can do vorbis in ogg in avi!
[21:58:35] <mru> because some people refuse to realise the need for it
[21:58:43] <mru> there are specs for mpegts in mp4
[21:58:45] <Dark_Shikari> mru: we totally need to support ogg in avi!
[21:58:51] <peloverde> pseudochaindemux seems less hackish than the giant pile of adts hacks we have
[21:58:53] <kierank> [22:57] <@Yuvi> peloverde: I agree, is there any reason (e.g. same problems as latm) not to? --> and 337m
[21:58:59] <kierank> I would like to see this too
[21:59:01] <peloverde> and the completely stalled LATM situation
[21:59:03] <bcoudurier> what adts hacks ?
[21:59:09] <kierank> it would remove current dirty hacks I have in my tree as well
[21:59:20] <mru> latm in ts in mp4...
[21:59:31] <mru> in http in ip in mpegts
[21:59:34] <bcoudurier> oh you guys are good a complaingin
[21:59:46] <bcoudurier> international ranking
[21:59:53] <peloverde> sometimes a bsf is needed with ADTS sometimes it isn't the users have no idea
[22:00:16] <bcoudurier> how can 337m need a demuxer on his own ?
[22:00:27] <bcoudurier> peloverde, a _lot_ of SDKs supports 3 forms
[22:00:32] <bcoudurier> adts, raw, latm
[22:01:10] <kierank> bcoudurier: as we discussed a while ago the idea of having multiple programs that the container views as only 1
[22:01:53] <BBB> BastyCDGS: good work so far, keep it uop
[22:01:54] <peloverde> bcoudurier, then you explain to users why then need a magical incantation to properly remux adts files
[22:02:13] <BBB> BastyCDGS: I'm hoping that you sort of get a feel of the way demuxers/decoders are done in ffmpeg this way
[22:02:14] <bcoudurier> you don't need to explain them
[22:02:16] <kierank> dolby e in 337m in 302m in ts is going to be very ugly
[22:02:18] <bcoudurier> you reformat in the muxer
[22:02:25] <bcoudurier> like the ts/mp4 muxer does
[22:02:41] <bcoudurier> or you add a mechanism to automatically insert a bitstream filter
[22:02:48] <bcoudurier> or you add the code to do that in ffmpeg.c
[22:02:48] <BastyCDGS> I got already a bit thanks to the bug fixing stuff
[22:02:58] <bcoudurier> seriously there are _tons_ of way to do it
[22:03:01] <BastyCDGS> with this knowledge it makes it lots easier
[22:03:02] <bcoudurier> but you guys complain
[22:03:28] <bcoudurier> if you are lazy but have something _working_
[22:03:33] <bcoudurier> I'm _ok_ with it
[22:03:37] <bcoudurier> and will say so on the ml
[22:03:49] <bcoudurier> we must stop find excuses
[22:03:54] <peloverde> bcoudurier, no it doesn't
[22:03:56] <bcoudurier> finding
[22:04:18] <bcoudurier> doesn't what ?
[22:04:29] <peloverde> ffmpeg -i al18_64.adts -acodec copy copy.mp4
[22:04:37] <bcoudurier> not mp4
[22:04:46] <bcoudurier> err not aac
[22:04:48] <bcoudurier> but h264
[22:04:58] <bcoudurier> ts does mp4 -> adts automatically though
[22:05:08] <bcoudurier> depending on the usage
[22:05:15] <peloverde> and I quote: "6D 64 61 74 FF F0"
[22:05:24] <BastyCDGS> Input #0, IFF, from '../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows':
[22:05:24] <BastyCDGS>   Duration: N/A, bitrate: N/A
[22:05:24] <BastyCDGS>     Stream #0.0: Video: iff_anim, pal8, 320x200, PAR 10:11 DAR 16:11, 90k tbr, 90k tbn, 90k tbc
[22:05:30] <BastyCDGS> but no window yet :(
[22:06:08] <BastyCDGS> [iff_anim @ 0x8b30730]palette data underflow
[22:06:08] <BastyCDGS> ../../ffmpeg-svn.orig/patches/anim-j/BoingThrows/BoingThrows: could not open codecs
[22:06:37] <bcoudurier> in any case, I don't see what you are trying to prove
[22:07:38] <BBB> BastyCDGS: that's because no video is decoded yet
[22:07:45] <BBB> BastyCDGS: you need to make a video decoder next
[22:07:48] <peloverde> If it's so trivial then why don't the demuxers you maintain support it?
[22:07:49] <BBB> only then do you see video being displayed
[22:08:10] <BastyCDGS> no the first image is standard IFF-ILBM
[22:08:17] <BastyCDGS> this should be shown already
[22:08:23] <BastyCDGS> the special stuff starts with the delta frames
[22:08:49] <bcoudurier> what are you talking about
[22:09:01] <bcoudurier> have we add so many request for adts to mp4 ?
[22:09:09] <bcoudurier> _no_
[22:09:16] <bcoudurier> then I don't see the point
[22:09:22] <BastyCDGS> a wait this is a stub right now, just try it with calling the original for a moment
[22:09:29] <bcoudurier> however mp4 -> ts
[22:09:32] <bcoudurier> _yes_
[22:09:35] <bcoudurier> so the ts muxer does it
[22:09:44] <Yuvi> doesn't mp4 only allow raw aac?
[22:09:48] <bcoudurier> if you want to do it feel free to do so
[22:09:54] <bcoudurier> wtf
[22:10:00] <bcoudurier> if you don't, don't complain
[22:10:01] <BBB> BastyCDGS: right, your decoder is a stub
[22:10:01] <peloverde> plenty of people remux adts aac to mp4
[22:10:07] <BBB> BastyCDGS: so change that first
[22:10:09] <bcoudurier> not using ffmpeg
[22:10:16] <bcoudurier> and I don't see any bugreport
[22:10:16] <peloverde> and ffmpeg happily creates a broken stream
[22:10:28] <bcoudurier> so what ? it's a bug
[22:10:30] <peloverde> but ffmpeg and faad will happily play the broken stream
[22:10:34] <peloverde> so most don't notice
[22:10:41] <peloverde> but it's still wildly out of spec
[22:10:52] <bcoudurier> so in other words it's not a big deal
[22:11:00] <peloverde> there are tons of mp4s in the wild that have whole adts frames in them
[22:11:16] <Yuvi> quicktime won't play such files for one
[22:11:17] <peloverde> it's a big deal because it's out of spec
[22:11:19] <bcoudurier> well I guess that was meant to happen
[22:11:27] <peloverde> and other implementations don't support it
[22:11:44] <bcoudurier> there's only one rule
[22:11:47] <bcoudurier> people complaining
[22:11:53] <bcoudurier> do users complain ?
[22:12:06] <bcoudurier> I don't see that many
[22:12:22] <bcoudurier> would people complain if they had to add -vbsf h264_annexbtomp4 every time ?
[22:12:25] <bcoudurier> _yes-
[22:12:29] <peloverde> FAAC encodes 5.1 aac as SCE.0 CPE.0 CPE.0 LFE.0, completely broken but faad plays it so no problem, right? wrong it buts heads with features faad doens't support makign supporting that brokeness in ffmpeg a nightmare
[22:12:31] <bcoudurier> so mp4 muxer does it internally
[22:12:48] <bcoudurier> it's easier for everybody
[22:13:09] <peloverde> people don't complain because ti seems to work, then the file is subtly broken when they take it elsewhere
[22:13:12] <bcoudurier> well, avi is borken
[22:13:13] <BBB> guys, don't kill each other please
[22:13:18] <bcoudurier> if you don't play broken avis
[22:13:22] <bcoudurier> you play 20% of avis
[22:13:27] <bcoudurier> and people will use something else
[22:13:32] <bcoudurier> it's up to you
[22:13:45] <peloverde> when did avi come up?
[22:13:52] <Yuvi> this isn't about playing broken files, it's about generating them and adding to the brokeness problem
[22:14:13] <peloverde> Yuvi: correct
[22:14:29] <_Jonas_> hi all, i have found a small buffer overflow bug, http://pastie.org/926949
[22:14:34] <peloverde> standards should be followed strictly for output
[22:14:36] <BastyCDGS> I have found the issue with the colormap
[22:14:45] <BastyCDGS> it's because HAM & EHB aren't supported yet
[22:15:15] <BastyCDGS> i.e. 4096 color mode and 262144 color mode
[22:15:47] <peloverde> and the problem is that this doesn't just happen with mp4, it happens with every single muxer that uses a aac with a global header
[22:17:17] <BastyCDGS> what about dropping that crazy iff.h stuff I added and use IffDemuxContext instead
[22:17:24] <BastyCDGS> like I did with position storing
[22:17:44] <_Jonas_> or is this the wrong channel for this ?
[22:18:52] <Yuvi> for aac, is ts the only container we support muxing for that requires adts?
[22:18:59] <peloverde> _Jonas_, file something in the bug tracker so it doesn't get lost
[22:20:02] <peloverde> The ADTS muxer creates ADTS
[22:20:12] <peloverde> but interestingly it requires the data in mp4 format
[22:22:11] <bcoudurier> creating broken files is a bug
[22:22:23] <bcoudurier> and I'm not talking about this problem
[22:22:31] <bcoudurier> no
[22:22:34] <bcoudurier> the adts muxer supports both
[22:22:38] <BastyCDGS> not if you're microsoft then it's a feature haha
[22:22:44] <bcoudurier> it will parse extradata if it is present
[22:22:51] <bcoudurier> like the ts muxer
[22:23:30] <BBB> BastyCDGS: that's indeed the idea, to continue using iffdemuxcontext for this stuff
[22:23:39] <BBB> (demuxing-related)
[22:27:10] <Yuvi> hm, does anything support both raw aac and adts, or could we just assume GLOBAL_HEADERS == raw, and adts otherwise?
[22:27:20] <Yuvi> for muxing
[22:29:00] <Yuvi> well the second half worn't work
[22:29:06] <bcoudurier> we should be able to assume that
[22:29:43] * peloverde looks at all the duplication between the adts muxer and the aac decoder
[22:32:47] <peloverde> also for what it's worth the ADTS muxer doesn't seem to remux adts streams at all, merely pass them though
[22:34:03] <bcoudurier> what's the problem ?
[22:34:14] <bcoudurier> factorizing code is welcome
[22:34:25] <peloverde> I didn't say it's a problem, I said for what it's worth
[22:34:50] <peloverde> people may try to remux shoddily muxed adts files and wonder why they are still shoddily muxed
[22:35:03] <peloverde> i.e. bad adts_buffer_fullness
[22:35:17] <bcoudurier> ...
[22:35:23] <peloverde> or try to remove the crc
[22:35:40] <bcoudurier> you should relax a bit
[22:35:40] <peloverde> or want to normalize everything as mpeg-4
[22:35:51] <BastyCDGS> did a commit to ml for iff-anim
[22:35:56] <bcoudurier> feel free to fix things
[22:36:08] <peloverde> I've spent a lot of time thinking about how to make the adts muxer more flexible
[22:36:34] <bcoudurier> you can do whatever you want
[22:36:52] <bcoudurier> with the adts muxer
[22:36:52] <bcoudurier> seriously
[22:37:13] <peloverde> do we have some sort of normalize/super-remux flag
[22:37:15] <bcoudurier> well for what is worth it seems the bitstream filter is not flexible at all
[22:37:25] <bcoudurier> feel free to add it
[22:39:17] <BastyCDGS> is there a way to set panning in ffmpeg in audio sample?
[22:39:30] <BastyCDGS> i ask because iff-anim has 3 modes, left, right, center
[22:39:47] <BastyCDGS> want do set pan to 0x80 (if ranges from 0-255) for center mode
[22:40:24] <bcoudurier> [NULL @ 0x3084d00]Multiple RDBs per frame with CRC is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a feature which has not been implemented.
[22:40:24] <bcoudurier> aac_adtstoasc failed for stream 0, codec copy: Operation not permitted
[22:40:57] <peloverde> Are you filtering something with multiple RDBs?
[22:41:12] <BBB> BastyCDGS: ? what's that?
[22:41:23] <peloverde> All I know is that people constantly yammer on about how AAC is completely unnecessary because we have MP3 or Vorbis or AC-3 already, then constantly complain to me about how broken FFmpeg's AAC support is when the only brokenness that is actually my fault is the encoder
[22:41:26] <BastyCDGS> panning? stereo position...
[22:41:40] <bcoudurier> I really don't blame you
[22:41:53] <BBB> BastyCDGS: "ffmpeg" has no panning, the decoder should take care of that, no?
[22:41:59] <BastyCDGS> 0 is left, 255 is right, 128 is center, 64 would be left channel 75% of volume, right channel 25%
[22:42:13] <bcoudurier> the aac file is from mp4
[22:42:15] <BBB> is that part of the audio packet?
[22:42:17] <bcoudurier> -acodec copy test.aac
[22:42:20] <BastyCDGS> yes
[22:42:24] <BastyCDGS> audio pkt
[22:42:25] <bcoudurier> either the parser did fuck up
[22:42:28] <bcoudurier> or something is wrong
[22:42:44] <BastyCDGS> so I will solve this by output the same sample on left and right channel
[22:43:02] <BBB> BastyCDGS: uh ok, but again, focus on video, not audio
[22:43:09] <BBB> for now, video is your task, not audio ;)
[22:43:24] <bcoudurier> AAC is clearly useful
[22:43:58] <bcoudurier> I don't know who tells you about mp3 and ac-3
[22:44:04] <bcoudurier> everybody use aac
[22:44:19] <peloverde> ffmpeg -i in.mp4 -abs aac_adtstoasc out.aac?
[22:44:35] <peloverde> ATSC uses AC-3
[22:44:45] <bcoudurier> nope
[22:44:57] <bcoudurier> -i in.mp4 -acodec copy out.aac
[22:45:11] <peloverde> how is that giving you bsf errors?
[22:45:11] <bcoudurier> then out.aac -absf aac_adtstoasc test.mp4
[22:45:15] <peloverde> ahhh
[22:45:18] <BastyCDGS> bbb, this is hard considering you're all talking about audio stuff all the time *gg*
[22:45:32] <BBB> BastyCDGS: well, ffmpeg is 50% video and 50% audio
[22:45:40] <bcoudurier> I was making the muxer to abort if aac is missing extradata
[22:45:46] <bcoudurier> so I tested
[22:45:47] <BBB> and several of us on irc know more about audio than video, I guess
[22:46:04] <bcoudurier> well radio uses he-aac
[22:46:11] <bcoudurier> web is using aac
[22:46:32] <bcoudurier> tv's support aac now
[22:47:06] <peloverde> half the web seems to think that MPEG codecs are a giant conspiracy
[22:47:29] <bcoudurier> don't listen to freetards ;)
[22:47:42] <bcoudurier> they make a lot of noise indeed
[22:48:52] <BBB> +1 to that
[22:49:10] <BBB> peloverde: the corporate world, which is what will pay for your job now and forever after, amen, is all mpeg codec
[22:49:34] <BBB> peloverde: many still use mp3, but there's a lot of aac+ nowadays
[22:49:52] <BBB> and don't forget the biggest website in the world, youtube, which uses aac
[22:50:02] <BBB> facebook, hulu, etc.
[22:50:03] * Kovensky wonders if anyone but eroge companies use mp2
[22:50:06] <Kovensky> +s
[22:50:27] <bcoudurier> mp2 is still used much in broadcast
[22:50:45] <bcoudurier> but they work at 384kb anyway
[22:51:27] <bcoudurier> for 5.1 they go pcm since the bitrates used for hd are so high anyway
[22:51:41] <mru> there's a lot of ac3 too
[22:51:45] <BastyCDGS> BBB: can i access IffDemuxContext from a decoder or must I use IffContext there?
[22:51:47] <bcoudurier> not in broadcast
[22:51:50] <bcoudurier> for iptv
[22:51:50] <mru> sure is
[22:52:00] <mru> directv-hd is all ac3
[22:52:01] <bcoudurier> you are talking about iptv
[22:52:05] <mru> sat
[22:52:08] <bcoudurier> or sat same
[22:52:16] <bcoudurier> the copy on the server is not ac3
[22:52:21] <mru> and atsc is ac3
[22:52:23] <bcoudurier> it's dolby-e
[22:52:25] <mru> a/52
[22:52:30] <bcoudurier> or pcm
[22:52:49] <bcoudurier> yes that's for sat/iptv
[22:52:56] <mru> and atsc terrestrial
[22:53:00] <bcoudurier> ie the last end to the consumer
[22:53:01] <mru> it's mp2 and ac3
[22:53:23] <BastyCDGS> one question, is there something like a decryptor layer for stuff like blu-ray copy protection and decss?
[22:53:42] <bcoudurier> they don't receive that as a master
[22:53:42] <mru> it's much harder than css to break
[22:53:44] <mru> but it can be done
[22:53:51] <BBB> BastyCDGS: iffcontext
[22:54:15] <mru> or did you mean a generic decryption layer in ffmpeg
[22:54:16] <BBB> BastyCDGS: anything that needs to go from demuxer to decoder (setitngs or so) should go in the AVPacket or in the AVCodecContext, I'll help you with that tomorrow
[22:54:18] <BBB> gotta go now
[22:54:39] <peloverde> "ffmpeg -i al00_44.mp4 -acodec copy copy.adts; ffmpeg -i copy.adts -acodec copy -absf aac_adtstoasc out.mp4" seems to work for me
[22:54:55] <BBB> BastyCDGS: there's some decryption code in ffmpeg, but it needs a lot of work... so nothing useful for dvd/bluray
[22:55:10] <BastyCDGS> i meant more a framework
[22:55:25] <BastyCDGS> which links in between demuxer and decoder
[22:56:01] <bcoudurier> peloverde, uploading Pirates3.mov in incoming
[22:56:08] <peloverde> ok
[22:56:30] <bcoudurier> aac-lc created by apple
[22:58:08] <BBB> BastyCDGS: there's no such thing yet right now
[22:58:34] <BastyCDGS> what about avfilter? isn't that a similar thing?
[23:01:41] <BBB> avfilter is for filtering decoded video/audio
[23:01:54] <BBB> think noise reduction for audio or rotation for video
[23:02:05] <BBB> deinterlacing, etc.
[23:05:38] <BastyCDGS> what about a libavdecrypt?
[23:05:44] <BastyCDGS> just an idea for a name
[23:06:50] <BastyCDGS> or just libavcrypt (for encrypting possibilities)
[23:07:02] <BastyCDGS> could also also GPG signed movies with ffmpeg able to verify signature ;)
[23:07:54] <BastyCDGS> no fake bin laden movies anymore *g*
[23:08:45] <peloverde> GPG signed movies sound kind of busy
[23:08:55] <peloverde> err cool
[23:15:00] <BastyCDGS> normally it would take some time to verify a 1:30h movie (due to it's file length)
[23:15:16] <BastyCDGS> with such a thing like libavcrypt it could verify it during playback
[23:15:29] <BastyCDGS> and when the movie is finished you get the result of verification
[23:15:48] <mru> and get told you just wasted two hours watching a fake film
[23:16:46] <BastyCDGS> at least you know it then ;)
[23:17:26] * kierank senses some really crazy idea
[23:17:31] <BastyCDGS> but that's just an idea which spontaneously came into my mind, maybe some of you are interested int this...
[23:18:06] <kierank> to be honest it made no sense whatsoever
[23:19:56] <BastyCDGS> sure, for normal kind of movies it's no sense, but imagine being a NGO where there might be guys interested into making the NGO unseriously and releasing fakes in the name of them
[23:20:16] <BastyCDGS> the usecase is proably more or less the same like GPG in mails
[23:20:33] <drv> surely you could just verify the whole file with gpg? :)
[23:21:03] <janneg> calculating the sha256 of a 700M file takes 20 seconds (empty caches, 5400rpm notebook drive)
[23:21:30] <BastyCDGS> that's always an option...;)
[23:22:00] <janneg> 7s user time
[23:23:08] <BastyCDGS> where you are mentioning sha256 you can even do this blockwise, thus even while watching it, just sha the frame ;)
[23:23:27] <mru> to what end?
[23:24:29] <BastyCDGS> but GPG was just another example, libavcrypt is more useful for css and hdmi stuff, undoubtfully
[23:24:50] <mru> hdcp is done at the link level
[23:24:56] <mru> by hardware
[23:25:39] <BastyCDGS> if it becomes the signal from software to do it...
[23:25:55] <BastyCDGS> but it wouldn't get active, if ffmpeg would decrypt it by own ;)
[23:25:57] <mru> that's outside the scope of ffmpeg
[23:26:28] <mru> ffmpeg only goes as far as decoding and a bit of post-filtering
[23:26:49] <mru> hdcp is handled by the display driver
[23:29:11] <BastyCDGS> it isn't really a high (not even medium) priority for me either...thought is as a long term project if at all
[23:29:59] <janneg> are there even hdmi capture devices?
[23:31:57] <kierank> yes
[23:32:20] <kierank> some of them can strip hdmi as well
[23:32:49] <janneg> s/hdmi/hdcp/?
[23:33:16] <mru> janneg: ever heard of a tv?
[23:33:57] <janneg> yes, even of tvs running ffmpeg
[23:34:08] <kierank> janneg,yes
[23:34:28] <mru> I doubt the hdmi signal goes to ffmpeg though
[23:34:41] <mru> they use ffmpeg for decoding stuff from other sources
[23:34:44] <janneg> but I doubt the processor of the tv has access to the hdmi signal though
[23:35:40] <janneg> I'm still looking for use cases of hdcp decoding in ffmpeg
[23:35:42] <kierank> mru: I thought it was just using ffmpeg for demuxing in the tvs?
[23:35:59] <mru> I've no idea what they use it for
[23:36:12] <mru> but I'm sure it's nothing to do with raw video from hdmi
[23:41:08] <janneg> wtf: samung has distributes a ffmpeg.zip of the full svn checkout, i.e. including .svn dirs
[23:41:19] <Dark_Shikari> Seems easy enough
[23:41:26] <Dark_Shikari> was it samsung that had that massive wtf of code modifications?
[23:41:39] <mru> they had some weird changes
[23:41:48] <mru> but they're playing by the rules
[23:41:53] <mru> in a nice way even
[23:41:56] <BastyCDGS> did they released the changes within GPG
[23:42:00] <BastyCDGS> ah ok
[23:42:29] <mru> the full svn checkout means it's easy to see exactly what they did
[23:42:52] <mru> we've seen others who release some bizarre hybrid of multiple revisions mixed up with their own changes
[23:43:22] <janneg> 33 files changed, 2569 insertions(+), 518 deletions(-)
[23:44:11] <janneg> they even ship their config.h|mak
[23:44:55] <kierank> hehe they added latm
[23:46:14] <kierank> and drm metadata crap
[23:46:23] <janneg> and AES decryption to the mpegts demuxer
[23:47:06] <kierank> weird, aes seems to be for the freesat spec
[23:47:39] <kierank> weird that totally fta satellite service would need that
[23:47:42] <kierank> a*
[23:48:17] <kierank> ah, it's for bbc iplayer
[23:48:31] <BastyCDGS> do you plan to add any of the samsung stuff into ffmpeg mainline tree?
[23:48:59] <peloverde> I believe we've picked over it a few times already
[23:52:29] <bcoudurier> latm ? :)
[23:52:32] <bcoudurier> they made it work hehe
[23:52:53] <peloverde> they don't have to remux anything
[23:53:07] <janneg> some version of paul kendall's patches
[23:54:10] <bcoudurier> remux is another step IMHO
[23:54:31] <bcoudurier> if decoding works, they can transcode at least
[23:54:53] <peloverde> because transcode is usually a good option with lossy audio
[23:56:07] <janneg> and they aren't even using it. it requires libfaad and they don't enable it
[23:56:19] <bcoudurier> it's _better_ than nothing in all cases !
[23:56:49] <bcoudurier> seriously, this is depressing
[23:56:54] <peloverde> or we could just chain demux
[23:57:06] <bcoudurier> then work on it
[23:57:16] <peloverde> we already support chaindemux
[23:57:26] <peloverde> see dv in mov and ogg vorbis in avi
[23:57:37] <bcoudurier> ??
[23:57:57] <Dark_Shikari> we don't support ogg in avi
[23:57:59] <bcoudurier> add chaindemux in the mpegts demuxer
[23:58:03] <bcoudurier> if you wanbt
[23:58:09] <bcoudurier> I don't fucking care
[23:58:15] <bcoudurier> do what you want but make it work !
[23:58:22] <bcoudurier> and stop complaining
[23:58:39] <peloverde> you're the one complaining IIRC
[23:58:47] <bcoudurier> are you kidding me ?
[23:59:01] <peloverde> you were the one bitching about the parser
[23:59:08] <bcoudurier> I only hear you complaining here
[23:59:33] <bcoudurier> I'm not bitching about it
[23:59:37] <bcoudurier> I'm asking you for solutions
[23:59:40] <bcoudurier> on getting the aac frame size
[23:59:45] <bcoudurier> your answer ?