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

[burek]

[00:08] <cone-263> ffmpeg.git 03Anton Khirnov 07master:b06c8bce02b1: mpegvideo: remove an unneeded call to avcodec_get_frame_defaults().
[00:08] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:efb5ebe83258: Merge commit 'b06c8bce02b15115a4789252365df2dda0c4713c'
[00:15] <cone-263> ffmpeg.git 03Anton Khirnov 07master:2d1f4288dd02: mpegvideo: call av_frame_unref() instead of avcodec_get_frame_defaults().
[00:15] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:3b2b07397c41: Merge commit '2d1f4288dd02a624cb8b86ab06371d6434c9da69'
[00:20] <cone-263> ffmpeg.git 03Anton Khirnov 07master:281a40e18f92: lavf: remove an unneeded call to avcodec_get_frame_defaults().
[00:20] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:0506cc2cc3e9: Merge commit '281a40e18f923510f2067d05c5b0cf08cc49dfee'
[00:25] <cone-263> ffmpeg.git 03Anton Khirnov 07master:48d17ee6dc2b: api-example: remove an unneeded call to avcodec_get_frame_defaults().
[00:25] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:525a7d9b7868: Merge commit '48d17ee6dc2b2a552f645484f200c2946bf24607'
[00:32] <cone-263> ffmpeg.git 03Anton Khirnov 07master:598ce4ab4f18: h264: call av_frame_unref() instead of avcodec_get_frame_defaults().
[00:32] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:e3578fd525e9: Merge commit '598ce4ab4f1893e0661fc038101487e511937877'
[00:41] <cone-263> ffmpeg.git 03Anton Khirnov 07master:d7b3ee9a3a03: lavc: deprecate avcodec_get_frame_defaults().
[00:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:44967ab60a9b: Merge commit 'd7b3ee9a3a03ab88d61a5895fbdbc6689f4dd671'
[00:48] <cone-263> ffmpeg.git 03Rumin Sam 07master:70e981cf5d75: rtspdec: Fix keep-alive request for ACTi cameras
[00:48] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:3efe5e3b094a: Merge remote-tracking branch 'qatar/master'
[05:46] <cone-726> ffmpeg.git 03Dale Curtis 07master:9c0dd7b46230: avformat/oggdec: reset end_trimming in ogg_reset()
[05:46] <cone-726> ffmpeg.git 03Michael Niedermayer 07master:551a67979562: avformat/oggdec: reset end_trimming when it has been used, so it cannot be used twice by mistake
[08:16] <ubitux> Daemon404: 183117fed7d0a910b5f65e5c78b065f125abf369
[10:50] <ubitux> if there is an error while decoding a packet, should we reset it before trying to read another frame?
[11:36] <BoR0> <BoR0> is there any framework that is able to detect whether or not a video is contained in a video? lossless comparison is trivial, what I need is something that can compare by approximation
[11:36] <BoR0> <BoR0> and also to be good in performance
[12:21] <ubitux> does sws have any temporal support?
[12:22] <ubitux> (i'm wondering if i need to flush or something after a seek)
[12:25] <nevcairiel> i dont think so
[12:29] <ubitux> http://ffmpeg.org/pipermail/libav-user/2013-December/006010.html lol
[12:45] <re-G> hi guys
[12:45] <re-G> i think that bug not really fixed: https://trac.ffmpeg.org/ticket/2230
[12:46] <re-G> i can set service_name -metadata for mpegts but not for hls segments.
[12:49] <re-G> i want to set (or copy from source) apple's rotation metadata for hls streaming but it doesn't work
[12:53] <re-G> tested with HEAD and 2.1.1
[13:01] <re-G> there is my output http://pastebin.com/UCDjLUMw
[13:11] <cone-204> ffmpeg.git 03Martin Storsjö 07master:35686a289fcd: mp3adu: Set the channel layout properly
[13:11] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:30ee4b3393eb: Merge remote-tracking branch 'qatar/master'
[13:13] <Compn> re-G : how often does metadata update in hls ?
[13:18] <ubitux> just received a mail
[13:18] <ubitux> > Hello M. Boesch
[13:18] <ubitux> > I just bought FFmpeg
[13:18] <ubitux> o_o
[13:19] <JEEB> lol
[13:20] <ubitux> he seems to be talking about a ffmpegX 0.0.9y
[13:20] <ubitux> wonder if he got scamed
[13:21] <michaelni> re-G, you use the hls muxer, ticket 2230 is about the segment muxer
[13:23] <Compn> ubitux : ffmpegx has a registration , which looks like a donation type thing
[13:23] <Compn> which is legal as long as they provide source
[13:28] <re-G> michaelni: 2296 is about hls muxer and it is marked duplicate of 2230
[13:32] <re-G> Compn: sorry i didn't understand the point of your question
[16:23] <ubitux> http://b.pkh.me/0001-WIP-seek-playback-fuzz.patch
[16:24] <ubitux> michaelni: you wanted a seek/swr-reset test
[16:24] <ubitux> this seems to do the trick
[16:24] <ubitux> if you want to play with it
[16:26] <Compn> wbs : how many mp3adu samples do we have? i remember ripping one long ago, just curious if it was ever found in the wild again
[16:28] <Compn> http://samples.ffmpeg.org/real/mp3_in_rm/
[16:29] <michaelni> ubitux, nice, more tests are always good
[16:30] <ubitux> i put it in examples but it certainly belongs elsewhere
[16:30] <ubitux> and we can certainly adjust a few things
[16:30] <ubitux> i get a lot of decode error with various files post seek though
[16:30] <ubitux> (see GoneNutty.avi or matrixbench mpg)
[17:08] <Daemon404> ubitux, k
[17:08] <Daemon404> i am going to.. massage the message a bit
[17:32] <cone-204> ffmpeg.git 03James Almer 07master:c619e14c314b: avformat/oggparseopus: Check opus_duration() return value
[17:39] <saste> michaelni, time for a new irc meeting?
[17:40] <michaelni> if theres something to discuss sure
[17:40] <saste> topics: task funding, website?
[17:40] <saste> ^ ubitux?
[17:40] <ubitux> dunno
[17:41] <saste> what about the next saturday afternoon?
[17:41] <saste> (the one after this week)
[17:41] <saste> about task funding, there are a few tasks i would like to work on, but it's better if there are more developers
[17:42] <saste> 1. DVD reading support
[17:42] <saste> 2. scripting/lavfi scripting
[17:43] <wm4> libavformat won't be able to do good DVD reading support
[17:43] <saste> btw SPI is going to support paypal donations
[17:44] <saste> we may consider to support some form of subscription funding at some point
[17:44] <Daemon404> [16:43] < wm4> libavformat won't be able to do good DVD reading support <-- libavformat is definitely not the place to do this
[17:45] <saste> Daemon404, why?
[17:45] <Daemon404> what's the use case?
[17:45] <Daemon404> it's out of scope for libavformat
[17:45] <wm4> maybe you could do raw libdvdread
[17:45] <saste> Daemon404, you use ffmpeg to transcode a DVD
[17:45] <wm4> but for libdvdnav to API is way too low level
[17:45] <wm4> the libavformat API I mean
[17:45] <Daemon404> ... man, the bubble you guys live in
[17:45] <saste> it would be some kind of DVD demuxer, or a reading protocol
[17:46] <Daemon404> do you gusy reall think ffmpeg's main users use its cli?
[17:46] <saste> Daemon404, if not up to you to decide
[17:46] <saste> i had a few requests for that, if there are enough supporters then the project will start
[17:46] <Daemon404> yes, by all means keep on making bad decisions.
[17:46] Action: Daemon404 fades into the bg
[17:47] <saste> people is still using mencoder to do DVD conversions
[17:47] <saste> Daemon404, well we are here to discuss what's good or bad
[17:48] <Daemon404> i very quickly discovered long ago that i do not like discussing such things here, since some people are in their own little world (what's up nicholas?)
[17:48] <wm4> the only thing I'd need for DVD playback is proper mapping of stream pts and playback pts
[17:49] <saste> Daemon404, if you don't want to discuss things here, nobody will force you
[17:50] <ubitux> i approve the dvd in lavf/lavd
[17:50] <ubitux> it's definitely one of the very few reasons ppl still use mencoder
[17:51] <ubitux> and it can be very useful for ppl with a bunch of dying dvd to backup
[17:51] <ubitux> integration in ffmpeg simplifies the workflow
[17:51] <wm4> I'd rather have some direct support for synchronizing stream and file timestamps
[17:52] <wm4> though I'm not sure how exactly this should work
[17:54] <GstBlub> I'm trying to capture a rtsp stream: ffmpeg -i rtsp://strm01.novotempo.org.br/radionovotempo-vivo -acodec copy -vcodec copy captured.file but I keep getting the following errors:
[17:54] <GstBlub> [rtsp @ 0x59400] UDP timeout, retrying with TCP
[17:54] <GstBlub> [rtsp @ 0x59400] method SETUP failed: 454 Session Not Found
[17:54] <GstBlub> [rtsp @ 0x59400] Could not find codec parameters for stream 0 (Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, 2 channels, s16p, 256 kb/s): unspecified frame size
[17:54] <GstBlub> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[17:54] <GstBlub> rtsp://strm01.novotempo.org.br/radionovotempo-vivo: could not find codec parameters
[17:55] <GstBlub> The same stream works fine in vlc and windows media player.  I tried googling what could be the issue but haven't really found anything meaningful
[17:55] <ubitux> GstBlub: ’ #ffmpeg
[17:56] <Compn> Daemon404 : isnt youtube a 'main user' ? they use the gui? :P
[17:57] <Compn> saste : wouldnt dvd fit better into the filesystem , like  libavdevice ?
[17:57] <Daemon404> youtube also doesnt read physical dvds
[17:57] Action: Compn doesnt know
[17:58] <ubitux> we also need a vobsub muxer :-°
[17:58] <Compn> is bluray or dvd more important ?
[17:58] <ubitux> we already support bluray
[17:58] <wm4> the ffmpeg bluray demuxer is pretty useless too
[17:58] <Compn> discs ?
[17:58] <ubitux> dunno
[17:58] <Compn> the answer is no
[17:58] <saste> Compn, DVD has a dvd protocol
[17:59] <saste> let me check my old patches, I don't remember if it was using a protocol or a demuxer
[17:59] <Compn> Daemon404 : whats features should ffmpeg work on ?
[17:59] <Compn> open to suggestions...
[17:59] <GstBlub> ubitux:  well, I've also been looking at the ffmpeg implementation a bit but didn't really find anything interesting.  It seems like this used to be a bug in ffserver that got fixed, but shouldn't ffmpeg still be able to play it (as a client)?  vlc/wmp can play it so it seems like ffserver (if that's what is serving) can't be that broken, even if it has this bug
[17:59] <Compn> GstBlub : we mean its a question for #ffmpeg , this is development only channel...
[18:00] <GstBlub> ok
[18:00] <Compn> i'd be happy to help you there
[18:00] <wm4> Compn: it would be nice if libavformat could seek
[18:00] <wm4> currently it pretends it can, but it often doesn't work correctly at all
[18:00] <Compn> in all formats there is problem ?
[18:01] <Daemon404> Compn, a higher level api
[18:01] <Daemon404> perhaps with indexing.
[18:01] <wm4> also what Daemon404 said
[18:01] <Compn> Daemon404 : sure, which one? vlc ?
[18:01] <Daemon404> vlc's api is not what you think it is
[18:01] <wm4> gstreamer!
[18:01] <Daemon404> lol
[18:01] <Compn> is there an api in another project that can be brought over to ffmpeg code ?
[18:02] <Compn> i mean, to reduce 3rd parties from reinventing said wheeele
[18:02] <ubitux> we replicated gstreamer design in filtergraphs
[18:02] <ubitux> i hope you like it
[18:02] <wm4> Compn: ffms2
[18:02] <Daemon404> ffms2 has a few issues which precluse it from beign a true high level ffmpeg api
[18:02] <Compn> wm4 : do you want ffmpeg to build an index of frames and have precise seeking like video editing applications ?
[18:02] <Daemon404> such as protocol support
[18:03] <wm4> Compn: I'm just using it for playback, so I'm not really interested in full indexing
[18:03] <Daemon404> ffms2 wins in its ease of use
[18:03] <Daemon404> getframe(n)
[18:03] <Daemon404> not the delicious loop over packets and check for multiframe packets and multipacket frames
[18:04] <Daemon404> also checking for AVERROR_EOF, which might not actually man EOF
[18:04] <wm4> wut
[18:05] <Daemon404> av_read_frame can return EOF and have a  full buffer
[18:05] <Daemon404> as in you need to decode a few more frames
[18:05] <wm4> that doesn't seem to make any sense
[18:05] <wm4> when does it happen?
[18:05] <Daemon404> cant remember, ive seen it with h264
[18:06] <Compn> i was thinking about this the other day. it seems like we need to figure out if we are going to prioritize ffmpeg (the program) or ffmpeg (the group of libraries, libavcodec etc)
[18:06] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decoding.c;h=1b5a9894710a3d3b7afe1f96f1b705f1600cbcd2;hb=HEAD#l332
[18:06] <ubitux> ?
[18:06] <ubitux> this^ ?
[18:06] <nevcairiel> you do realize that the decoder can store frames internally, and a demuxing EOF has nothing to do with that? :)
[18:06] <Daemon404> yes
[18:06] <Daemon404> but it sure is annoying
[18:07] <Daemon404> and in every way relevant to wy i hate writing this code for every new thing i do
[18:07] <Daemon404> instead of getframe(n)
[18:07] <nevcairiel> eh, whatever, if such trivial things get you already, there is no hope
[18:07] <Compn> why not just rip getframe(n) out of ffms2 and submit patch to ffmpeg-devel ?
[18:07] <wm4> nevcairiel: it's called boiler plate
[18:07] <Daemon404> yes
[18:07] <Daemon404> what wm4 said
[18:07] <wm4> writing it once is not too bad, but if you write it several times, it's annoying
[18:08] <Daemon404> Compn, it is nontrivial, and c++
[18:08] <Compn> oh god
[18:08] <Compn> c++!
[18:08] <nevcairiel> he makes it sounds like its the worst bug in the world, while thats one of the actually documented and logical things, that you need to flush the decoder
[18:08] <wm4> and if you need to write it several times, it probably means the API is too low level
[18:08] <nevcairiel> noone ever claimed that the api was high level :)
[18:08] <wm4> no, but we claimed a higher level API is required
[18:08] <nevcairiel> contribute one
[18:08] <Daemon404> ...  proposed it to be funded
[18:09] <Compn> we're trying to figure out what api should look like
[18:09] <Compn> you guys both agree on ffms2 getframe(n) ?
[18:09] <Compn> ... with changes ?
[18:09] <nevcairiel> a ffms2 api wouldnt work for any player or real-time use, since its basic concept relys on having exact knowledge about the file
[18:09] <Daemon404> its not feasible to bring it over as-is
[18:09] <Plorkyeran> there's a lot more to it than just a getframe function...
[18:09] <Daemon404> nor is ffms2's desgn
[18:10] <Compn> i mean , could you write up what kind of high level api you want and would be happy with ?
[18:10] <wm4> nevcairiel: yes, but getframe(n) could just be an additional API call to a feasible API
[18:10] Action: Compn grasping at straws
[18:10] <Daemon404> everyone here takes things way too literally
[18:10] <wm4> the main issue is that a high level API would have to wrap libavcodec and libavformat at the same time
[18:11] <Daemon404> you cant use libavfrmat withtu avcodec anyway
[18:11] <ubitux> libavsimpleapi
[18:11] <nevcairiel> sure you can
[18:11] <Daemon404> nevcairiel, no you cant. it is a hard depeendency
[18:11] <Daemon404> it wont build ;)
[18:11] <nevcairiel> well ok, it needs it for probing files, but you dont need to use it for the actual decoding
[18:11] <wm4> libavformat is pretty crazy, opening decoders and so on
[18:11] <wm4> it's all because otherwise, libavformat would be _too_ low level
[18:12] <Daemon404> that is not libavformat
[18:12] <Compn> because there was a developer policy to keep codec specific hacks out of avformat, and without those codec specific hacks, the avformat wont decode shit ?
[18:12] <Daemon404> that is *one* evil function
[18:12] <Daemon404> which im sure everyone already knows
[18:12] <wm4> also, codec parsers
[18:12] <nevcairiel> without this evil function, you wouldnt know anything about the streams :p
[18:12] <Daemon404> yes
[18:12] <Compn> probe ?
[18:12] <wm4> you could argue that these parts of libavformat should be somewhere else
[18:13] <wm4> while libavformat should just return packets in whatever format
[18:13] <Daemon404> anyway
[18:13] Action: Daemon404 goes to do work
[18:13] <clever> dang!
[18:14] <clever> ive got the yuv420 output working perfectly now, but memcpy takes up 20-30% of the cpu time
[18:14] <nevcairiel> data shuffling like that can use a lot of memory
[18:14] <clever> and at 1080p, its ~3mb per frame!
[18:15] <wm4> clever: time to try to do hwaccel style pass-through
[18:15] <nevcairiel> er, lot of cpu i mean =)
[18:15] <clever> but oddly, its not the memcpy in my hwaccel module
[18:15] <clever> i measured that function and it comes out to very little time
[18:15] <wm4> clever: e.g. vdpau, vaapi, dxva all pass through a native hardware surface type
[18:15] <wm4> clever: which can be passed to the display api directly to render it
[18:16] <wm4> hm
[18:16] <wm4> maybe omx does the memcpy
[18:16] <clever> i wrapped the entire frame end function
[18:17] <clever> let me pastebin a few bits
[18:17] <Compn> Daemon404 : curious if you disable-decoder=all and use libavformat that way  ? 
[18:18] <Daemon404> i tried that before
[18:18] <Daemon404> crashy crasy
[18:18] <Compn> ah
[18:18] <Compn> could be a bug
[18:18] <clever> wm4: http://pastebin.com/Zzn80NkT
[18:19] <clever> the entire end_frame function from line 23 to line 72 is averaging 0.05 seconds
[18:19] <clever> wm4: and the bulk of that time is spent on lines 26 thru 39
[18:21] <clever> and that function is purely async
[18:21] <clever> is there a way ffmpeg can accept an async decoder, or should i try to just add a 1 frame delay?
[18:22] <wm4> I'd try to get native pass-through working
[18:23] <clever> there are functions in the gpu to render to an EGL surface
[18:23] <clever> but wont that then confuse the rest of ffmpeg?
[18:24] <wm4> do you target playback use or transcoding?
[18:24] <clever> playback with ass subtitles
[18:24] <wm4> then do it like vo_gl
[18:24] <wm4> and render the subtitles using opengl
[18:25] <wm4> or gles in this case
[18:25] <wm4> <clever> there are functions in the gpu to render to an EGL surface <- I bet this will be much more efficient than readback + rendering again
[18:25] <clever> yeah
[18:25] <clever> is there any way to detect that the gl output is in use?
[18:25] <clever> so i can switch between the 2 modes automticaly?
[18:25] <wm4> uh, in mplayer?
[18:25] <clever> allowing transcode to work if you attempt it?
[18:26] <wm4> in ffmpeg the decoder just returns a frame, in whatever pixel format
[18:26] <clever> i can see how in mplayer, via the hwctx that it passes in
[18:26] <clever>         OMXContext *hwctx = avctx->hwaccel_context; // made in vd_ffmpeg.c
[18:26] <wm4> there's also the get_format user level callback
[18:26] <wm4> which is usually used to control whether to use hw decoding
[18:27] <clever> so how exactly is the hwaccel supposed to return the gl handle?, what type should it be and where does it go?
[18:27] <wm4> the pixel format always selects between software formats or wrapped hardware surfaces
[18:27] <clever> are there any other decoders i can use as an example?
[18:27] <wm4> the hwaccel should probably return whatever omx outputs
[18:27] <wm4> the rest is left to the application
[18:27] <wm4> the application could create an egl context and use the omx thing with it
[18:28] <wm4> I don't know omx, but this sounds pretty logical
[18:28] <clever> the vdpau code doesnt even talk to the gpu, all it does is buffer the bitstream and fire it off to mplayer
[18:28] <clever> the mplayer vo does all the work
[18:28] <wm4> yeah, well, vaapi is different at least
[18:28] <wm4> with vaapi, ffmpeg actually does vaapi calls
[18:28] <wm4> so it should be somewhat similar to your case
[18:29] <clever> hmmm, from the 3d/video mixup demo i saw, i dont think it had any handle to the current video frame
[18:30] <clever> it would bind the video output to a surface, and then just go off on its own and render a spinning cube
[18:30] <clever> and the texture was changing on its own, entirely from the gpu
[18:30] <wm4> yeah, that's not very ffmpeg/mplayer style
[18:31] <clever> i'll have to look over the docs and see what else it can do
[18:35] <clever> http://ext.earthtools.ca/firmware/documentation/ilcomponents/egl_render.html
[18:35] <clever> only match i can see is egl_render
[18:42] <towolf> hi, how do i use the ts_from_file feature for jpg series to make variable framerate mp4 video? cf. http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/144093.html
[18:42] <towolf> it drops almost all frames when i just leave out the fps=$FPS filter in the example
[18:45] <Compn> just dont make vfs files, please :P
[18:45] <Compn> eheh
[18:45] <Compn> also towolf , thats a #ffmpeg question
[18:46] <towolf> Compn, i tried there. why not make vfr files?
[19:02] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:d780fdb904a4: avformat/hlsenc: copy metadata
[19:02] <Compn> towolf : because nothing supports them
[19:02] <Daemon404> um
[19:02] <Daemon404> thast a load of shit
[19:03] <Daemon404> even flash supports them
[19:03] <towolf> Compn, vfr is a better match for modern players like html5 video
[19:03] <Daemon404> the way mp4 files uses timestamps explicitly supports vfr
[19:03] <Compn> maybe i should rephrase
[19:03] <Compn> i dont want to support anyone with vfr problems
[19:03] <Compn> because its all headaches
[19:04] <towolf> so, do i need some magic flags like copyts, copytb, vsync vfr, or something?
[19:04] <Compn> Daemon404 : you do user support with vfr files yet ? 
[19:04] <Daemon404> we have for aeons
[19:04] <Compn> good, you can help towolf then :)
[19:04] <Daemon404> towolf, my suggestion is to encode separately
[19:04] <Daemon404> and use one of the prexisting tools to mux a vfr mp4
[19:05] <Daemon404> ffmpeg's mp4 muxer is not so fun.
[19:05] Action: Compn bets webm for 'html 5'
[19:05] <towolf> Daemon404, i tried mkv ut it drops frames as well. i just think i'm missing a crucial flag at the right spot in the command line, the question is which and where
[19:05] <Compn> yes!
[19:06] <Daemon404> if mkv is ok
[19:06] <Daemon404> then you can encode normally in ffmpeg such that no frames are dropped
[19:06] <Daemon404> and mux with mkvtoolnix
[19:06] <Daemon404> which taes a timestamp file as input 
[19:06] <towolf> Daemon404, mkv is not ok
[19:06] <Daemon404> then like i said
[19:06] <Daemon404> use prexisting tools to mux the final mp4
[19:06] <Compn> towolf : you want webm ?
[19:06] <Daemon404> which support proper timestamp innput
[19:06] <Compn> or what format ?
[19:06] <towolf> Compn, no mp4
[19:06] <Compn> oh ok
[19:07] <towolf> Compn, doesn't matter, i just want oddball timestamps divided by 60 in a video
[19:08] <towolf> this is my command line now (tried this and that so far):
[19:08] <towolf> nice ffmpeg -y -f image2 -pattern_type glob -ts_from_file 2 -i "by-day/2013-12-11/lapse-*.jpg" -sws_flags "area+accurate_rnd+bitexact"  -vf scale=1296:972,crop=1280:720:8:200,setpts="(PTS-STARTPTS)/60"  -c:v libx264 -crf 18 -profile:v baseline -preset slower 2013-12-11-vfr.mp4
[19:09] <Daemon404> yes, please do ignore the answer ive given you twice now
[19:09] <Compn> lol, headaches i tells ya
[19:09] <towolf> Daemon404, i didn't understand what you said actually
[19:09] <towolf> you said, try muxing to another format and then use mkvtoolnix
[19:09] <Daemon404> encode to a cfr h264 elementary stream file wth no dropped frames
[19:10] <Daemon404> since you said taht works
[19:10] <Daemon404> mux with a tool that supports proper timestamp inputs
[19:10] <Daemon404> liek GPAC or (maybe?) L-SMASH
[19:10] <Daemon404> this is a solved problem
[19:10] <towolf> but then the timestamps have been lost, and in the process of making CFR it drops and dupes frames, which i find unnecessary
[19:10] <Daemon404> thats just ffmpeg being crap
[19:11] <towolf> Daemon404, i assumed that handling timestamps is a very basic integral part of ffmpeg and i'm just not versed in its magic enough
[19:11] <Daemon404> you need to specify the fps before -i
[19:11] <Daemon404> for it to be applied to teh sourceiirc
[19:11] <towolf> Daemon404, no that is what ts_from_file does
[19:11] <Daemon404> there is nothing basic or integrat about ffmpeg's timestamp code or handling
[19:11] <Daemon404> its horrible hacks and voodo magic
[19:12] <Daemon404> and undocumented options
[19:12] <towolf> it gie the ts from the modification time of the jpeg, which is irregular, if i give -r it will be CFR
[19:12] <towolf> -r 60 is one source of ts, and -ts_from_file is another. one is constant the other not
[19:12] <Daemon404> the idea is to ncode in such a way that no frames a dropped
[19:13] <Daemon404> the timetamps of the .h264 file *do not matter8
[19:13] <Daemon404> you apply timestamp at mux time
[19:13] <Daemon404> by muxing with a tool (not ffmpeg) that supports i t
[19:13] <Daemon404> it*
[19:13] <towolf> so is there any tool that eats both raw .h264 and separate list of timestamps?
[19:13] <towolf> how? as ascii file?
[19:13] <Daemon404> usually a v2 matroska-timescode file
[19:13] <Daemon404> gpac can with a script iirc
[19:14] <Daemon404> l-smash maybe can
[19:14] <Daemon404> if you use avisynth or something, x264 can encode and use a v2 timecodes file
[19:15] <Daemon404> http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.external_timecode_files
[19:15] <Daemon404> format si efined here
[19:15] <Daemon404> in section 18.2
[19:16] <towolf> Daemon404, interesting, never heard of such things
[19:16] <Daemon404> be warned: when the mkvtoolnix document i linked says "timecode"
[19:16] <Daemon404> it really mans timestamp
[19:16] <Daemon404> they misuse the word.
[19:17] <Daemon404> s/mans/means/
[19:17] <towolf> looks sweet and simple.
[19:26] <clever> /opt/vc/include/interface/vcos/pthreads/vcos_platform.h:681:4: error: implicit declaration of function 'sbrk' [-Werror=implicit-function-declaration]
[19:26] <clever> hmmmm, it doesnt complain when compiling under ffmpeg, but it does when compiling under mplayer :S
[19:30] <wm4> clever: using sbrk anywhere but inside the libc is usually broken
[19:31] <clever> wm4: this is the code from the gpu library, http://pastebin.com/Wiz40sn0
[19:31] <clever> its just used to figure out how much memory is free, an ugly hack
[19:31] <clever> for some reason, the compile options used in ffmpeg accept it, but mplayer doesnt
[19:32] <wm4> see man sbrk and the feature test macros it requires
[19:33] <wm4> and that code sure looks broken as fuck
[19:33] <clever> thats stuff that broadcom released
[19:33] <wm4> lol
[19:34] <clever> maybe this is why they wont release the rest of their code, shame!
[19:34] <clever> from what i can tell, some of these header files are used on both the arm and gpu core
[19:35] <clever> and a simple #define changes the behavoir
[19:35] <jangle> Greetings all.  I am attempting to write an rtsp client.  I am testing this against a server that delivers the content using rtp over udp.  When I watch vlc start the stream and compare it to my client, the rtsp handshake is similar enough, and the return codes from the servers in both cases don't suggest anything out of the ordinary.  in the case of vlc, rtp-delivered video and audio is recieved shortly after, whereas in the case of my client, the r
[19:35] <jangle> data is not delivered.  is there somthing I have to do special in order to setup the rtp side of the equation?
[19:36] <jangle> I apoogize if this is off topic, but since ffmpeg houses an rtsp server I figured there'd be someone here who would know what is expected of a client
[19:36] <cone-204> ffmpeg.git 03Vittorio Giovara 07master:6b45f05ef5b2: parseutils: fix discarding const attribute warning
[19:36] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:a435a0337419: Merge commit '6b45f05ef5b241fd1513702119af9c30056a0ac5'
[19:36] <jangle> and if someone can point me to a more appropriate channel, I'll take my question there instead
[19:39] <re-G> michaelni: thanks for patch #2296. will try it tomorrow
[19:39] <clever> wm4: aha!, it still compiles if i comment that sbrk stuff out
[19:40] <clever> guess nothing is using that function
[19:40] <clever> #if defined(linux) || defined(_HAVE_SBRK)
[19:40] <clever> and it is sorta protected, it assumes linux will always have sbrk
[19:42] <clever> but it does mean i need to modify the system headers to make it even compile, yuck
[19:46] <cone-204> ffmpeg.git 03Vittorio Giovara 07master:46c0cbd5dc01: rtsp: suppress a incompatible pointer types warning
[19:46] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:30aa9b727da0: Merge commit '46c0cbd5dc01196949105e49f2ded10aa85a6e39'
[19:54] <cone-204> ffmpeg.git 03Martin Lambers 07master:ae9d13f03e6c: img2: add stereo 3d still picture file extensions
[19:54] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:2644df82e6b3: Merge commit 'ae9d13f03e6c81ea00fafe6aa74b4a849ec8da1a'
[20:06] <cone-204> ffmpeg.git 03Vittorio Giovara 07master:a2eeed619de3: changelog: drop redundant new attribute
[20:06] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:93cf43ec3feb: Merge commit 'a2eeed619de3bb257e82f0e06d1a580101bce54c'
[20:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07master:9fa75be96d0b: mpegts: add HEVC registration descriptor
[20:26] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:7830c882fa93: Merge remote-tracking branch 'qatar/master'
[21:14] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:3dbf9afe857d: libavformat/hdsenc: check init_file() return code
[21:59] <j-b> Do you have a gif encoder?
[21:59] <nevcairiel> yes
[21:59] <Daemon404> ts not terribly great iirc
[22:00] <nevcairiel> well palette generation is a tricky thing
[22:00] <Daemon404> imagemagick does it rather well
[22:00] <Daemon404> slowly
[22:00] <Daemon404> but well.
[22:00] <nevcairiel> iirc ubitux was playing with it a while ago
[22:00] <Daemon404> some guy who worked on the gimp was here too
[22:00] <ubitux> yes i worked on making the gif encoder decent
[22:01] <ubitux> decent = not bad as shit like before
[22:01] <ubitux> good enough for most cases
[22:01] <Daemon404> imagemagick still beats it
[22:01] <Daemon404> in my tests
[22:01] <ubitux> yeah sure, isn't it multipass?
[22:01] <Daemon404> yeah
[22:01] <Daemon404> and it takes all frames int oaccount
[22:01] <Daemon404> super slow
[22:01] <ubitux> :p
[22:02] <Daemon404> result is good though
[22:02] <Daemon404> i managed to do it all in memory with libavcodec + magickwand
[22:02] <Daemon404> (and boy oh boy i magickwand's api NOT documented)
[22:06] <ubitux> Daemon404: did you try with rgb8 pix format?
[22:06] <ubitux> (so no pal)
[22:07] <ubitux> http://lucy.pkh.me/bbb.gif
[22:07] <ubitux> -rw-r--r-- 1 ubitux ubitux 375K Dec 12 22:06 bbb.gif
[22:07] <Daemon404> that looks terrible
[22:07] <Daemon404> crosshatching everywhere
[22:07] <ubitux> ./ffmpeg -i ~/samples/big_buck_bunny_1080p_h264.mov -ss 45 -vf scale=320:160,format=rgb8 -r 20 -frames:v 50 -y bbb.gif
[22:07] <ubitux> yeah well that's the scaler
[22:08] <ubitux> you could try different dithering
[22:08] <Daemon404> dithering is kind of important for gifs
[22:08] <ubitux> but depending on the dithering, you might want to disable the transdif gif encoding
[22:08] <ubitux> sure
[22:09] <ubitux> anyway, it's not an awesome encoder, but i believe that's definitely better than the previous hacks :D
[22:10] <ubitux> j-b: the gif muxing hack doesn't exist anymore since a while now, so you might want to give it a try
[22:11] <j-b> cool
[22:12] <j-b> so standard libavformat/libavcodec calls?
[22:12] <Compn> j-b : adding a feature to make little gifs in vlc ?
[22:12] <ubitux> j-b: yes, see the command line above
[22:12] <Compn> j-b : auto upload to vine or twitter too ?
[22:12] <Daemon404> j-b, i could probably hack up an iagemagick gif encoder too for vlc
[22:12] <Daemon404> since now i know exactly how to do it
[22:12] <ubitux> i'd recommend to output to rgb8 instead of the default pal though
[22:12] <j-b> Compn: you imagine the number of reddit karma points I could get with a post like this?
[22:12] <ubitux> pal = size x10 
[22:12] <j-b> over 9000!
[22:12] <ubitux> exactly
[22:12] Action: j-b karma whore
[22:12] <Compn> Daemon404 : do it!
[22:13] <Daemon404> im a bit scared of learning vlc's plugin api
[22:13] <j-b> for encoder, it's not really hard
[22:13] <j-b> muxer might be harder
[22:13] <Daemon404> i see
[22:13] <Daemon404> dont you have something akin to image2 or 'raw' muxer
[22:14] <Daemon404> that i an just pass the imagemagick buffer to?
[22:14] <j-b> we do have a raw muxer
[22:15] <j-b> basically for an encoder, you do all the magic in static block_t *Encode( encoder_t *p_enc, picture_t *p_pict );
[22:15] <j-b> p_pict is the entrance picture and block_t is your output stream
[22:16] <Daemon404> well also
[22:16] <Daemon404> imagemagick would have delay equal to the entire file
[22:16] <Daemon404> since it process all frames at once
[22:16] <wm4> how else would it process it...
[22:16] <ubitux> does imagemagick supports vfr?
[22:16] <Daemon404> irrelevant
[22:16] <Daemon404> gifs do not
[22:16] <ubitux> ?
[22:17] <ubitux> there is a delay between each frame
[22:17] <ubitux> so they actually do
[22:17] <Daemon404> isnt that a global value
[22:17] <ubitux> no
[22:17] <Daemon404> (and does anything even support that properly?)
[22:17] <ubitux> ffmpeg? :)
[22:17] <Daemon404> anthing that matters
[22:17] <Daemon404> like browsers
[22:17] <ubitux> it supports it at least for the last one
[22:18] <ubitux> so i'm assuming it works, feel free to try
[22:18] <ubitux> each frame ends with a "delay" value
[22:18] <ubitux> to mark a pause before loading the next gif pic
[22:19] <Daemon404> i always thought it was per-file
[22:19] <ubitux> try -final_delay with the gif muxer
[22:20] <ubitux> you should be able to try different delay with setpts
[22:20] <Daemon404> i dream of teh day  gifs are replaced by html5
[22:20] <Daemon404> and <video>
[22:20] <ubitux> since you e eval you should be able to figure something out
[22:22] <wm4> Daemon404: how a about a zip containing jpgs and a javascript switches the frames
[22:22] <wm4> actually I don't know if they use zip for this, but it'd be a nice touch
[22:23] <Daemon404> aside from the javascript
[22:23] <Daemon404> you describe most game formats
[22:23] <Daemon404> maybe s/jpeg/tga/ or some x texture
[22:25] <nevcairiel> isnt that just mjpeg
[22:52] <Compn> http://www.avpreserve.com/blog/a-primer-on-codecs-for-moving-image-and-sound-archives-2/
[23:28] <clever> Daemon404: and you where right!, my cheating has turned south!
[23:28] <clever> mplayer uses a different linelength then ffplay, so i cant cheat anymore
[23:28] <clever> but now i fully understand how to copy the yuv420, so that should be an easy fix
[23:31] <kierank> 9:20 PM <"Daemon404> i dream of teh day  gifs are replaced by html5
[23:31] <kierank> 9:20 PM <"Daemon404> and <video>
[23:31] <kierank> I've been trying to say this for ages
[23:32] <JEEB> there's seemingly an imageboard that does that already
[23:33] <wm4> ubitux: btw., would be nice if av_seek_frame() would work for all demuxers that implement seeking
[23:33] <llogan> CompuServe
[23:33] <wm4> currently, some formats require you to use avformat_seek_file...
[23:36] <smarter> http://gfycat.com/about seems to be a nice way to do gif to <video>
[23:38] <clever> neat
[23:42] <clever> smarter: one thing that often bothers me, animated gifs that end in .jpg!
[23:43] <wm4> on the web mime types count
[23:43] <wm4> file extensions are supposed to be ignored
[23:43] <clever> and most http servers use the extension to infer the mime type
[23:44] <clever> some of my browsers refuse to load css if the css extension isnt maped to the right mime type
[23:44] <clever> server side
[23:47] <llogan> is amerge > amix?
[00:00] --- Fri Dec 13 2013