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

[burek]

[00:02] <durandal_1707> yes
[00:18] <BBB> why is ThreadFrame->progress an AvBufferRef?
[00:19] <durandal_1707> huh?
[00:19] <BBB> thread.h
[00:19] <BBB>     AVBufferRef *progress;
[00:19] <BBB> why?
[00:24] <durandal_1707> ask anton?
[00:30] <durandal_1707> ask anton3
[03:11] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:46312fc2a95a: cmdutils: dont change the log level for -report
[03:50] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:5dba888dd564: msmpeg4: Fix ff_msmpeg4_pred_dc() so it works with lowres>0
[07:45] <j-b> Good morning
[08:52] <cone-758> ffmpeg.git 03Hendrik Leppkes 07release/0.10:5e6135f68d77: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[08:52] <cone-758> ffmpeg.git 03Hendrik Leppkes 07release/0.11:274ec187dcc6: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[08:52] <cone-758> ffmpeg.git 03Hendrik Leppkes 07release/1.0:491f2e517d92: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[08:52] <cone-758> ffmpeg.git 03Hendrik Leppkes 07release/1.1:24dc6b1a06d6: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[08:52] <cone-758> ffmpeg.git 03Hendrik Leppkes 07release/1.2:1065d4197e97: mathops/x86: work around inline asm miscompilation with GCC 4.8.1
[10:25] <cone-758> ffmpeg.git 03Diego Biurrun 07master:6dc6598692da: configure: Simplify an expression with enabled_all.
[10:25] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:1152863a3f1b: Merge commit '6dc6598692da3b0ebda2d768681786343f26a4f4'
[10:48] <cone-758> ffmpeg.git 03Diego Biurrun 07master:ace87c19ed4c: configure: whitespace cosmetics
[10:48] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:14a61bc3f9ad: Merge commit 'ace87c19ed4c4882d7b9b3ce512c4c195e39a203'
[11:11] <cone-758> ffmpeg.git 03Kieran Kunhya 07master:95d52464542f: lavc: Add option to encode MPEG-2 AAC with libfdk-aac
[11:11] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:af5f9c08763b: Merge commit '95d52464542f532061290192518d5fe1c1930e8d'
[11:32] <cone-758> ffmpeg.git 03Rafaël Carré 07master:c3e58f8fb75d: matroskaenc: restore compatibility with non referenced AVPacket
[11:32] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:a620c8321efc: Merge commit 'c3e58f8fb75d8467161a65b85eb88281547ebab1'
[11:48] <cone-758> ffmpeg.git 03Rafaël Carré 07master:e21307a2b024: lavf: don't abort if both encoder and muxer aspect ratios are not set
[11:49] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:f48366c7040a: Merge remote-tracking branch 'qatar/master'
[12:52] <ubitux> wm4: not sure i'll update the smi demuxer/decoder soon, but sure feel free to share
[13:04] <ubitux> haha the jpeg2k vs jpeg2000 thread is getting seriously ridiculous :))
[13:07] <durandal_1707> really? drama ended yesterday
[13:08] <ubitux> durandal_1707: i'm a bit out of time :)
[14:29] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:a46e578ddacd: avformat/avio: Fix EOF handiling of ffurl_read_complete()
[16:11] <cone-758> ffmpeg.git 03Michael Niedermayer 07master:bbe26eff2235: h264: Fix null pointer dereference with disabled error concealment
[17:36] <khali> ah, one more bug found in the delogo filter..
[21:40] <wm4> so it seems libavformat's mp3 demuxer doesn't actually real embedded id3v2 tags
[21:41] <wm4> s/real/read/
[21:42] <wm4> there's only code to skip id3v1 tags (maybe because these are typically at the end of the file and can't be skipped as header?)
[21:44] <Daemon404> doesnt everybody use a separate lib for mp3 stuff
[21:44] <Daemon404> id3lib or w/e it's called
[21:45] <wm4> libavformat appears to have its own id3 code
[21:46] <Daemon404> ive gotten lots of bug reports (via CCCP) about lavf's mp3 demuxer
[21:46] <Daemon404> so much i've just deemed it a crapshoot
[21:46] <JEEB> lol, so far it's one of the least worst @ DirectShow
[21:46] <wm4> it's always wonderful when I try to replace rotten mplayer code with ffmpeg functionality, only to find that mplayer's code worked better
[21:46] <JEEB> it's really the MS splitter that is derp
[21:47] <JEEB> which MS for whatever reason still keeps around
[21:47] <JEEB> even though even WMP hasn't used it for years
[21:47] <JEEB> and thus people complain "but this works in WMP!!!!one-eleven"
[21:48] <wm4> also av_dict_get() sure is a weird API (you iterate all keys by passing key=""?)
[21:48] <durandal11707> wm4: id3 reading thing is not in demuxer itself
[21:48] <wm4> durandal11707: then where is it?
[21:48] <wm4> oh, utils.c?
[21:51] <wm4> I only see code that reads id3 on the start of the file as part of probing and so on
[21:58] <durandal11707> yes, so what you try to acomplish?
[22:00] <wm4> durandal11707: well, first it would be nice if it could recognize and parse embedded id3v2 tags... id3v2 tags can be anywhere, not just the start of the stream, and e.g. web streams appear to use them to update info about newly played song
[22:00] <wm4> +s
[22:00] <wm4> durandal11707: second, I'd like to add shoutcast support... while shoutcast metadata is really simple to read, transferring the info from stream layer to demuxer is not
[22:01] <wm4> I thought about injecting artificial id3 tags, but even then I can't align them on packet boundaries
[22:02] <durandal11707> perhaps you could add to shoutcast metadata some special header so you could make use of it in demuxer....
[22:05] <wm4> handling shoutcast directly in the demuxer would probably be easier
[22:06] <durandal11707> but how would you recognise it?
[22:07] <wm4> well, the shoutcast protocol inserts a variable sized metadata header each N bytes
[22:08] <wm4> what would your "special header" do instead?
[22:11] <durandal11707> and can you recognise such metadata header?
[22:12] <wm4> no, it's implicit (you have to count the bytes you receive)
[22:13] <wm4> if you request shoutcast metadata, it will reply with a Icy-MetaInt header in the http response
[22:13] <wm4> Icy-MetaInt is an integer that sets the data payload size
[22:13] <wm4> so all Icy-MetaInt bytes you get a metadata packet
[22:14] <wm4> with consists of a single byte for the length of the header
[22:14] <wm4> then you can read that header, and after that you get Icy-MetaInt data bytes again
[22:14] <wm4> that's it
[22:27] <wm4> also if I concat two mp3 files, libavformat returns the same length as for the first original file
[22:27] <wm4> weird
[22:39] <durandal11707> wm4: concat with what?
[22:40] <wm4> cat
[22:40] <durandal11707> your own fault than....
[22:40] <wm4> really? I thought mp3 contains no timestamps
[22:46] <wm4> well, maybe it's just the best to let the user read the icy metadata as some sort of out of band data
[22:47] <wm4> so you could get av_opt_get() it
[22:49] <wm4> yeah, probably much better than making up weird hacks
[22:49] <durandal11707> that is ugly, av_opt_get is for options and not for metadata
[22:54] <wm4> durandal11707: mime type is already "returned" via av_opt_get
[22:57] <wm4> and other ideas, like id3v2 injection, don't sound like they'll work any time soon
[23:55] <cone-409> ffmpeg.git 03Michael Niedermayer 07master:8a7aabe80b9b: avfilter/vsrc_testsrc: fix artifacts with odd height
[00:00] --- Tue Jun 25 2013