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

[burek]

[00:03] <sware> or not :)
[00:04] <michaelni> sware, iam sure interrested to see it
[00:04] <michaelni> but iam no msvc user
[00:04] <michaelni> so this is just curiousity
[00:04] <sware> I understand. When I'm done I will share it 
[00:12] <saste> ubitux: you was working on a samples-buffer filter or something like that, right?
[00:12] <saste> because now i need it as well
[00:12] <ubitux> mmh asetframesize? it wasn't
[00:12] <ubitux> +me
[00:12] <ubitux> also now it's should not be necessary anymore
[00:12] <saste> i discovered a nasty behaviour with showwaves
[00:13] <ubitux> ah yes that would simplifies things for the show* filters
[00:13] <ubitux> it will avoid the manual buffering :p
[00:13] <saste> try showwaves with a low samplerate, e.g. 800
[00:13] <saste> or even 8000
[00:14] <ubitux> ok just a minute
[00:14] <ubitux> while i'm rebuilding my tree, did you see these messages?
[00:14] <ubitux> 14:51:45 <@ubitux> saste: i think i'm going to add the scene detection filter to my todo list, if you don't plan to do it soon :)
[00:14] <ubitux> 14:52:22 <@ubitux> saste: oh btw, i noticed something strange the other day; drawtext strftime was using my local time :p
[00:14] <ubitux> 14:52:36 <@ubitux> did you ever expect this?
[00:14] <saste> i don't yet understand why the video playback is choppy, but i suppose it is because you need a lot of audio frames in order to create a single output video
[00:15] <saste> strftime... iirc it will show *local* time
[00:15] <saste> what was you expecting?
[00:15] <ubitux> timestamps :)
[00:15] <ubitux> duration of the movie :p
[00:15] <saste> no, that why you worked on that!!
[00:15] <ubitux> i worked on the timecode, which is slightly different :)
[00:16] <ubitux> but sure using the timecode workaround that issue
[00:16] <saste> strftime... was a feature of the old drawtext, possibly was useful for video surveillance system or $gods know why
[00:16] <saste> i never liked that feature
[00:16] <saste> as for timestamps... we had a lot of proposals, but we never find a good way to show them
[00:17] <saste> indeed what format should we use? how to specify the format?
[00:17] <ubitux> (indeed aresample=8000,asplit[out1],showwaves=s=800x200[out0] is kind of choppy :p)
[00:17] <burek> is it the same to write: -acodec <codec>, -codec:a <codec> and -c:a <codec> ?
[00:17] <saste> a guy proposed a patch but i disliked because it seemed too limited
[00:18] <saste> asetframe... do we have a patch or should i write it from scratch?
[00:18] <saste> *asetframesize
[00:18] <ubitux> yes we have a patch
[00:18] <saste> good
[00:20] <ubitux> it was written by Andrey Utkin
[00:20] <ubitux> i think he is on irc but i forgot his nick
[00:21] <ubitux> saste: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-March/121976.html
[00:52] <CIA-105> ffmpeg: 03Michael Niedermayer 07master * r90290a5150 10ffmpeg/libavcodec/eatqi.c: (log message trimmed)
[00:52] <CIA-105> ffmpeg: tqi: Pass errors from the MB decoder
[00:52] <CIA-105> ffmpeg: This silences some valgrind warnings.
[00:52] <CIA-105> ffmpeg: CC: libav-stable at libav.org
[00:52] <CIA-105> ffmpeg: Fixes second half of http://ffmpeg.org/trac/ffmpeg/ticket/794
[00:52] <CIA-105> ffmpeg: Bug found by: Oana Stratulat
[00:52] <CIA-105> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:52] <CIA-105> ffmpeg: 03Martin Storsjö 07master * r1e8561e369 10ffmpeg/libavformat/flvdec.c: (log message trimmed)
[00:52] <CIA-105> ffmpeg: flvdec: Make sure sample_rate is set to the updated value
[00:52] <CIA-105> ffmpeg: The sample_rate variable is used for checks for audio format
[00:52] <CIA-105> ffmpeg: changes at the end of the function.
[00:52] <CIA-105> ffmpeg: This fixes cases where the sample rate was set from the codec
[00:52] <CIA-105> ffmpeg: id by flv_set_audio_codec (as for nellymoser 8 kHz/16 kHz),
[00:52] <CIA-105> ffmpeg: so the value set to last_sample_rate wasn't equal to sample_rate
[01:06] <Daemon404> michaelni, i figured out the problems i was having.
[01:07] <Daemon404> not an ffmpeg bug, just some bits i missed while using the api
[01:09] <ubitux> Daemon404: i see you are experimenting with lavf, do you mind updating doc/examples/muxing.c if something isn't clear?
[01:09] <michaelni> Daemon404, patch or pull request to improve docs or add some error checks if thats possible, are welcome!
[01:09] <ubitux> like adding comments or anything
[01:10] <Daemon404> there were a few things i tripped over yes
[01:13] <ubitux> michaelni: muxing.c seems not in seek with libav/lavf/output-example.c
[01:13] <ubitux> at least the guess format thing
[01:13] <Daemon404> one think that screwed me right up
[01:13] <ubitux> we have a few more fixes otoh
[01:13] <ubitux> in sync* sorry
[01:13] <Daemon404> was this pkt.size = sizeof(AVPicture) nonesense 'feature' (hack)
[01:14] <Daemon404> which doesnt work for nut
[01:15] <ubitux> ('night)
[01:15] <Daemon404> night
[01:40] <saste> michaelni: nut actually doesn't properly support PAL8 output
[01:42] <saste> also i see that our lavfi test is using the I/O supported by swscale, while the scale filter supports pal8 output
[02:26] <Zeranoe> michaelni: I'm not sure whats different with your patch than mine, but the one you applied doesn't seem to fix the problem. Same error.
[02:37] <Zeranoe> michaelni: I'm sorry for the unneeded patch... It looks like the issue is on MinGW-w64s end...
[05:09] <CIA-119> ffmpeg: 03Michael Bradshaw 07master * rb0e1557fe7 10ffmpeg/libavutil/common.h: 
[05:09] <CIA-119> ffmpeg: Fixed warnings about int64 to int32 conversion
[05:09] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[07:33] <CIA-119> ffmpeg: 03Clément BSsch 07master * rb0b7a89b07 10ffmpeg/libavfilter/af_aresample.c: lavfi/aresample: print channel layouts and formats along with the rate.
[11:10] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rad12e9e8c0 10ffmpeg/ (libavfilter/vf_hflip.c tests/ref/lavfi/pixfmts_hflip): 
[11:10] <CIA-119> ffmpeg: lavfi/hflip: copy palette data in start_frame()
[11:10] <CIA-119> ffmpeg: Fix trac ticket #1116.
[11:10] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * re37bfc4925 10ffmpeg/libavfilter/vf_pixdesctest.c: 
[11:10] <CIA-119> ffmpeg: lavfi/pixdesctest: fix SAME -> SAME memcpy
[11:10] <CIA-119> ffmpeg: Fix pixdesctest output with pal8 input.
[11:10] <CIA-119> ffmpeg: X-Cola-Count: +(10+i*PI)l
[11:18] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r171db366fd 10ffmpeg/libavfilter/vf_pixdesctest.c: lavfi/pixdesctest: use AVPALETTE_SIZE macro
[12:14] <RobertNagy> saste
[12:15] <RobertNagy> in ffplay/input_request_frame
[12:15] <RobertNagy> ah
[12:15] <RobertNagy> nvm
[12:54] <ApolloX> any devs around?
[13:19] Action: michaelni adds 1 on the counter of people loging in asking a question and leaving before anyone can awnser
[13:24] <TimNich> places to go, people to see, rush rush rush.
[13:41] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rf2c5383620 10ffmpeg/libavdevice/avdevice.h: 
[13:41] <CIA-119> ffmpeg: avdevice: bump soname due to lavf soname bump
[13:41] <CIA-119> ffmpeg: avdevice is just a part of lavf and uses lavf API/ABI/structures
[13:41] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[13:41] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r5e50a5724b 10ffmpeg/libavcodec/ (11 files): (log message trimmed)
[13:41] <CIA-119> ffmpeg: Revert "removing lowres support"
[13:41] <CIA-119> ffmpeg: There have been multiple user complaints about loosing this feature
[13:41] <CIA-119> ffmpeg: while its not clear the 3% speedloss claims where real or fabricated.
[13:41] <CIA-119> ffmpeg: My own testing indicates no statistically significant speed difference
[13:41] <CIA-119> ffmpeg: both with mpeg2 and mpeg4, and if at all the code with lowres support
[13:41] <CIA-119> ffmpeg: is a tiny bit faster than without.
[14:08] <j-b> michaelni: it would appear that FFmpeg has a regression wrt to flv support compared to libav: when piped from rtmpdump, it does not work (tested both HEAD on Win32). Any idea?
[14:17] <michaelni> j-b, can you pipe that data to a file instead of ffmpeg so i can take a look ?
[14:17] <michaelni> or tell me the options for rtmpdump
[14:54] <j-b> dumped file does work. Replacing flvdec.c from the fork does not. /me head explodes
[15:05] <michaelni> j-b, how can i reproduce the problem ?
[15:12] <j-b> that is the 1000$ question
[15:13] <nefrir> how do you pipe from rtmpdump to ffmpeg ?
[15:19] <j-b> rtmpdump -v -r "rtmp://cp73422.live.edgefcs.net/live/eTF1-Flash-Live@8976/eTF1-Flash-Live@8976" -W "http://www.wat.tv/images/v40/PlayerWat.swf?revision=4.0.69" -o - | "C:\Utils\VLC\VLC.exe" -
[15:19] <j-b> nefrir: like this
[15:20] <nefrir> ok, going to a file and playing back with cat file | vlc -
[15:20] <nefrir> does that reproduce the issue ?
[15:21] <j-b> let me check
[15:21] <j-b> cat on win32, brrr
[15:28] <michaelni> rtmpdump here (on linux) gives me: "ERROR: rtmp server sent error" for that line
[15:29] <michaelni> tried with a working rtmp url and piping this way into ffplay works
[15:30] <michaelni> something from rtmp://rt.fms.visionip.tv/live that was
[15:31] <michaelni> works with ffmpeg too
[15:33] <michaelni> all that on linux of course ...
[15:33] <cbsrobot>  on osx
[15:34] <cbsrobot> this works:
[15:34] <cbsrobot> rtmpdump -v -r "rtmp://cp73422.live.edgefcs.net/live/eTF1-Flash-Live@8976/eTF1-Flash-Live@8976" -W "http://www.wat.tv/images/v40/PlayerWat.swf?revision=4.0.69" -o - | ffplay -
[15:34] <cbsrobot> this does not (seems to hang somewhere)
[15:34] <cbsrobot> rtmpdump -v -r "rtmp://cp73422.live.edgefcs.net/live/eTF1-Flash-Live@8976/eTF1-Flash-Live@8976" -W "http://www.wat.tv/images/v40/PlayerWat.swf?revision=4.0.69" -o - | /Applications/VLC.app/Contents/MacOS/VLC -
[15:34] <michaelni> cbsrobot, which rtmpdump version do you have ?
[15:35] <cbsrobot> RTMPDump v2.3
[15:35] <michaelni> i have 2.4 and i get ERROR: rtmp server sent error
[15:35] <michaelni> ERROR: rtmp server requested close
[15:38] <cbsrobot> hmmm with rtmpdump 2.4 I get:
[15:38] <cbsrobot> ERROR: RTMP_ReadPacket, failed to read RTMP packet header
[15:39] <cbsrobot> maybe it's my firewall - not sure
[15:40] <cbsrobot> although with rtmpdump 2.3 and ffplay I have no problem at all
[15:40] <cbsrobot> besides some "Missing reference picture"
[15:45] <mateo`> hi, i was wondering why codec->time_base = ist->st->codec->time_base;
[15:45] <mateo`> oups sorry
[15:46] <mateo`> i was wondering why codec->time_base = ist->st->time_base in case of stream copy and not ist->st->codec->time_base
[15:47] <michaelni> id guess it might lead to non monotone timestamp issue if the timebase is not fine enough 
[15:48] <michaelni> thats especially an issue for stream copy as there one cannot drop frames to compensate
[15:48] <michaelni> but you can try to change it and see if it works
[15:53] <ubitux> mmh is the mov/mp4 muxer supposed to be able to mux some subtitles?
[15:53] <ubitux> it looks like it requires some "mov text" codec, but we don't have any encoder
[16:02] <mateo`> michaelni: thx
[16:22] <ubitux> burek: why are you need using https://ffmpeg.org/trac/ffmpeg/wiki ?
[16:22] <ubitux> s/need/not/
[16:22] <mateo`> here comes another dumb about output codec time base selection in ffmpeg.c. Is this condition, av_q2d(icodec->time_base)*icodec->ticks_per_frame > av_q2d(ist->st->time_base)
[16:22] <burek> ubitux, it's not the same wiki format
[16:22] <burek> it's something specific to trac
[16:22] <mateo`> written only for mpeg containers ?
[16:23] <burek> wikimedia is used on wikipedia for example and on vlc's wiki too
[16:23] <ubitux> ok
[16:23] <ubitux> did you see the guy proposing the Q&A website recently?
[16:23] <burek> yes
[16:23] <ubitux> it looks like we are splitting more and more the documentation
[16:23] <ubitux> but well& :)
[16:24] <burek> well, my point is not to split it
[16:24] <burek> there is some "plugin" for texi2html
[16:24] <burek> which outputs wiki format
[16:24] <burek> and I'd like the most if we could have something merged
[16:25] <burek> like, devels, who like to work with texi and other people, not that much familiar with it, who will use wiki
[16:25] <ubitux> the main issue i see is that duplicating the current .texi documentation will lead to somes fixes done only in the wiki
[16:25] <ubitux> and some only in the official doc
[16:25] <burek> to finally get the best from both worlds
[16:25] <burek> yes, I agree with that.. :(
[16:26] <burek> I started this because several time I've found simple errors, which I could fix in a second, but I'm just to lazy to learn/install/configure git and use it
[16:26] <ubitux> the documentation is huge, and is changing "alot"
[16:26] <burek> and I guess other (mortal) users :) are sharing my thoughts :)
[16:26] <mateo`> for example if my stream time base is 59.94 and my codec time base is 29.94, my output codec time base will be 59.94, which seems to be wrong
[16:27] <burek> well, that's why I was asking the question :) to see if there is a point in doing all that or not :)
[16:29] <michaelni> mateo`, its just a heuristic that tries to select a timebase that sane and that works
[16:30] <michaelni> if you select 29.94 in that case it may work but it also may fail
[16:35] <mateo`> michaelni: so i guess choosing a valid output codec time base depends on input format/codec (thus this heuristic could be replaced by a piece of code for every format/codec), right ?
[16:37] <michaelni> it depends on input, output and luck :)
[16:38] <michaelni> if you can improve it so it fixes some bug or chooses nicer timebases thats welcome but iam not sure its easy
[16:41] <mateo`> i'll give it a try since i have no luck copying dv essence from gxf to mxf
[17:22] <cbsrobot> burek - would it be possible to write a converter that can convert texi <-> wiki ?
[17:23] <cbsrobot> in that way every modification on the website could be sent to a mailinglist and verified for correctness 
[17:24] <cbsrobot> I suggest to keep one "master" documentation up to date - I guess that would be texi
[17:24] <cbsrobot> and say all other documentations are derivates of this main documentation
[17:37] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r6bc485b86b 10ffmpeg/doc/RELEASE_NOTES: 
[17:37] <CIA-119> ffmpeg: release_notes: update
[17:37] <CIA-119> ffmpeg: Note, if you want something mentioned in the release notes for 0.11
[17:37] <CIA-119> ffmpeg: push it but be real quick ...
[17:37] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:57] <Daemon404> michaelni, um
[17:57] <Daemon404> just how many current point releases do you plan on having?
[17:57] <Daemon404> at the current moment there will be a whopping 7
[18:05] <michaelni> Daemon404, more is better :)
[18:06] <Daemon404> not from a longterm maintenece standpoint (e.g. debian stable) :/
[18:06] Action: Daemon404 thinks it's tad much to handle so many concurrent rels
[18:08] <michaelni> debian can just ignore every 2nd release if they want
[18:09] <Daemon404> debian stable is still on 0.5 lol
[18:09] <Daemon404> for like at least another year
[18:12] <michaelni> 0.5 is nice, just 300 or so remotely exploitable issues (and thats all forks noone did, can or will backport the fixes)
[18:13] <Daemon404> perhaps someone should notify siretart 
[18:14] <michaelni> i mentioned it once as reply to some security list IIRC, debian will play deaf until they are confronted with it under major publicity
[18:14] <michaelni> that is IMHO
[18:15] <Daemon404> personally, i'd push for it myself (maybe i will)
[18:15] <Daemon404> im a very large debian user
[18:15] <burek> eat less and practice more then :)
[18:16] <Daemon404> aye
[18:16] <Daemon404> it's not so easy for me to do without knowledge / a list of problems though
[18:19] <siretart> Daemon404: give me a list of open issues in 0.5, and I'll update 0.5 in a point release
[18:19] <Daemon404> siretart, i have no such list... carl eugen or michael probably have some idea
[18:20] <siretart> aha
[18:22] <michaelni> siretart, just take a bunch of random samples and run a fuzzer over them then try to play them with ffmpeg 0.5
[18:22] <michaelni> you should see alot of crashes
[18:23] <siretart> michaelni: give me a list of your 300 'security' patches for 0.5 and I'll review which of them should get backported to 0.5
[18:23] <siretart> commit ids are fine
[18:23] <Daemon404> git log | grep j00ru
[18:24] <michaelni> darn, Daemon404 you said exactly what i wanted to say 
[18:24] <Daemon404> there are a bunch that are only in ffmpeg
[18:24] <Daemon404> that BBB never got to backport
[18:34] <iive> well, the biggest problem is that masters don't like to backport, but to redo on their own, so figuring out what have and have not been fixed even harder.
[18:34] <iive> .. is even harder.
[18:36] <ubitux> The TTXT format is an XML description of the timed text stream
[18:36] <ubitux> T_T
[18:36] <j-b> michaelni: http://git.videolan.org/?p=vlc/vlc-2.0.git;a=commit;h=6965b452713b2438b14fe41400aab0bef233addb FYI
[18:37] <j-b> michaelni: all the 3 security issues were fixed in the last HEAD
[18:40] <ubitux> iive: it's not a secret, security is not a priority in libav
[18:41] <iive> ubitux: my point is, you won't be able to automate the check of what is in and what is out. Or you would need a little bit more complicated script.
[18:41] <JEEB> ubitux, welcome to subtitles in mp4 :P
[18:41] <JEEB> @ TTXT
[18:41] <ubitux> :(
[18:42] <JEEB> or well... at least there's something in the spec for subtitles
[18:42] <ubitux> iive: yep :p
[18:42] <JEEB> chapters didn't get as lucky
[18:42] <ubitux> JEEB: i saw that, it also seems there is some kind of karaoke stuff
[18:42] <JEEB> yeah
[18:42] <ubitux> srsly.
[18:43] <ubitux> the specs did not seem to describe it though
[18:43] <ubitux> from the little i saw
[18:44] <michaelni> anybody going to repla to "RFC: TEXT subtitle decoder" ?
[18:44] <michaelni> reply
[18:45] <michaelni> j-b, thx, so nothing left in the way of 0.11 if these where already fixed :)
[18:46] <ubitux> michaelni: i'm going to
[18:46] <ubitux> (if we're talking about the same thread)
[18:47] <j-b> michaelni: yep
[18:47] <j-b> michaelni: I still need to understand the interaction with flv seeking from rtmpdump, but I only reproduce it on win32... SO this will wait
[18:48] <michaelni> ubitux, thx
[18:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * re02e58fb1c 10ffmpeg/libavfilter/libavfilter.v: 
[18:57] <CIA-119> ffmpeg: libavfilter: export ff_default_query_formats()
[18:57] <CIA-119> ffmpeg: Its needed for fate on shared versioned .so
[18:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:58] <ubitux> mmh?
[18:59] <ubitux> michaelni: i don't see the shared box in the red
[18:59] <ubitux> how did you spot that?
[19:01] <michaelni> ubitux, do you ran make distclean ?
[19:01] <michaelni> IIRC tools/lavfi-showfiltfmts.c here failed to link
[19:01] <ubitux> well i guess the box fate does that automatically since it's done from a fresh checkout
[19:02] <ubitux> ah
[19:02] <ubitux> maybe that's the reason there is less tests ran
[19:10] <michaelni> Zeranoe, did you check why the dshow stuff fails ?
[19:10] <michaelni> do you have some error message/outout ?
[19:10] <michaelni> outPut
[19:16] <Zeranoe> The error was on MinGW-w64s end, they fixed the bug
[19:17] <michaelni> Zeranoe, thx, so ill ignore this issue for the release
[19:17] <michaelni> you can close the issue on trac ..
[19:23] <Zeranoe> michaelni: I believe it has already been closed?
[20:58] <fuser> sorry to bother but... has anyone ever dealt with a "progressive audio delay" using "-map 0:0 -vcodec copy -map 0:2 -acodec copy"? thanks!
[21:18] <CIA-119> ffmpeg: 03Samuel Pitoiset 07master * rbba287fdac 10ffmpeg/libavformat/ (rtmppkt.c rtmpproto.c): 
[21:18] <CIA-119> ffmpeg: rtmp: Check return codes of net IO operations
[21:18] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:18] <CIA-119> ffmpeg: 03Samuel Pitoiset 07master * r177bcc9593 10ffmpeg/libavformat/rtmpproto.c: 
[21:18] <CIA-119> ffmpeg: rtmp: Pass the proper return code in rtmp_handshake
[21:18] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[21:18] <CIA-119> ffmpeg: 03Kostya Shishkov 07master * rd073f122ea 10ffmpeg/libavcodec/imc.c: imc: some cosmetics
[21:18] <CIA-119> ffmpeg: 03Alex Converse 07master * red7bdd8647 10ffmpeg/libavformat/movenc.c: 
[21:18] <CIA-119> ffmpeg: movenc: Don't write the 'wave' atom or its child 'enda' for lpcm audio.
[21:18] <CIA-119> ffmpeg: It's left over from stsd v0. QuickTime 7 no longer writes 'wave' or 'enda'
[21:18] <CIA-119> ffmpeg: when 'lpcm' is the audio tag.
[21:18] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rc0b47d1914 10ffmpeg/: (log message trimmed)
[21:18] <CIA-119> ffmpeg: Merge remote-tracking branch 'qatar/master'
[21:18] <CIA-119> ffmpeg: * qatar/master:
[21:18] <CIA-119> ffmpeg:  movenc: Don't write the 'wave' atom or its child 'enda' for lpcm audio.
[21:18] <CIA-119> ffmpeg:  imc: some cosmetics
[21:18] <CIA-119> ffmpeg:  rtmp: Pass the proper return code in rtmp_handshake
[21:18] <CIA-119> ffmpeg:  rtmp: Check return codes of net IO operations
[21:19] <michaelni> fuser, if you are talking about a bug please report it on trac with all information needed to reproduce
[21:19] <michaelni> if its something else please explain
[21:21] <fuser> @michaelni: hi. i don't know if it is a bug or not. i used ffmpeg to remove an audio stream from a movie with "ffmpeg -i movie.avi -map 0:0 -vcodec copy -map 0:2 -acodec copy output.avi" but i got a progressive audio delay...
[21:22] <fuser> the output avi starts ok but playing the delay is getting longer...
[21:23] <fuser> i'm not able to fix it with mencoder due to the fact that it is not constant
[21:23] <fuser> how can i deal with this?
[21:23] <michaelni> sounds like a bug if the source is ok
[21:23] <fuser> the source is fine
[21:23] <fuser> ffmpeg version 0.7.12
[21:24] <michaelni> hmm, thats a bit old
[21:24] <michaelni> you probably should try the latest release or git master 
[21:24] <fuser> sorry, that's not true... it is another version....
[21:25] <fuser> (dual boot misunderstanding)
[21:25] <fuser> and i can tell you i already used it with other file and it all went ok
[21:25] <fuser> so, i could exclude a bug
[21:26] <fuser> could it be something in the source file?
[21:27] <michaelni> i would need to see the source file to say anything ...
[21:27] <fuser> can you suggest a way to investigate deeper?
[21:30] <michaelni> if you want to debug it yourself, you should look at the timestamps from demuxer to muxer
[21:31] <fuser> and which ffmpeg version do you suggest?
[21:36] <fuser> is there something wrong with this command: "ffmpeg -i movie.avi -map 0:0 -vcodec copy -map 0:2 -acodec copy output.avi"?
[21:36] <michaelni> fuser, the latest version
[21:37] <michaelni> i see no obvious error in the command from a quick look
[21:40] <fuser> i've just tried that command with two different version of ffmpeg and now the output audio is "hiccuping"
[21:41] <michaelni> well, your choices are then down to 1. upload the video so we can take a look or to open ffmpeg.c in a text editor and fix it
[21:42] <michaelni> s/the video/the source movie/
[22:10] <ubitux> michaelni: RELEASE is missing an update
[22:15] <ubitux> mmh, maybe just upstream, the branch is ok
[22:17] <ubitux> btw, no news entry?
[22:51] <michaelni> ubitux, done, feel free to spellcheck it :)
[22:52] <ubitux> :)
[22:54] <Compn> funman : why not just ffmpeg -i movie.avi -c copy output.avi ?
[22:54] <Compn> err
[22:54] <Compn> that was to fuser who is gone now
[22:54] <Compn> pbbft
[22:58] <ubitux> is Philip Langdale on IRC?
[23:05] <ubitux> lavf question: is the way of demuxing the data free to change anytime?
[23:05] <ubitux> for instance i'm proposing to change the way srt are demuxed
[23:05] <ubitux> so the packet data change
[23:05] <ubitux> can we assume libav* user are not messing with the data directly?
[23:06] <ubitux> (is pkt->data considered "internal"?)
[23:08] <michaelni> ubitux, think about someone upgrading libavcodec with libavformat
[23:08] <michaelni> if the format in avpaket.data changes
[23:08] <michaelni> this would break somehow
[23:08] <ubitux> ah right, indeed...
[23:08] <michaelni> also other applications might use libavcodec without libavformat
[23:09] <michaelni> though chances are they wouldnt use the more odd parts
[23:09] <ubitux> so in the case of the subrip, we could just minor bump? :)
[23:10] <ubitux> or it would be wise to do a string lookup like "-->" to check if it's one format or another in lavc?
[23:10] <ubitux> sounds a bit hacky to do so
[23:11] <michaelni> supporting both formats is probably best if its easy (like when its just 5 lines of code)
[23:13] <ubitux> the timing parsing in lavc is more than 5 lines
[23:13] <ubitux> but making the code conditionnal like "if there is timing information, just ignore it but assume pkt->pts and duration are correctly set"
[23:14] <ubitux> is simple
[23:15] <ubitux> (thought it's likely the apps using lavc aren't setting the pts/duration since text timing info is present)
[00:00] --- Sat May 26 2012