[FFmpeg-devel-irc] IRC log for 2010-07-11

[irc at mansr.com]

[00:01:55] <Kovensky> hm
[00:02:00] <Kovensky> seems that I missed when the header actually got fixed
[00:02:16] <mru> there could have been a temporary glitch
[00:02:17] <Kovensky> libavutil/pixdesc.h had a few inline functions that used intreadwrite stuff
[00:02:45] <mru> I remember pixdesc.h using endian definitions from config.h
[00:02:49] <mru> we fixed that
[00:03:02] <Kovensky> (the deprecated func is avcodec_get_pix_fmt, the new one was av_get_pix_fmt but when I tried fixing the warning it would fail)
[00:05:45] <saintd3v> peloverde: what are scalefactor bands vs. scalefactor window bands?
[00:08:21] <CIA-99> ffmpeg: vitor * r24181 /trunk/tests/ (ref/fate/yop fate2.mak): Psygnosis YOP demuxer and decoder test
[02:54:01] <mru> lol @ michael's response to german comments in patch
[02:57:23] <Dark_Shikari> which thread?
[04:11:18] <_av500_> A64 encoder
[04:12:31] <Dark_Shikari> lol
[07:55:03] <_av500_> woot: avcodec_decode_audio4
[07:55:45] <_av500_> i wonder if it is going to overtake 0.x releases
[08:00:25] <kshishkov> FFmpeg 1.0 will use avcodec_{de,en}code_{audio,video}42
[08:01:15] <_av500_> that will output samples in XML?
[08:02:01] <kshishkov> of course - libavcodec replaced with libavxslt
[08:04:12] <_av500_> kshishkov: its sunday, go to the park, ride a steam train!
[08:04:18] <pross-au> 42 lol
[08:04:40] <pross-au> kshishkov: we are gonna need an xml parser sooon
[08:04:48] <_av500_> pross-au: you could have smuggled 42 in as a typo
[08:05:06] <kshishkov> _av500_: I'm not from sunny Serbia, it's too hot for me to go outside
[08:05:21] <_av500_> pross-au: why not use any of the 375 existing xml parser libs :)
[08:05:45] <kshishkov> idiotic question - we don't like using external libs
[08:06:13] <pross-au> because ours will be better
[08:06:53] <_av500_> kshishkov: iKnow. btw, at some time I found out that our own SW here used 3 different xml parser libs...
[08:07:12] <pross-au> same problem here _av500_
[08:07:17] <Yuvi> at the same time?
[08:07:32] <_av500_> Yuvi: for different sub modules
[08:07:49] <_av500_> each guy that needed xml brought in another lib it seems
[08:07:52] <xxthink> http://pastebin.org/389226
[08:07:58] <xxthink> this is the transcoding log
[08:08:02] <pross-au> its a common design pattern _av500_
[08:08:05] <xxthink> I transcodea ts to mp4
[08:08:21] <xxthink> But the video and audio can't be synchronized correctly
[08:08:22] <pross-au> "i prefer lib foo so im gonna use it"
[08:08:43] <_av500_> pross-au: its more like "I will not read any of the existing sourse code"
[08:09:06] <pross-au> actually thats my biggest complain about software engineers.
[08:09:27] <xxthink> The problem is I can't make sure the audio and video start time because there aren't PTS infor in the first packet of audio and video
[08:09:28] * _av500_ thinks about patching his libc to output NO_PTS instead of -9223372036854775808
[08:10:38] <xxthink> _av500_: yes. But if there isn't PTS info in the first packet
[08:10:51] <xxthink> How to decide its PTS ?
[08:11:04] <_av500_> xxthink: no idea, I would consider such a file broken
[08:11:47] * _av500_ would drop all stuff until PTS && key_frame
[08:11:51] <xxthink> _av500_: But now ffmpeg considers its PTS is 0
[08:12:06] <xxthink> I also think these packets should be dropped
[08:12:13] <_av500_> xxthink: well, that is about the best guess it can make, no?
[08:12:39] <xxthink> _av500_: but it can't make sure this method is correct
[08:12:52] <xxthink> sometimes it will cause problems
[08:13:04] <_av500_> i dont doubt that
[08:13:11] <xxthink> why?
[08:13:28] <xxthink> you agree with the current method?
[08:13:49] <_av500_> i have not looked much into current method
[08:13:59] <xxthink> ok
[08:14:17] <_av500_> xxthink: where is this file from?
[08:14:35] <xxthink> I have a TS file,
[08:14:41] <xxthink> But the audio is in Chinese
[08:14:51] <xxthink> So I can find it is not correct
[08:15:23] <xxthink> this TS file is record from the Cable TV
[08:16:23] <xxthink> But this TS file can be displayed correctly by mplayer
[08:16:46] <xxthink> so I don't know how mplayer treat this packets?
[08:17:49] <_av500_> xxthink: playing is much easier than transcoding
[08:18:03] <_av500_> you can send no pts frame to the decoder, but not to the muxer
[08:18:35] <xxthink> but the player should decide its PTS correctly
[08:18:47] <_av500_> its only a few frames
[08:18:49] <_av500_> i guess
[08:19:03] <_av500_> so the player can just output them without timing
[08:19:03] <_av500_> thats what i do
[08:19:21] <xxthink> i c
[08:20:27] <jai> ffmpeg needs an xml parser?
[08:20:36] <xxthink> so one method for transcoding is discard all these frames
[08:20:43] <_av500_> jai: for enterprise customers
[08:20:50] <jai> xspf? some tracker format?
[08:20:57] <jai> _av500_: of course :)
[08:24:50] * kshishkov waits for superdump to create profiles for FFmpeg in XML
[09:21:38] <mru> mornings
[09:21:52] * elenril has only one morning here
[09:22:02] * mru gives elenril some of his spares
[09:22:20] <elenril> w00t, thanks
[09:22:40] <mru> when you work from home, you easily accumulate lots of unused mornings
[09:27:05] <kshishkov> goda morgnar
[09:27:21] <kshishkov> you'll need them soon
[09:27:58] <mru> nah, german clocks show an hour more, so it's not as early there
[09:47:52] <kshishkov> actually it's Russian clocks that show an hour more than it's really is
[09:48:25] <mru> no, they're even more ahead
[09:49:00] <mru> everybody knows the best time is in greenwich
[09:49:49] <kshishkov> yep, but compared to neighbouring countries they have skewed clocks
[09:49:51] <Honoome> species at this time of the year
[10:15:26] <CIA-99> ffmpeg: pross * r24182 /trunk/libavcodec/avcodec.h: Fix trivial punctuation error
[10:15:26] <CIA-99> ffmpeg: skal * r24183 /trunk/libavcodec/libvorbis.c: use avccontext->frame_size where appropriate
[10:15:39] <CIA-99> ffmpeg: skal * r24184 /trunk/libavcodec/libvorbis.c: add some buffer checks
[10:15:39] <CIA-99> ffmpeg: reimar * r24185 /trunk/ (4 files in 3 dirs): Add avsubtitle_free function.
[10:15:39] <CIA-99> ffmpeg: reimar * r24186 /trunk/libavcodec/dvbsubdec.c: Remove useless casts and memset.
[10:15:40] <CIA-99> ffmpeg: reimar * r24187 /trunk/libavcodec/pgssubdec.c: Set pix_fmt to the correct value for the format the PGS decoder actually uses.
[10:15:50] <CIA-99> ffmpeg: reimar * r24188 /trunk/libavcodec/utils.c: 100l, change avsubtitle_free to the actually tested and working version.
[11:29:37] <CIA-99> ffmpeg: mstorsjo * r24189 /trunk/libavformat/ (Makefile mp3.c):
[11:29:37] <CIA-99> ffmpeg: Fix ID3v1 tags in mp3 files
[11:29:37] <CIA-99> ffmpeg: Patch by James Darnley, james dot darnley at gmail
[11:50:36] <CIA-99> ffmpeg: stefano * r24190 /trunk/ (libavutil/avutil.h doc/APIchanges):
[11:50:36] <CIA-99> ffmpeg: Update lavu minor and add APIchanges entry after r24174 (add bswap.h
[11:50:36] <CIA-99> ffmpeg: and intreadwrite.h API public interface).
[11:55:37] <CIA-99> ffmpeg: lu_zero * r24191 /trunk/libavformat/rtpdec_h264.c:
[11:55:37] <CIA-99> ffmpeg: Handle av_base64_decode return value
[11:55:37] <CIA-99> ffmpeg: garbled sdp would cause crash otherwise.
[11:57:47] <CIA-99> ffmpeg: stefano * r24192 /trunk/doc/ffmpeg-doc.texi:
[11:57:47] <CIA-99> ffmpeg: Fix crop filter syntax shown for the -crop* options in the ffmpeg man
[11:57:47] <CIA-99> ffmpeg: page.
[11:57:47] <CIA-99> ffmpeg: Patch by Stefan de Konink /$name/@/konink/de.
[12:03:55] <lu_zero> mru: poing
[12:04:03] <mru> pong
[12:04:20] <lu_zero> vp8 is broken on big-endian or just ppc?
[12:04:32] <mru> only ppc with gcc 4.0.4
[12:04:39] <lu_zero> -_-
[12:04:42] <lu_zero> it's ancient
[12:04:46] <mru> yeah
[12:04:57] <mru> shall we officially not support it?
[12:05:26] <kshishkov> depends on the reason
[12:05:35] <mru> it miscompiles stuff
[12:05:43] <kshishkov> so does every compiler
[12:05:54] <lu_zero> I'd ask for a 4.1
[12:05:59] <mru> it miscompiles ffmpeg where most other versions work
[12:06:11] <kshishkov> and it's 4.0 ... ok then
[12:13:51] <lu_zero> fun
[12:14:16] <lu_zero> asking for an h264 elementary stream using -vcodec copy generates garbage...
[12:14:27] <mru> from mp4?
[12:14:35] <lu_zero> do we have already a topic about it?
[12:14:46] <mru> you need -vbsf h264_mp4toannexb
[12:14:46] <lu_zero> mru: yup
[12:15:35] <lu_zero> I wonder if it's feasible adding a warning
[12:18:09] <_av500_> "here be dragons"
[12:25:58] <lu_zero> hic sunt leones you meant
[12:45:22] <CIA-99> ffmpeg: vitor * r24193 /trunk/tests/ (ref/fate/pictor fate2.mak): Add Pictor/PC Paint PIC regtest
[12:48:15] <peloverde> saintdev: scalefactor window bands = scalefactor bands within a window, scalefactor band
[12:48:15] <peloverde>  = scalefactor band within a window group
[12:48:26] <peloverde> For long windows the two are identical
[12:48:49] <peloverde> num_swb is the top band, max_sfb is the top transmitted band (the rest are implicitly zero)
[13:18:47] * mru @ airport
[13:19:52] <mru> android wifi AP working fine :-)
[13:21:15] <wbs> ah, the new stuff in 2.2?
[13:21:29] <mru> yeah
[13:22:04] <wbs> good thing that that is available now. had to set up the inofficial tethering using openvpn and whatnot once, when the only connection I had was on the phone
[13:22:41] <wbs> so browsing and downloading and RTFMing on the phone, moving binaries to the computer and trying to set it up there
[13:23:36] <mru> heh
[14:06:27] <CIA-99> ffmpeg: vitor * r24194 /trunk/tests/fate2.mak: DTS Coherent Acoustics regtest
[14:14:13] <CIA-99> ffmpeg: vitor * r24195 /trunk/tests/fate2.mak: NellyMoser regtest
[14:28:56] * mru out
[14:30:25] <kshishkov> sounds like asm
[14:44:03] <zorgy7> hi guys, does anyone know what the values: ff_mjpeg_bits_dc_luminance, ff_mjpeg_bits_dc_chrominance and ffm_mjpeg_val_dc are?
[14:44:22] <zorgy7> they are located in mjpeg.c
[14:45:33] <CIA-99> ffmpeg: victor * r24196 /trunk/libavfilter/ (avfilter.c vf_scale.c defaults.c): Use avfilter_copy_picref_props() along lavfi.
[14:47:53] <kshishkov> zorgy7: should be obvious if you know at least a little bit about JPEG coding
[14:48:28] <zorgy7> kshishkov: yea :( i have no idea of JPEG coding
[14:49:20] <zorgy7> so i can find out more if i look into the encoding/decoding algorithm for jpeg?
[14:50:41] <kshishkov> of course
[14:51:07] <CIA-99> ffmpeg: kostya * r24197 /trunk/libavcodec/truespeech.c:
[14:51:07] <CIA-99> ffmpeg: Do not try to decode less than one frame of data in TrueSpeech decoder.
[14:51:08] <CIA-99> ffmpeg: This should solve issue 2085.
[14:51:20] <zorgy7> okay
[14:57:22] <CIA-99> ffmpeg: victor * r24198 /trunk/libavformat/avformat.h: Clarify the avoidance of usage of these AVStream fields.
[15:20:01] <Compn> doh where is j-b ?
[15:30:33] <kshishkov> in France, obviously
[15:31:24] <janneg> Compn: on vacation
[15:31:33] <Compn> ah
[15:31:47] <Compn> was going to ask him if vlc's ftp had any dvb/mpegts subtitle samples
[15:32:38] <janneg> Compn: are you looking for something special
[15:33:41] * janneg is pretty sure that samples has some. if not I can upload some
[15:34:32] <Compn> reimar wanted more dvb subs and some special dvb vbi teletext too, and any other mpeg subtitles that werent working 100% in mplayer ...
[15:35:11] <Compn> see thread 'mpeg-ts (pgs) subtitle support' on dev-eng
[15:35:16] <janneg> dvb vbi teletext is on my todo list
[15:35:54] <Compn> well tell reimar that so you guys dont duplicate work :)
[15:37:17] <Compn> janneg : btw do you have an account at videolans' trac ? the sample url is 404 here and itd be nice if uploader fixed it >> http://trac.videolan.org/vlc/ticket/3461
[15:39:17] <janneg> Compn: just looking through my samples for dvb vbi teletext
[15:40:19] <janneg> and I have no account for videolan's trac, asking in #vlc would probably help
[15:40:42] <Compn> so it goes :)
[15:43:20] <BBB> Dark_Shikari: ping
[16:39:26] <lu_zero> the gsoc webapp is still broken?
[16:57:12] <CIA-99> ffmpeg: jbr * r24199 /trunk/ (8 files in 2 dirs):
[16:57:12] <CIA-99> ffmpeg: Add AVCodecContext.lpc_type and Add AVCodecContext.lpc_passes fields.
[16:57:12] <CIA-99> ffmpeg: Add AVLPCType enum.
[16:57:12] <CIA-99> ffmpeg: Deprecate AVCodecContext.use_lpc.
[16:58:12] <CIA-99> ffmpeg: jbr * r24200 /trunk/doc/APIchanges: Fill-in revision number for addition of lpc_type and lpc_passes.
[17:14:25] <nfl> how do I force more data to be passed to decode_frame() as compared to that being passed currently for a particular frame?
[17:14:50] <nfl> I need 24B, but get only 16B and it isn't EOF yet
[17:22:05] <kshishkov> something is wrong with your approach then
[17:22:08] <kshishkov> what codec?
[17:22:18] <nfl> g723.1
[17:22:38] <kshishkov> why do you need more data?
[17:23:04] <nfl> for the particular frame type, I need 24 bytes
[17:23:36] <kshishkov> sounds like your parser should handle that
[17:24:02] <kshishkov> I'm pretty sure there's no way to make decode_frame() ask for more bytes
[17:24:12] <nfl> I was asked to set CODEC_CAP_SUBFRAMES instead of using a parser :)
[17:25:09] <kshishkov> still, if some frames are of bigger size, request it - you can signal that you have not consumed all data
[17:25:23] <nfl> that is what I do currently
[17:25:40] <nfl> return the no. of bytes consumed for the current frame
[17:26:06] <nfl> so what exactly does CODEC_CAP_SUBFRAMES indicate?
[17:27:19] <kshishkov> that your actual frame data contains several frames
[17:27:37] <kshishkov> and codec may use it partially to output several buffers of data
[17:28:25] <nfl> so I take it that a parser is the only way out?
[17:28:56] <kshishkov> nope
[17:29:23] <nfl> what else can I do then?
[17:30:35] <kshishkov> ask on ML with all statements clear - why you need more data sometimes and why you can't get it with current approach
[17:32:00] <nfl> ok
[17:32:11] <kshishkov> that should be better than asking here
[17:43:20] <wbs> the decoder can simply output nothing (without returning an error) and buffer the data internally, too
[17:43:36] <wbs> the mpeg audio decoder used to do that up until a few years ago
[17:44:25] <wbs> the api-example.c in lavc relied upon that, see the changes in the log of that file when I fixed it for the new behaviour of the decoder a while back
[17:46:45] <nfl> ok
[17:47:35] <CIA-99> ffmpeg: cehoyos * r24201 /trunk/libavcodec/libvpxenc.c:
[17:47:35] <CIA-99> ffmpeg: Set libvpx encoding profile to libavcodec's profile.
[17:47:35] <CIA-99> ffmpeg: Patch by James Zern, jzern google
[17:52:37] <wbs> nfl: where are you receiving the data from? usually, you wouldn't feed incomplete frames to a decoder (but you could want to feed more than one frame)
[17:53:04] <nfl> wbs: from a file
[17:53:18] <kshishkov> wbs: that's why I'd like to see it in a mail - easier to understand
[17:58:11] <nfl> wbs: so this is what I will do: store the 16B in a buffer, return 16, in the next call, append 8B to the buffer and return 8. sounds ok?
[17:58:41] <nfl> *sound
[17:59:03] <CIA-99> ffmpeg: jbr * r24202 /trunk/doc/APIchanges: APIchanges: fix a grammar mistake
[18:03:20] <lu_zero> uhm?
[18:03:49] * lu_zero reads the email
[18:04:50] <lu_zero> wbs: I'm planting more verbose error reporting in ffrtsp and ffrtp, once I'm done I'll need your help picking up what's missing
[18:05:21] * lu_zero is actively feeding broken streams while messing with feng
[18:25:08] <kierank> what's the easiest way of getting samples which are doubles into something i can listen to?
[18:25:25] <kierank> to verify that the decoding works
[18:26:56] <wbs> lu_zero: oh, nice :-)
[18:31:31] <wbs> nfl: yes. that's one way of solving it. do you blindly read chunks of data from the file that you pass to the decoder?
[18:32:15] <nfl> blindly?
[18:32:57] <wbs> as in, you don't know how large the frames are at that point, so you may cut the frames and feed incomplete frames to the decoder?
[18:33:31] <nfl> yes
[18:33:32] <wbs> normally, the demuxer would read from the file using at least some kind of framing, returning data in packets containing one or more full frames
[18:34:12] <wbs> if you don't have such a demuxer, you can either use a parser, make the decoder handle the case as we discussed earlier, or
[18:34:45] <wbs> refill the buffer when the number of bytes left is getting small, as we do in api-example.c right now
[18:35:04] <wbs> the last case doesn't fit into ffmpeg.c though
[18:35:04] <nfl> I use raw.c to read in the file contents
[18:36:12] <wbs> kshishkov: sorry for taking the discussion here instead of on the ML, i'm in a sotuation where irc is easier than mail atm
[18:36:31] <wbs> but I guess I can recap the situation in a ML reply in a moment
[18:53:24] <wbs> kshishkov, nfl: summarized as a reply on -soc
[18:59:28] <nfl> wbs: thanks
[19:13:19] <lu_zero> uhmmm
[19:13:28] <lu_zero> sdp_parse looks overoptimistic...
[22:18:10] <CIA-99> ffmpeg: ramiro * r24203 /trunk/configure:
[22:18:11] <CIA-99> ffmpeg: mingw32: properly check if vfw capture is supported by the system headers
[22:18:11] <CIA-99> ffmpeg: Remove check for an specific w32api version, checking instead if vfw.h
[22:18:11] <CIA-99> ffmpeg: supports vfw capture. The defines in w32api 3.12 were wrong, so this must be
[22:18:11] <CIA-99> ffmpeg: accounted for in the check.
[22:32:34] <CIA-99> ffmpeg: ramiro * r24204 /trunk/configure: mingw32: merge checks for mingw-w64 and mingw32-runtime >= 3.15 into one
[22:53:39] <CIA-99> ffmpeg: conrad * r24205 /trunk/libavcodec/vc1dec.c: vc1: ff_draw_horiz_band needs a one row delay when the loop filter is active
[22:53:41] <CIA-99> ffmpeg: conrad * r24206 /trunk/libavcodec/vc1dec.c:
[22:53:41] <CIA-99> ffmpeg: vc1: Fix ordering of loop filter for I/B frames
[22:53:41] <CIA-99> ffmpeg: All horizontal edges must be filtered before all vertical edges
[22:53:41] <CIA-99> ffmpeg: conrad * r24207 /trunk/libavcodec/x86/ (4 files): Make ff_pw_4 128 bits
[22:53:41] <CIA-99> ffmpeg: conrad * r24208 /trunk/libavcodec/x86/ (Makefile vc1dsp_mmx.c x86util.asm vc1dsp_yasm.asm): MMX/SSE VC1 loop filter