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

[burek]

[00:37] <CIA-41> ffmpeg: 03Martin Storsjö 07master * rc66495c6d7 10ffmpeg/configure: 
[00:37] <CIA-41> ffmpeg: configure: Add a dependency on https for rtmpts
[00:37] <CIA-41> ffmpeg: The rtmpts protocol uses https implicitly, via the ffrtmphttp
[00:37] <CIA-41> ffmpeg: protocol, but the ffrtmphttp protocol is also useable for plain
[00:37] <CIA-41> ffmpeg: rtmpt without https, so the dependency needs to be added here instead.
[00:37] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[00:37] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rdc31b84cbf 10ffmpeg/libavformat/rtmpproto.c: 
[00:37] <CIA-41> ffmpeg: rtmpproto: fix compilation without optimizations
[00:37] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:56] <CIA-41> ffmpeg: 03yang 07master * r6a2bad2c4f 10ffmpeg/libavcodec/x86/dsputil_mmx.c: (log message trimmed)
[00:56] <CIA-41> ffmpeg: dsputil_mmx: fix incorrect assembly code
[00:56] <CIA-41> ffmpeg: In file libavcodec/x86/dsputil_mmx.c, function ff_put_pixels_clamped_mmx(), there are two assembly code blocks. In the first block (in the unrolled loop), the instructions "movq 8%3, %%mm1 \n\t" etc have problem.
[00:56] <CIA-41> ffmpeg: For above instruction, it is clear what the programmer wants: a load from p + 8.
[00:56] <CIA-41> ffmpeg: But this assembly code doesnt guarantee that. It only works if the compiler
[00:56] <CIA-41> ffmpeg: puts p in a register to produce an instruction like this: movq 8(%edi), %mm1.
[00:56] <CIA-41> ffmpeg: During compiler optimization, it is possible that the compiler will be able to
[01:43] <CIA-41> ffmpeg: 03Alexander Strasser 07master * r3f22fcce3a 10ffmpeg/tools/bisect-create: 
[01:43] <CIA-41> ffmpeg: tools/bisect-create: Support "bisect run"
[01:43] <CIA-41> ffmpeg:  Make it possible to use the run bisect sub command. As with all
[01:43] <CIA-41> ffmpeg: other ffbisect commands, revisions that do not contain the needed
[01:43] <CIA-41> ffmpeg: tools are skipped.
[01:43] <CIA-41> ffmpeg: Signed-off-by: Alexander Strasser <eclipse7 at gmx.net>
[03:05] <Hawk-TAO> gentlemen
[03:06] <Daemon404> http://i3.kym-cdn.com/entries/icons/original/000/000/088/Gentlemen.jpg
[03:08] <Hawk-TAO> i spent time to analyse the code,but i cannt know how is the actual parameter passed to the function pointer    s->read_packet = read_packet; 
[03:09] <Hawk-TAO> aviobuf.c line 86
[03:09] <durandal_1707> that function pointer is used by library itself
[03:11] <Hawk-TAO> but how is the actual parameter passed to it?
[03:11] <durandal_1707> by the caller
[03:12] <Hawk-TAO> this is the caller     *s = avio_alloc_context(buffer, buffer_size, h->flags & AVIO_FLAG_WRITE, h,
[03:12] <Hawk-TAO>                             (void*)ffurl_read, (void*)ffurl_write, (void*)ffurl_seek);
[03:13] <Hawk-TAO> http://pastebin.com/X290puXR
[03:13] <Hawk-TAO> but where is the actual parameter?
[03:14] <durandal_1707> no, that is not caller
[03:15] <Hawk-TAO> ?
[03:15] <Hawk-TAO> but where is the caller?
[03:18] <Hawk-TAO> help me,plz
[03:18] <durandal_1707> this is basic understanding of C
[03:20] <Hawk-TAO> sorry,i really didnt find the actual parameter. 
[03:21] <Hawk-TAO> callback function?
[03:23] <durandal_1707> michaelni: having two iff video decoders is bad, they should be merged
[03:42] <Compn> hmm
[03:42] <Compn> kind of annoying
[03:43] <durandal_1707> ?
[03:43] <Compn> wbs : you going to add hyc and other rtmpdump author copyright into rtmp code ?
[03:44] <Compn> since there afaict some copy / paste and its at least based on it for sure
[03:48] <Hawk-TAO> thx,i have find it,
[03:48] <Hawk-TAO> see you,have a good dream
[04:03] <burek> does ffmpeg have support for this: http://en.wikipedia.org/wiki/Cinavia
[04:12] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r697edcc12a 10ffmpeg/libavcodec/vc1dec.c: 
[04:12] <CIA-41> ffmpeg: vc1dec: dont attempt error concealment on field pictures.
[04:12] <CIA-41> ffmpeg: This is not implemented and doesnt work.
[04:12] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:13] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r2e346bdaba 10ffmpeg/libavcodec/error_resilience.c: 
[04:13] <CIA-41> ffmpeg: ec: print picture type with concealment error message.
[04:13] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:13] <michaelni> durandal_1707, you mean iff_ilbm and iff_byterun1 ?
[04:13] <durandal_1707> yep
[04:14] <juanmabc> all fixes done, http://code.google.com/p/openmedialibrary got 0.2.4 without issues :D
[04:14] <juanmabc> for the record it has a just openal counterpart: http://code.google.com/p/openalextensions
[04:15] <juanmabc> now, don't move so much api in a while, he ;D
[04:15] <durandal_1707> juanmabc: you are asking that on wrong channel
[04:15] <michaelni> durandal_1707, can the 2 be distinguished from the bitstream ?
[04:15] <michaelni> if so merging should be easy
[04:16] <juanmabc> durandal_1707: it is more so you know an opengl/al implementation that to announce it
[04:16] <durandal_1707> bitstream? compression is set in header and this header should be before frame data, like with cdxl
[04:17] <durandal_1707> juanmabc: these days most of api changes comes from libav
[04:17] <juanmabc> no worries, i was semi kidding, though for real it has to work in some time
[04:18] <juanmabc> i know sws_freeContext is not going to forever once sws_free makes it, ...
[04:21] <juanmabc> at some point libav and ffmpeg has to start differentiating, if not whats the point of forking if they share patches
[04:23] <juanmabc> the most difficult thing for me was sinking, the rest was up in like half hour
[04:24] <juanmabc> though examples/documentation are laacking, ffplay.c is pretty messy (despite awesome powerful)
[04:24] <juanmabc> you seem to concentrate a lot on features but put together without design concern, code looks awful
[04:26] <juanmabc> its a drawback of how you made so much codec power?, i guess :D
[04:26] <juanmabc> </end>
[04:27] <durandal_1707> it mostly have nothing to do with number of codecs....
[04:27] <juanmabc> design wise is where you have been working, and where not
[04:28] <juanmabc> ffplay.c and friends need love
[04:29] <michaelni> ffplay.c actually has a active maintainer
[04:29] <michaelni> if theres some issue or suggestions, maybe drop him a mail ...
[04:30] <juanmabc> i could, details hack on some design without adding features for once ;)
[04:31] <juanmabc> where i could find its address?
[04:32] <juanmabc> mmm, there seems to be a trunk/MAINTAINERS file
[04:35] <juanmabc> he, isn't me or it is *you* michaelni???
[04:35] <juanmabc> cool
[04:36] <michaelni> ffplay.c                              Marton Balint
[04:37] <juanmabc> oh, so it changed in the while
[04:38] <juanmabc> i'm fonna post in ffmpeg-devel at ffmpeg.org
[04:38] <juanmabc> thanks
[04:39] <juanmabc> just so it looks better some day
[04:41] <durandal_1707> what to looks better?
[04:43] <juanmabc> is programming design course, not programming features course
[04:43] <juanmabc> that you got ok
[04:44] <durandal_1707> ok, so what looks ugly and need to look better?
[04:51] <juanmabc> globals, lack of structs, no task splitting, no multi backend support, ... an ffplay folder to grow is what i ended suggesting
[04:51] <juanmabc> all together in one file, is the start of the mess
[04:52] <juanmabc> i find weird, you support so many codecs, but just sdl backend
[04:52] <Compn> http://cryptome.org/2012/07/david-house-gj-notes.htm
[04:52] <durandal_1707> ffplay is just known hack
[04:53] <durandal_1707> the right way is to rewrite libavdevice api and let ffplay use it
[04:53] <Compn> juanmabc : i made a wishlist that ffplay should port mplayer's libvo system (or vlcs system, or any thing similar)
[04:53] <durandal_1707> Compn: not ffplay, but libavdevice
[04:55] <juanmabc> what's libvo video output backend?
[04:56] <juanmabc> add ao to that then
[04:56] <Compn> mplayer also has libao2
[04:56] <Compn> the backends are just every supported interface
[04:57] <Compn> directx, gl , x11 / xv / xvmc , vdpau etc
[05:00] <durandal_1707> michaelni: lavc/iff.c have potential out of memory condition:  s->mask_palbuf = av_malloc((2 << s->bpp) * sizeof(uint32_t) + FF_INPUT_BUFFER_PADDING_SIZE);
[05:01] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r22ce78a95e 10ffmpeg/ (libavcodec/vc1dec.c tests/ref/fate/vc1_sa10143): 
[05:01] <CIA-41> ffmpeg: vc1dec: dont apply the loop filter on fields
[05:01] <CIA-41> ffmpeg: Fixes read of uninitialized memory
[05:01] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:21] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r0e1925ddc4 10ffmpeg/libavcodec/iff.c: 
[05:21] <CIA-41> ffmpeg: iffdec: Fix integer overflow.
[05:21] <CIA-41> ffmpeg: Found-by: durandal_1707
[05:21] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:23] <durandal_1707> michaelni: av_append_packet seems to not work if called first
[05:24] <durandal_1707> probably becase packet->size is not 0 when read_packet is called
[14:56] <crtmpserver> hello
[14:56] <michaelni> hello
[14:57] <crtmpserver> I think I found a problem with hls.c
[14:57] <crtmpserver> when the input is an HLS source (ffmpeg -i http://some.com/test.m3u8 &)
[14:58] <crtmpserver> if the source has B-Frames inside it (dts!=pts)
[14:58] <crtmpserver> the pakets generated from that source have wrong timestamps
[14:58] <crtmpserver> also, when I ust pick up one chunk from that hls, it works perfectly
[14:59] <crtmpserver> I mean, the B-framesare preserved
[15:00] <crtmpserver> I can provide a http link to a HLS stream
[15:00] <michaelni> crtmpserver, if you havnt already please submit a bug report (see http://ffmpeg.org/bugreports.html) that is unless you have a patch to fix it :)
[15:00] <crtmpserver> and also the command used
[15:00] <crtmpserver> got it
[15:00] <crtmpserver> tx
[16:16] <crtmpserver> michaelni, I created the ticket
[16:16] <crtmpserver> willing to create the fix, but I need some guidance 
[16:31] <michaelni> crtmpserver1, try -debug_ts and see if theres a difference
[16:34] <michaelni> crtmpserver, also check what is feeded in the flv muxer (printf/av_log pkt->dts/pts before av_interleaved_write_frame() in ffmpeg.c)
[16:45] <crtmpserver1> I printed out the pkt dts/pts just before putting them on the flv file inside flvenc.c
[16:45] <crtmpserver1> as i suspected, the pts/dts are completely different from what I get from mpegts demuxer
[16:46] <crtmpserver1> somewhere along the formats chain, packets changes pts/dts
[16:46] <crtmpserver1> libavformat/mpegts.c: 2087: 3834824994; DTS: 3834815985;
[16:47] <crtmpserver1> sorry
[16:47] <crtmpserver1> libavformat/mpegts.c: 2087: PTS: 3834815985; DTS: 3834806976;
[16:47] <crtmpserver1> and when it hits flvenc.c I get this:
[16:48] <crtmpserver1> libavformat/flvenc.c:  551: PTS: 2369; DTS: 2369;
[16:48] <crtmpserver1> the problem is not that they are normalize to 0 timebase
[16:48] <crtmpserver1> the problem is that pts and dts values are the same (basically, no dts)
[16:49] <crtmpserver1> dts info was lost for good, making the resulted flv inconsistent
[16:49] <crtmpserver1> same goes for mp4 output
[17:01] <ubitux> sorry to interrupt; just a simple question: there is no way to inline yasm code right?
[17:04] <funman> no i think gcc always uses gas
[17:04] <ubitux> mmh?
[17:05] <ubitux> i mean, the question is about inline external function definition written in "yasm" style
[17:05] <ubitux> inlining*
[17:05] <ubitux> to avoid the call overhead
[17:05] <funman> ah sorry i read inline asm
[17:06] <funman> with macro perhaps?
[17:06] <ubitux> i don't see how
[17:07] <funman> hmm inline a yasm function call into C ?
[17:07] <ubitux> yes
[17:07] <funman> gcc won't know how to remove call overhead
[17:08] <ubitux> what are the reasons for wanting to move inline asm to yasm?
[17:08] <ubitux> (apart from "it's ugly")
[17:09] <funman> i don't remember
[17:09] <funman> probably using yasm macros but that's only good for new code
[17:10] <durandal_1707> there are compilers that dont support inline asm....
[17:11] <funman> ubitux: perhaps that could be a feature for clang?
[17:11] <ubitux> clang doesn't support it? oO
[17:12] <ubitux> maybe ICC doesn't?
[17:12] <funman> no i mean disassembling foreign objects and remove call overhead ot inline
[17:12] <funman> clang is fine with inline asm
[17:12] <ubitux> i guess the linker couldn't do it?
[17:13] <ubitux> mmh it would required adding space in the object 
[17:13] <kierank> ubitux: yasm is much easier to work with
[17:13] <kierank> easier to add things like avx
[17:14] <ubitux> ok
[17:14] <wbs> Compn: fixed
[17:16] <michaelni> crtmpserver,  if what flvenc gets differs, check what you get from av_read_frame() then you know if ffmpeg.c messes it up
[17:17] <michaelni> next check what hls/mpegts return to libavformat (that is av_log in their read_packet)
[17:17] <Compn> wbs : thx
[17:17] <michaelni> then you know if its the demuxer of lavf core
[17:18] <michaelni> oR
[17:20] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r01272e7662 10ffmpeg/libavformat/utils.c: 
[17:20] <CIA-41> ffmpeg: Revert "lavf: count skipped samples for initial timestamps."
[17:20] <CIA-41> ffmpeg: This reverts commit 885fc058655efee94203314984ce99b301fdebb1.
[17:20] <CIA-41> ffmpeg: This commit caused timestamps in case of generic seeking to become
[17:20] <CIA-41> ffmpeg: inconsistent.
[18:19] <crtmpserver1> av_read_frame is messing things up in hls.c
[18:19] <crtmpserver1> when the pkt comes out of that function, the damage is already done
[18:52] <michaelni> crtmpserver if you have good timestamps at some point and bad ones later you can "bisect" the code with av_logs until you find where its messed up
[18:53] <michaelni> if i know where its messed up i can probably fix it
[19:02] <CIA-41> ffmpeg: 03Piotr Bandurski 07master * rb9c129be0f 10ffmpeg/libavformat/riff.c: 
[19:02] <CIA-41> ffmpeg: riff: fix remuxing of G723_1 in wav
[19:02] <CIA-41> ffmpeg: Attached patch fixes remuxing of G723.1 in wav, so the output is playable by WMP.
[19:02] <CIA-41> ffmpeg: (It's still not enough for encoding - probably some extradata should be added to the output file
[19:02] <CIA-41> ffmpeg: to make it playable by WMP/win codec)
[19:02] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:30] <CIA-41> ffmpeg: 03Nicolas George 07master * r3ccf22c64a 10ffmpeg/ffmpeg.c: 
[19:30] <CIA-41> ffmpeg: ffmpeg: keep packet/frame availability in global structures.
[19:30] <CIA-41> ffmpeg: This replaces the use of the no_packet and no_frame arrays.
[19:57] <crtmpserver1> they are all messed up. not a single DTS timestamp is present on the output
[20:49] <saste> michaelni: can you comment on ticket #1386?
[20:49] <saste> https://ffmpeg.org/trac/ffmpeg/ticket/1386
[20:49] <saste> in particular, why coded_w/h overrides w/h set in the codec context?
[20:54] <aiguu> Hello all-- I am curious if ffmpeg has any checks and/or implements Intel's quick sync video instructions?
[20:55] <aiguu> Or is it in the works?
[21:01] <kierank> no because quick sync is a closed box
[21:15] <aiguu> I thought there were a number of open source ffdshow filters and tools using it 
[21:15] <aiguu> http://sourceforge.net/projects/qsdecoder/
[21:16] <kierank> probably using the decoder yes
[21:16] <kierank> but that should work using dxva
[21:17] <aiguu> I was hoping if it was a matter of CPU, it could be integrated into the decoding function and used if available rather than explicitly doing :p 
[21:30] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r65d94f63ca 10ffmpeg/libavcodec/aacdec.c: 
[21:30] <CIA-41> ffmpeg: aac: Mention abbreviation as well in long_name
[21:30] <CIA-41> ffmpeg: Most people know the codec as "AAC" and not "Advanced Audio Coding".
[21:30] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r816ff352a3 10ffmpeg/doc/git-howto.texi: doc: Add Git configuration section
[21:30] <CIA-41> ffmpeg: 03Martin Storsjö 07master * r6c1ed45483 10ffmpeg/configure: 
[21:30] <CIA-41> ffmpeg: configure: Add a dependency on https for rtmpts
[21:30] <CIA-41> ffmpeg: The rtmpts protocol uses https implicitly, via the ffrtmphttp
[21:30] <CIA-41> ffmpeg: protocol, but the ffrtmphttp protocol is also useable for plain
[21:30] <CIA-41> ffmpeg: rtmpt without https, so the dependency needs to be added here instead.
[21:30] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:30] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r6b80142144 10ffmpeg/libavformat/Makefile: 
[21:30] <CIA-41> ffmpeg: build: Skip compiling rtmpdh.h if ffrtmpcrypt protocol is not enabled
[21:30] <CIA-41> ffmpeg: The ffrtmpcrypt protocol depends on external libraries, which are
[21:30] <CIA-41> ffmpeg: also required to compile the header file.
[21:30] <CIA-41> ffmpeg: 03Martin Storsjö 07master * r6a433fdba8 10ffmpeg/libavformat/ (rtmpcrypt.c rtmpdh.c): 
[21:30] <CIA-41> ffmpeg: rtmp: Add credit/copyright to librtmp authors for parts of the RTMPE code
[21:30] <CIA-41> ffmpeg: Our implementation of RTMPE is heavily based on librtmp.
[21:30] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:30] <CIA-41> ffmpeg: 03Samuel Pitoiset 07master * rf7bfb126cd 10ffmpeg/libavformat/rtmpproto.c: 
[21:30] <CIA-41> ffmpeg: rtmp: Move the CONFIG_ condition into the if conditions
[21:30] <CIA-41> ffmpeg: This makes sure these calls are removed by dead code elimination
[21:31] <CIA-41> ffmpeg:  rtmp: Move the CONFIG_ condition into the if conditions
[21:31] <CIA-41> ffmpeg:  aac: Mention abbreviation as well in long_name
[21:31] <CIA-41> ffmpeg:  build: Skip compiling rtmpdh.h if ffrtmpcrypt protocol is not enabled
[21:31] <CIA-41> ffmpeg: 03Adriano Pallavicino 07master * r999c63e4ca 10ffmpeg/libavformat/rtp.c: 
[21:31] <CIA-41> ffmpeg: rtp: Only choose static payload types if the sample rate and channels are right
[21:31] <CIA-41> ffmpeg: If using a different sample rate or number of channels, use a dynamic
[21:31] <CIA-41> ffmpeg: payload type instead, where the parameters are passed in the SDP.
[21:31] <CIA-41> ffmpeg: G722 is a special case where the normal rules don't apply.
[21:31] <CIA-41> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:44] <ramiro> where can I access the samples uploaded for the issue tracker?
[21:45] <saste> ola ramiro, nice to see you :)
[21:45] <saste> and no i can't help, maybe Compn?
[21:46] <ramiro> saste: =)
[21:47] <michaelni> saste, coded_width has to be used or things like lowres would probably break
[21:48] <saste> michaelni: do you have idea why it is set to a value different from w in the sample?
[21:48] <michaelni> ramiro, http://streams.videolan.org/incoming/ ?
[21:48] <michaelni> saste, h264 croping (pure guess)
[21:49] <michaelni> ramiro, or do you mean something else than the ftp ?
[21:52] <saste> michaelni: the sample is vp6f, could it be a bug in the decoder?
[21:52] <nevcairiel> vp6f also defines cropping
[21:52] <ramiro> michaelni: thanks, I found the file
[21:52] <nevcairiel> its quite normal for width to diverge from coded_width, but it should always be less then 16, ie less then a macroblock
[21:53] <saste> well avcodec_open sets w/h to coded_w/h if they are set, so i don't really know where (if?) the problem is
[21:54] <nevcairiel> vp6f puts its cropping into extradata and the decoder should re-apply it after init or after decoding of first frame
[21:54] <nevcairiel> i dont remember when it does it
[21:54] <saste> what i know is that the decoded frame size is different from the size set in coded_w/h, but this is the value set in the codec context
[22:03] <Compn> whats
[22:03] <Compn> hi saste / ramiro :)
[22:04] <ramiro> Compn: hi
[22:08] <Compn> so many logins
[23:10] <burek> can anyone suggest a good source to populate this table http://ffmpeg.org/trac/ffmpeg/wiki/SupportedMediaTypesInFormats
[23:10] <burek> basically, which format supports which codecs
[23:11] <saste> burek: write a script which tries every format in turn, and report if the combination is valid
[23:12] <saste> right now that's the only way, since the list of supported codecs is not exposed
[23:12] <burek> I see, but if the ffmpeg doesn't complaint, does it mean it is really supported?
[23:12] <burek> complain*
[23:13] <saste> supposing the command is simple enough, that could give some indication
[23:14] <saste> but not that could be more complicate
[23:14] <burek> ok, I'll try, thanks :)