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

[burek]

[00:41] <Compn> JEEB : maybe h264 lowres is impossible. part of why i asked :)
[00:42] <Compn> or maybe it has to be h264 no slices or soemthing
[00:42] <saste> ubitux: you could consider to add a scroll mode in showspectrum, similar to what I did for cellauto
[00:45] <ubitux> yeah sure
[00:45] <ubitux> i just wanted to keep compat with ffplay
[00:46] <ubitux> but i have some other things to think about atm, so maybe later :)
[00:47] <Skyler> H.264 lowres is impossible in general
[00:47] <JEEB> yeah, that's how I've understood it so far
[00:49] <saste> ubitux: of course
[00:49] <saste> anyway that's cool
[00:50] <saste> i'm going to add a showspectrum+pad+showaudio fancy filtergraph
[00:50] <saste> *showwaves
[00:51] Action: saste should spend less time on irc and more on emacs
[00:51] <ubitux> :D
[00:52] Action: ubitux 1: F5 https://ffmpeg.org/trac/ffmpeg/wiki/FancyFilteringExamples; jmp 1
[01:11] <BoRiS> Does anyone know where to find an example on using ffmpeg with c/c++ for transcoding a file from one format to another(into mpeg4)?
[01:11] <ubitux> in the examples directory
[01:12] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;hb=HEAD
[01:12] <BoRiS> thanks :-)
[11:42] <japjap> Hello, any idea why I get this ? h264 warning: h264 module discarded (no startcode)
[11:43] <japjap> and the video wont play
[11:45] <michaelni> japjap, with which application  do you get this warning ? plain ffmpeg ?
[11:47] <japjap> VLC using it... please see the entire log here: http://pastebin.com/62nbCQ6d
[11:50] <michaelni> japjap, can you try plain ffmpeg (just making sure it is a bug in ffmpeg and not vlc) ?
[11:51] <japjap> is ffmpeg.exe -f h264 -i test.h264 -vcodec copt out.mp4 fine ?
[11:52] <michaelni> you shouldnt need -f h264 at the start it should be detected and copt doesnt sound like a valid vcodec
[11:53] <japjap> when callen without -f h264, it says:  Invalid data found when processing input
[11:54] <michaelni> japjap, then at least format detection fails, please open a ticket on https://ffmpeg.org/trac/ffmpeg
[11:55] <michaelni> (or format detection succeeds and something else fails)
[11:55] <japjap> @michaelni - please consider that it might be a bug in my h264
[11:55] <japjap> because I am building it out of RTPs
[11:55] <japjap> and might be missing something
[11:55] <michaelni> hmm, does it work with -f h264 added ?
[11:56] <japjap> nope, but gives more info http://pastebin.com/x7s0EuGu
[11:56] <japjap> my file is looking like: 0x000001 0x000001[SPS] 0x000001[PPS] 0x000001[FRAME]... 0x000001[FRAME]
[11:58] <japjap> michaelni, am I missing something with the file format?
[11:59] <michaelni> japjap, you can download the reference h264 decoder, if it doesnt decode it  then yes
[11:59] <michaelni> should be there: http://iphome.hhi.de/suehring/tml/
[12:00] <japjap> JM_dp.zip at http://iphome.hhi.de/suehring/tml/download/development/  ?
[12:01] <michaelni> should work, i would have picked jm18.4.zip probably though
[12:02] <japjap> michaelni, could you please provide some quick instructions on what to test ?
[12:03] <michaelni> just try to decode your h264 file, if it doesnt work theres something wrong with the h264 file
[12:03] <japjap> michaelni, I am on Windows, how to use the decoder ?
[12:04] <JEEB> you compile it?
[12:04] <JEEB> be it with mingw or MSVS
[12:04] <JEEB> you can see decoding examples over at x264's regression test suite
[12:05] <JEEB> if you don't know how to use JM's decoder
[12:07] <japjap> unfort I haven't even geard about is so far, I'm quite a newbie with video
[12:07] <japjap> heard*
[14:08] <kriegerod> michaelni, i'd like to ask you as you authored these lines of code: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;h=251cd11d02dd624c3a5bff164d465055a65f7c92;hb=HEAD#l1023 . I work with durable mpegts streams, and because of this code i have _double_ dts jump on wrap. See what is currently produced by demuxing: http://pastebin.com/6gKSqFDk . I want to propose to increment pts instead of decrementing dts
[15:29] <japjap> Hello guys, could anyone please tell me how to capture video with RTSP via ffmpeg ?
[15:30] <japjap> I've tried  ffmpeg -i rtsp://LOCAL_IP -y -vcodec copy -f mp4 record.mp4
[15:30] <japjap> did not work
[15:30] <japjap> keeps complaining about missing SDP info
[15:31] <japjap> I've also tried ffplay "rtp://192.168.5.4444:9978"
[15:31] <japjap> gives rtp://192.168.5.44:9978: could not open codecs
[15:41] <kriegerod> japjap: show your full command and uncut console output with full debug on
[16:25] <michaelni> kriegerod, i think either way has problems
[16:26] <michaelni> that is incrementing pts would add a wrap for cases where streams start with pts=0 and dts<"0"
[16:26] <michaelni> so i think we need a check based on some reference
[16:26] <michaelni> like a previous timestamp
[16:27] <michaelni> and then choose the variant that introduces less wraps
[16:28] <kriegerod> i was wrong saying about "double" wrap, actually the fact of negative dts does not mean anything more than any other timestamp jump
[16:29] <kriegerod> but i'm interested in solving such wraps at all. I see the discussion in maillist about ts wraps and seeking, and i understand only that the problem is quite tricky to solve
[16:30] <kriegerod> I'd be glad to work on solution, but i need advices and direction
[16:34] <michaelni> the general timestamp discontinuity problem is quite long standing and tricky
[16:34] <michaelni> if its just for linear playback then removing all discontinuities is relatively easy
[16:35] <michaelni> if you have some external information about where discontinuities are (like if they are on chapter starts only) then it would be relatively easy too
[16:36] <michaelni> but the general case is not so easy
[16:36] <michaelni> your file might start with timestamp 0 and if you seek to the end it may have timestamp 1000
[16:37] <michaelni> but you dont know if there are 0,1,2,3... discontiinuities between
[16:37] <michaelni> or where they are
[16:37] <kriegerod> currently, how many container formats can contain such discontinuities? Does seeking work on them in such cases? (i mean if i patch something, how probable is breakage of sth important)
[16:38] <kriegerod> i just work with mpegts only
[16:38] <michaelni> mpeg-ps/ts are the primary formats that can contain discontinuities
[16:38] <michaelni> seeking in them works if you seek by file position in bytes
[16:39] <michaelni> or timestamps if there are no discontinuities
[16:39] <michaelni> if theres a discontinuities then seeking will likely fail
[16:39] <michaelni> in some random way
[16:40] <michaelni> that is seeking by timestamp
[16:59] <Daemon404> michaelni, ping
[17:00] <michaelni> Daemon404, pong
[17:00] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=ad8dabfe9cfadfe50f9f6d47b481a434c2bc9376
[17:00] <Daemon404> 2112 is a bad assumption
[17:00] <Daemon404> it's introducing unwanted delay in some files
[17:01] <Daemon404> is there some way to identify apple's aac?
[17:01] <michaelni> there was someone who wanted to work on it
[17:01] <michaelni> but it seems he disappeared
[17:02] <Daemon404> i only saw: https://github.com/VFR-maniac/ffmpeg/commit/4341c2a791a9e3e2d86b24133c178c45ee45ac1f
[17:03] Action: Daemon404 prods MP4_maniac 
[17:26] <michaelni> Daemon404, ill try to fix the start_pad code, i dont think a fixed 0 is really a much better choice for a field that isnt really constant
[17:26] <Daemon404> indeed
[17:49] <ubitux> saste: there are a few other matches with git grep '[^_V]CODEC_ID' though :)
[17:50] <ubitux> (omiting old codec ids of course)
[17:50] <Daemon404> ^ that is a royal mess
[17:50] <ubitux> Daemon404: just a few matches, nothing that terrible
[17:50] <Daemon404> ubitux, i mean for lib users
[17:50] <Daemon404> aka me
[17:50] <ubitux> ah you mean the rename?
[17:51] <ubitux> well, you know where to complain
[17:51] <ubitux> saste: btw, shouldn't we at least build the examplse as part of FATE?
[17:51] <Daemon404> https://code.google.com/p/ffmpegsource/source/detail?r=703
[17:51] <ubitux> nice logo
[17:52] <Daemon404> lol
[17:52] <ubitux> mmh looks weird
[17:52] <saste> Daemon404: what's the main problem, apart the warnings and renames?
[17:53] <Daemon404> defining CodecID
[17:53] <Daemon404> while user code (i.e. haali's parser) may have things named CodecID
[17:53] <Daemon404> also a massive PITA for backwards compatable code
[17:53] <ubitux> if VERSION_CHECK(LIBAVCODEC_VERSION_INT, <, 54, 25, 0, 54, 51, 100) this is funny :)
[17:53] <ubitux> to handle both qatar & ffmpeg i guess?
[17:53] <Daemon404> cross-lib compat
[17:54] <saste> it already occurred to me  to find libs using CodecID, and it was painful to deal with they had to live with ffmpeg libs
[17:55] <Daemon404> im not sure i can parse that sentence
[17:55] <saste> i wonder what was  a better solution, maybe drop CodecID at the next bump with no define tricks
[17:55] <nevcairiel> typedef CodecID and defines for the old names would've been better
[17:55] <Daemon404> saste, btw, will you be at CDD?
[17:55] <Daemon404> VDD< even
[17:55] <saste>  it was painful to deal with *if* they had to live with ffmpeg libs
[17:55] <saste> CDD?
[17:56] <Daemon404> VDD
[17:56] <saste> nope...
[17:56] <Daemon404> ah well.
[17:56] <ubitux> :(
[18:00] <saste> if we'd manage to collect enough funds we could organize such events ourselves
[18:00] <saste> right now, far from it
[18:02] <Daemon404> well im quite grateful to be sponsored to fly out to Paris
[18:02] <Daemon404> ;)
[20:36] <msmithng> is there a good definition of what q= in the output log references somewhere?
[20:36] <msmithng> I'm presuming this is quality 
[20:36] <msmithng> but I'm coming up with nothing as far as what the range is...
[20:37] <Daemon404> probably quantizer...
[20:46] <kriegerod> michaelni, continuing the topic of timestamps wrapping: i have and idea to implement special bitstream filter addressing this issue. What do you think, is it realistic way to go? Can we enqueue together packets from all elem.streams and operate on their timestamps in single BSF context?
[21:20] <michaelni> kriegerod, i dont think that would work with seeking 
[21:21] <kriegerod> kinda yep... although seeking problem is not actual for me, i work with realtime iptv streams
[21:23] Action: Daemon404 pokes saste 
[21:24] <saste> Daemon404: what?
[21:24] <Daemon404> saste, is it possible to pad audio with silence to the length of the video using avfilte?
[21:24] <saste> uhm...
[21:25] <saste> or you add a new pad audio filter
[21:25] <saste> or you could modify flite to pad it
[21:25] <saste> first solution seems more generic
[21:25] <saste> both are unimplemented
[21:25] <Daemon404> aye
[21:26] <ubitux> mmh
[21:26] <ubitux> we can generate silence, but not "aconcat"
[21:26] <ubitux> that's too bad
[21:26] <Daemon404> ubitux, avisynth has been able to do this for ~10 years
[21:26] <saste> ubitux: concat should work just fine
[21:26] <Daemon404> re: what cant avs to that libavf cant
[21:26] <ubitux> saste: then with aevalsrc
[21:27] <Daemon404> =0
[21:27] <Daemon404> yea
[21:27] <ubitux> aevalsrc+concat
[21:27] <ubitux> might do the trick
[21:27] <Daemon404> but hat would require a bit of trickery
[21:27] <Daemon404> to do know the length of teh video etc
[21:27] <saste> yes basically: flite=...[voice]; aevalsrc=...[silence]; [flite][voice]concat=a=2,asetpts
[21:28] <ubitux> can we make concat stop when one of the two reaches the end?
[21:28] <saste> asetpts is needed for adjusting audio timestamps
[21:28] <saste> uh? why?
[21:28] <ubitux> ah well i'm stupid, not in that case
[21:28] <saste> concat is not supposed to work that way
[21:29] <saste> it was  [voice][silence]concat=a=2,asetpts
[21:29] <Daemon404> saste, i dont see how that would pad to the end of the video
[21:30] <Daemon404> it's just pad however long teh silence is
[21:30] <Daemon404> wouldnt it?
[21:30] <ubitux> without hardcoding the duration i don't know how that could be achieve
[21:31] <ubitux> (hardcoding = specifying a duration in aevalsrc parameters)
[21:31] <Daemon404> does aevalsrc not have access to duration?
[21:31] <Daemon404> eval() and all
[21:31] <ubitux> not sure
[21:31] <ubitux> but i'm wondering, can't we make ffmpeg stop encoding when the first streams end?
[21:32] <Daemon404> thats a bad solution
[21:32] <ubitux> why?
[21:32] <Daemon404> because it would cut the video short
[21:32] <Daemon404> many pro applications make shorter audio instead of paddign with silence
[21:32] <Daemon404> and assume no audio = silence
[21:32] <ubitux> as soon as there is no more video, it will stop picking silence from the audio silence?
[21:33] <Daemon404> OH
[21:33] <ubitux> isn't it what you want?
[21:33] <Daemon404> i misunderstood
[21:33] <Daemon404> i thought you meant kill the video when audio ends
[21:33] <ubitux> it would be weird if ffmpeg hadn't that feature
[21:33] <ubitux> no, the audio would be audio+infinite silence
[21:33] <Daemon404> yeah
[21:35] <ubitux> it looks like it's the default
[21:36] <ubitux> so it should work
[21:38] <Daemon404> ic
[21:43] <saste> and the asepts should not even be required, since concat assumes streams starting from 0 already
[21:43] <saste> *asetpts
[21:44] <Daemon404> ah
[21:45] <ubitux> ./ffmpeg -i video -i audio -map 0:0 -filter_complex 'aevalsrc=0 [silence]; [1:0][silence] concat=v=0:a=1 [padded_audio]' -map '[padded_audio]' output
[21:45] <ubitux> this seems to work, but not much tested
[21:45] <ubitux> can be simplified a lot most likely
[21:47] <ubitux> seems like there is kind of a bug ;)
[21:48] <ubitux> it seems to continue to poll from filters
[21:54] <saste> ubitux: concat=v=0:a=2?
[21:55] <ubitux> doesn't work
[21:55] <ubitux> ./ffmpeg -v 0 -f lavfi -i testsrc=d=60 -y video.mp4
[21:55] <ubitux> ./ffmpeg -v 0 -f lavfi -i 'aevalsrc=sin(440*2*PI*t)::d=5' -y audio.wav
[21:55] <ubitux> ./ffmpeg -i video.mp4 -i audio.wav -filter_complex 'aevalsrc=0 [silence]; [1:0][silence] concat=v=0:a=1 [padded_audio]' -map 0:0 -map '[padded_audio]' -c:v copy -y out.avi
[21:55] <ubitux> try this
[21:55] <ubitux> (it freezes)
[21:56] <saste> ah yes a=1 specifies the number of *output* audio streams
[21:57] <saste> ubitux: nicolas is working on some possibly related issues
[21:57] <ubitux> oh?
[21:57] <ubitux> well maybe i should open a trac issue so he doesn't forget ;)
[21:57] <saste> also i don't trust -filter_complex, what about a plain -f lavfi?
[21:58] <ubitux> gonna try
[21:58] <saste> but yes opening a trac ticket may help
[22:00] <ubitux> ah
[22:00] <ubitux> seems much better
[22:00] <ubitux> ok so
[22:00] <ubitux> Daemon404: ./ffmpeg -f lavfi -i 'movie=video.mp4 [out0]; amovie=audio.wav [audio]; aevalsrc=0 [silence]; [audio][silence] concat=v=0:a=1 [out1]' -y out.avi
[22:00] <ubitux> this works for me
[22:01] <ubitux> given that the only video streams in video.mp4 is longer than the audio stream in audio.wav
[22:02] <ubitux> (it should work if not of course)
[22:11] <ubitux> saste: ticket #1670 if you want to follow
[22:12] <saste> thanks
[22:13] <ubitux> Daemon404: so is that ok with you? :)
[22:14] <ubitux> saste: i already told you, but i really love aevalsrc :))
[22:14] <ubitux> thx for that great filter ;)
[22:14] <saste> yes that's pretty cool
[00:00] --- Wed Aug 22 2012