Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2013

1 participants
54 discussions

ffmpeg-devel.log.20131215
by burek 16 Dec '13

16 Dec '13

[00:45] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7a5d3a41fe38: avformat/mov: Check avio_read() return code in mov_read_extradata() and shrink the extradata if needed / return an error [00:45] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:b2361cfb9473: avcodec/svq3: cleanup context in case init fails [03:26] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2b31a9c613f9: avformat/iff: shrink packets to the initialized data [03:26] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:6f9be9106382: avformat/iff: fix memleak of packet [03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:b50968169df4: libzvbi-teletextdec: cosmetics [03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:249a435989d0: libzvbi-teletextdec: use defined constants for bitmap char width and height [03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:c77e0c2130c3: libzvbi-teletextdec: add chopped top row size to y offset [03:33] <cone-938> ffmpeg.git 03Marton Balint 07master:97f880e7a952: libzvbi-teletextdec: set bitmap teletext canvas dimensions [03:33] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:ec13849ce2dc: Merge remote-tracking branch 'cus/stable' [05:02] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:f6cd447bf105: avformat/utils: treat flv like mov with timestamp discarding [05:02] <cone-938> ffmpeg.git 03Alex Sukhanov 07master:cc0e2ba1aa93: Enable parser in FLV demuxer for H264 codec [09:14] <rcombs> https://github.com/11rcombs/mkm-spec <-- any thoughts on this? [09:15] <rcombs> It's meant as a simple specification to improve searching for external files referenced by MKV ordered chapters [09:54] <wm4> rcombs: ffmpeg doesn't even support ordered chapters in any form [09:59] <rcombs> wm4: doesn't mean I can't ask for comments [10:01] <rcombs> wm4: also, AFAIK there isn't consensus against adding support; there was a patch in the mailing lists that went through a fair few iterations, and was eventually dropped because of some implementation issues, not because the concept was disliked [10:05] <nevcairiel> mostly because the concept doesnt fit into avformats design [10:07] <rcombs> yeah, iirc the implementation was disliked because it put search code in libavformat, which was awkward [10:48] <cone-91> ffmpeg.git 03wm4 07master:5f6c21117f23: ffprobe: show best_effort_timestamp in the frame section [10:48] <wm4> hu [10:49] <wm4> saste: thanks [11:26] <nevcairiel> wow, the SWS_FAST_BILINEAR scaler is sure broken [11:29] <nevcairiel> with fast bilinear, i get ugly chroma bleed, not even static, it moves from frame to frame; http://i.imgur.com/YPzAMJl.png .. see the blue "shadow" [11:30] <JEEB> that's pretty awful :D [11:30] <wm4> nevcairiel: yeah, I think this has been long known [12:11] <michaelni> nevcairiel / wm4 which ticket is that sws issue ? [12:14] <nevcairiel> no idea, but all i did was scale http://files.1f0.de/samples/bunny444.mkv to yuv422p [12:28] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:d408d3dbc3c5: fate: update after 5f6c21117f23a3c825777cdb0565a21c5a468d35 [13:09] <wm4> why is libavcodec locking so fucking broken [13:34] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:81230e2612a9: avcodec/msmpeg4dec: print error in case of invalid vlc in msmpeg4_decode_dc for version <=2 [13:34] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:61edda9a4a34: avcodec/msmpeg4dec: initialize dir_ptr in error cases [14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:dc54bd4e8d8c: swscale/utils: factor (d + 1 < 4) out [14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:554e913fd7ac: swscale/utils: remove useless () [14:58] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:037fc3b054b1: swscale/utils: check chroma width for fast bilinear scaler [14:58] <michaelni> nevcairiel, wm4, sws fast bilinear bug fixed [14:59] <nevcairiel> fast only works for upscaling, eh? [15:02] <michaelni> the mmx2 code works only for upscaling [15:06] <BBB> that code is insanely crazy [15:06] <BBB> it's fast also [15:55] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:0e0f6bd4a579: avformat/id3v2: Check avio_read() return code in id3v2_parse() [16:52] <nevcairiel> hm was it ever documented anywhere how the swscale chroma position translates to the avcodec enum? [16:52] <nevcairiel> it seems rather confusing :p [17:03] <wm4> nevcairiel: vf_scale [17:03] <wm4> there's your "documentation" [17:04] <wm4> hm, actually [17:05] <wm4> avcodec_enum_to_chroma_pos() [17:05] <kierank> does anyone else care about chroma positioning [17:05] <kierank> apart from interlaced people [17:06] <kierank> ah mpeg-1 people apparently [17:06] <kierank> ... [17:07] <beastd> I see interlaced people ;) [17:09] <beastd> Should have been a pun on sixth sense, not sure if it came out that way... [17:12] <saste> beastd, ah you're here [17:12] <beastd> Hi saste [17:13] <saste> beastd: i see you can mark a checkbox in the tags cloud page to select wiki/tickets [17:14] <saste> so i think it should be fine to keep it as is, and add the possibility to add tags to wiki pages [17:15] <beastd> saste: yes. i will enable them. [17:15] <beastd> i tried to describe the checkbox thing in my reply to you on that ticket. but looking at it yourself is better. [17:18] <nevcairiel> kierank: looks like the default chroma pos in swscale is not mpeg2, so i'm trying to figure out if i can fix that [17:22] <saste> beastd, if you see people interlaced, you must have a serious vision problem [17:48] <saste> \o/ [19:44] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:e838c9852e6f: avcodec/bink: use av_mallocz for data [19:44] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:45115315820a: avformat/oggparsetheora: zero extradata padding area [20:12] <ubitux> michaelni: about 0e0f6bd4a5796f4f668092d7925a31b9b30fedd4, don't you need to check for < 4 instead? [20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:d37d4b6e4022: lavf/mux: improve feedback in case of no streams in muxer [20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:2364b4031dcb: doc/muxers/tee: use @ref to reference other sections [20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:81eff6e7a20b: doc/muxers/tee: add example showing second level escaping [20:14] <cone-91> ffmpeg.git 03Stefano Sabatini 07master:b2a4316287ea: examples/decoding_encoding: check av_samples_get_buffer_size() for a negative value [20:21] <michaelni> ubitux, fixed [20:21] <cone-91> ffmpeg.git 03Michael Niedermayer 07master:476aceaa22a0: vformat/id3v2: check avio_read for short reads in addition to errors [20:21] <ubitux> thx [20:44] <clever> ubitux: do you know how much and where ffmpeg will copy frames when getting the data into the player? [20:44] <clever> seeing performance issues even with -vo null, and i'm wondering if they can be fixed any [20:45] <ubitux> sounds like a player question [20:45] <clever> so mplayer allocates the avframe, passes it in, and expects to get the same frame back out with as little copying as possible? [20:47] <ubitux> i have no idea about mplayer internals, wm4 might be able to help you [20:47] <clever> i also discovered, sdl is completely software driven [20:47] <clever> the default libs have no hw accel [20:47] <clever> so that explains why ffplay is just as bad as -vo x11 [20:48] <ubitux> if you want to bench, ./ffmpeg -i ... -f null - [20:48] <clever> i was benchmarking mplayer with -vo null and got arround 10 fps [20:49] <wm4> clever: mplayer will attempt to pass frames directly to the VO [20:49] <clever> wm4: so what would cause 10 fps even with -vo null? [20:49] <wm4> it also has a hideous direct rendering mechanism, which is usually not active when not using any filters, though [20:49] <wm4> hm sdl2 should have a gl(es) backend [20:50] <wm4> that uses shaders for yuv and all [20:50] <wm4> clever: aren't the 10 fps caused by the readback? [20:51] <clever> i was getting about 11 fps when i used -vo null, but my code was proving full yuv420 1080 frames [20:51] <clever> 15 fps if i commented out the code to copy frames into ffmpeg [20:52] <clever> part of the problem is that the omx api is async, you run a function, and ~0.03 seconds later it runs a callback (in a diff thread) [20:52] <clever> then you can read the frame out [20:52] <clever> but i might be able to double buffer it, read one frame out while feeding another in [20:52] <Daemon404> thats not exactly hard to handle with some sort of thread pooling [20:52] <Daemon404> just annoying [20:53] <clever> i did write an example that will use a pthread condition to block until the last frame is done [20:53] <clever> then start the next frame, and return the last one [20:53] <clever> adding a 1 frame lag to the entire chain [20:53] <Daemon404> i fear that probably doesnt fit so well into ffmpeg's model. [20:54] <clever> yeah, i would expect it to mess up the sync some [20:54] <clever> since end_frame returns the wrong frame [20:54] <clever> but i have no idea how many extra frames of latency the omx core is adding [20:55] <clever> ive got one more way i can try to double-buffer it, then id like to try lower resolutions, it may handle 720p with this method [20:55] <clever> if that doesnt work, then the only option is to add gl surfaces [20:55] <clever> oh, and something else [20:56] <clever> Daemon404: if i define 2 AVHWAccel, one returns AV_PIX_FMT_YUV420P and one returns the custom glsurface trick [20:56] <clever> will ffmpeg pick the right one, based on which vo i'm using? [20:56] <wm4> hwaccels can return software surfaces? [20:56] <Daemon404> i know nothing of the hwaccel stuff. [20:56] <clever> wm4: i did sucessfully make a hwaccel that returns a custom pixel format type [20:56] <clever> wm4: which only -vo rpi supported [20:57] <wm4> clever: it's left to the application, the get_format callback decides which hwaccel is used [20:57] <clever> i was just trying to preserve the full yuv420 support for things like transcoding or filters at low resolutions [20:57] <clever> while adding support for gl surfaces, to make it work at 1080 [20:58] <wm4> for software surfaces it should probably use a separate pseudo-decoder [20:58] <wm4> like with libstagefright, I think [20:58] <wm4> or the crystalhd stuff or the vda decoder [20:58] <wm4> (though vda also has a proper hwaccel thing) [20:58] <clever> vda? [20:59] <clever> ah, vda_h264.c [20:59] <wm4> the OSX hw decoding API [20:59] <clever> i'll review those files and see what works [20:59] <wm4> btw. the vda code seems to suck, it always had mem leak problems etc. [21:00] <clever> also, i should check out the dispmanx code [21:00] <clever> hardware 2d compositor [21:00] <clever> pixel format conversions, scaling [21:01] <clever> the firmware exports a single dispmanx surface as fb0 (framebuffer) [21:01] <clever> but omxplayer uses dispmanx directly, to draw another surface over fb0 [21:02] <clever> ./interface/vctypes/vc_image_types.h: VC_IMAGE_YUV420SP, /* Y as a plane, then UV byte interleaved in plane with with same pitch, half height */ [21:03] <clever> wm4: aha!, dispmanx supports yuv420, so i can create a -vo dispmanx to handle it [21:03] <wm4> this 420SP thing sounds like NV12 [21:03] <clever> there are others [21:03] <nevcairiel> indeed it does [21:03] <clever> ./interface/vctypes/vc_image_types.h: VC_IMAGE_YUV420, [21:04] <clever> that one isnt explained, but is probly planar [21:06] <clever> and after that, it might be fun to check out the weston graphics engine [21:06] <clever> http://wayland.freedesktop.org/raspberrypi.html [21:06] <clever> it has dispmanx support, and uses the hw to draw all windows [21:06] <clever> so every graphical app has its own framebuffer, sized to match its window [21:06] <wm4> I wonder why everyone cares so much about this really shitty piece of hardware [21:07] <clever> because unlike the ps3, i have the ability to add support [21:07] <clever> for anything i want [21:07] <wm4> there are better ARM boards? [21:07] <ubitux> wm4: because it went viral and it's now widely spread [21:07] <clever> wm4: which didnt go viral, so i dont know about them :P [21:09] <clever> from a glance at the api, i think dispmanx is the same as XV, with more then 1 channel [21:10] <nevcairiel> wm4: i agree, i never understood the obsession with the rpi, its totally overrated and overhyped [21:11] <clever> but are there any similarly capable systems that can handle video decode in hw? [21:15] <wm4> I'm sure there are, though I don't know any (since I'm not into experimenting with bare boards...) [21:16] <wm4> rpi on the other hand seems to have a bunch of really dumb problems I heard from others [21:16] <wm4> like horrible and closed problems, incorrectly working (and unfixable) video output, etc. [21:16] <beastd> wm4: i fear most of the cheap boards have them :( [21:17] <beastd> Choose your poison! [21:18] <nevcairiel> i just got a arduino for some hacking, but not with anything video :p [21:19] <clever> wm4: what kind of problems? [21:22] <wm4> not sure, maybe something about always outputting limited range rgb [21:23] <beastd> IMHO when you are into multimedia development it is best too invest in a more expensive system that can do things CPU based. OTOH small boards are fun too, but you must be able to enjoy pain to some extent ;) [21:26] <wm4> I knew it, these things are for masochists [21:27] <JEEB> uhh [21:27] <JEEB> > multimedia [21:27] <JEEB> > internals [21:27] <JEEB> > not masochists [21:27] <JEEB> not seeing [21:27] <JEEB> :D [21:27] <wm4> ok I'm dealing with vsfilter crap and I'm hacking mplayer code too, ok, I must be a masochist [21:28] <JEEB> yes, so am I [21:28] <JEEB> also since when are you poking VSFilter o_O [21:28] <wm4> I'm not [21:28] <JEEB> that's an extra layer of pain [21:28] <JEEB> oh [21:28] <wm4> but I still have to deal with its crap [21:28] <JEEB> then you're not on this level yet [21:28] <JEEB> because the code is something special [21:28] <JEEB> esp. xy-vsfilter code [21:28] <wm4> just look at libass ticket #111, it makes me sad [21:29] <wm4> does xy add more special sauce? [21:29] <JEEB> they rewrote parts in ways that made the MPC-HC maintainer afraid of reading it [21:29] <wm4> wooh [21:30] <wm4> someone should convince xy to remove all the crap from his tree [21:30] <wm4> things carried over from vsfilter which nobody (?) cares about [21:32] <JEEB> the xy-vsfilter tree was quite a joke to begin with [21:32] <JEEB> instead of beginning from a cleaned up tree, it just had guliverkli there [21:32] <JEEB> all of it [21:32] <JEEB> mpc and all the other stuff [21:32] <JEEB> completely unused [21:34] <JEEB> although there now seems to be a pull request to fix that [21:34] <JEEB> they did also fix their tree mostly regarding line endings [21:34] <JEEB> they used to have CRLF and LF mixed [21:35] <wm4> reminds me of mplayer code, which mixes tabs, spaces, and multiple indentation styles in some files [21:35] <JEEB> I had to use a lulzy editor that does not try to normalize line endings so I would get sane diffs when I patched xy-vsfilter >:| [21:36] <nevcairiel> legacy code, so much fun [21:36] <JEEB> anyways, there's plenty of insanity in xy, or weird things at least [21:36] <JEEB> I mean, even more than the gabest/mpc-hc code [21:37] <nevcairiel> and people keep asking me to simply copy feature X or Y from ffdshow, and everytime i can only shake my head and cry a little inside, not touching that code base [21:37] <JEEB> I still remember middle-to-late 2011, when Lord and me were the only ones really working on ffdshow-tryouts, and clsid would in the best cases merge our work within hours [21:38] <JEEB> and yeah, ffdshow-tryouts' source code tree was "fun" [21:38] <nevcairiel> wonder what would have happened if i didnt show up [21:39] <wm4> nevcairiel: endless despair [21:39] <nevcairiel> more people would've eventually given up on dshow i reckon, and moved to vlc [21:39] <JEEB> yeah [21:39] <JEEB> there were some plans on doing large'ish changes to ffdshow-tryouts at one point [21:39] <JEEB> but that died out when LAV Video became good enough [21:39] <JEEB> november 2011 or so when me and Lord finally washed our hands from -tryouts [21:40] <wm4> I bet they would have kept using ffdshow [21:40] Action: beastd has given up on dshow 8 years ago [21:42] <nevcairiel> many still use ffdshow, either because they dont know any better, or because they have a deranged requirement for postproc [21:43] <JEEB> yup [21:43] <wm4> such as? [21:45] <JEEB> at simplest, cropping and resizing, but then there are people who use warpsharp and stuff in -tryouts [21:45] <JEEB> or avisynth [21:45] <Daemon404> or custom channel mixing [21:45] <JEEB> yes, for audio that [22:13] <saste> michaelni, should I push ffserver Metadata patch? [22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:d600b18f224e: avformat/utils: limit rfps to values larger than fps [22:14] <cone-75> ffmpeg.git 03Joakim Plate 07master:6eda91ad54fd: mpegts: stop analyzing when pmt for all programs have been found [22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:460f8fca9c26: avformat/id3v2: factor free code to the end of read_chapter() [22:14] <cone-75> ffmpeg.git 03Michael Niedermayer 07master:ffbcb1c6f051: avformat/id3v2: Check avio_read() return value in read_chapter() [22:25] <michaelni> saste, the new patch looks like it still has the same issue (entry==NULL and segfault) [23:14] <kierank> Compn: what's the ffmpeg incoming username and hostname [23:21] <Compn> kierank : i still cant stop from saying kye-rank every time i read your nick :\ [23:43] <funman> smarter: well we can bump after the fact no? [23:43] <smarter> sure, I don't know how this stuff is done usually :) [23:44] <wm4> Compn: I'd like access to incoming as well, if possible [23:45] <funman> smarter: it's done badly [23:46] <funman> smarter: people who write stuff pulls on one side and people who use stuff written by others pull on the opposite [23:46] <funman> so there's never a perfect solution [23:51] <Compn> anyone else need incoming access ? [23:52] <Compn> other devs should know login info too [23:52] <Compn> but i guess it wasnt widely advertised... [00:00] --- Mon Dec 16 2013

1 0

ffmpeg.log.20131215
by burek 16 Dec '13

16 Dec '13

[02:12] <DeadSix27> waiting 2 hrs, realise you forgot that you left the start param in the encode, feel annoyed. [02:13] <DeadSix27> i bet alot people here can relate. [02:58] <klaxa> most of the time i encode stuff while i'm asleep [03:03] <DeadSix27> ye same [03:04] <DeadSix27> but right now im still awake.. and had nothing much to do [03:49] <SLAYBoz> how much better is h265 over h264 [04:07] <Compn> its +1 better [04:07] <Compn> damn parker already said it [04:31] <SLAYBoz> is .ts a valid container? [04:38] <Compn> valid for what [04:39] <SLAYBoz> meaning is it container like .mkv/mp4/flv/asf [04:40] <Compn> yes, mostly used by commercial products and not pirates [04:40] <Compn> not as widely supported in editing applications [04:41] <SLAYBoz> how come i rarely see it even on commercial [04:42] <Compn> its usually used in set top boxes , where you dont have access to it [04:43] <SLAYBoz> i see [04:43] <SLAYBoz> i have only seen it on bluray and my HD camera [04:44] <SLAYBoz> does ffmpeg support .ts [04:47] <Compn> you think bluray is rare ? [04:48] <SLAYBoz> sorry i said that wrong, i rarely see them on commercial website [04:48] <SLAYBoz> does ffmpeg support .ts [04:49] <sacarasc> Yes. [04:50] <SLAYBoz> how come people don't use it as much as mkv/mp4 [04:50] <relaxed> you would be hard pressed to find a format that ffmpeg doesn't support [04:50] <SLAYBoz> relaxed it doesn't support .asf [04:50] <relaxed> wrong [04:51] <SLAYBoz> i can convert mkv video to .asf video? [04:51] <SLAYBoz> using ffmpeg [04:51] <relaxed> yes [04:51] <SLAYBoz> let me try [04:51] <relaxed> ffmpeg -formats 2>&1|grep asf [04:52] <relaxed> you need to do more research before you flood this channel with incomplete sentences and silly questions. [04:55] <SLAYBoz> it does support asf but not .ts [04:55] <relaxed> ffmpeg -formats 2>&1|grep mpegts [04:56] <SLAYBoz> it shows up [04:56] <SLAYBoz> what am i doing wrong then [04:56] <SLAYBoz> ffmpeg -i R:\b.mp4 -vcodec copy -acodec copy b.ts [04:57] <relaxed> You can't copy any stream into any container. [04:58] <SLAYBoz> b.flv and b.asf worked [04:59] <relaxed> Some containers only support certain A/V codecs. I expect you to google for more info. [04:59] <SLAYBoz> i know ts supports avc [05:01] <SLAYBoz> i guess that explains ts are rare [05:01] <SLAYBoz> but i don't get it [05:02] <relaxed> google until you do get it. [10:13] <rager> hi - I lost that video player example someon linked me a while back - can someone link me one for current ffmepg release? I'm trying to get some bindings to work, still [10:38] <rager> it was a relatively short c script that opened and played a video files [11:21] <zap0> rager, videolan libVLC? [13:07] <pyBlob> I've created a video, now when a scene change happens, I want to extract the first frame of the new scene, is there a good way to do that? [13:12] <zap0> py google `scene change ffmpeg` [13:13] <zap0> there are many "scripts" out there [13:13] <zap0> on the interwebs [13:13] <pyBlob> everything depends on the order you type it xD [13:20] <benbro1> I have img1.png, img2.png... instead of img001.png... [13:20] <benbro1> what can I use instead of img%03d.png ? [13:20] <pyBlob> try img%3d.png [13:23] <benbro1> doesn't work [13:23] <pyBlob> :/ [13:23] <benbro1> Could find no file with path 'frame%3d.png' and index in the range 0-4 [13:23] <pyBlob> img%d.png ? [13:23] <benbro1> seems to work :) [13:24] <benbro1> thanks [14:37] <padawanc> Hi everybody [14:37] <padawanc> Doesn't anyone know how to audio and video without capturing microphone? [14:38] <padawanc> I'm capturing some video lessons from a website, but when I speak or something the audio is put in the recorder too. [14:39] <padawanc> My paste http://pastebin.com/LgAzEwNq [14:39] <padawanc> how to capture audio and video* [14:46] <padawanc> To be more simple, I don't want to record my voice, just the sound that comes from the default output. [19:15] <mrmargolis> I am trying to extract information from a file that is on S3. ffmpeg/ffprobe do a great job of streaming part of the file to get the headers, but I am not getting particularly great throughput. Does anyone know if there is configuration that might help speed up http/https streaming? [19:16] <klaxa> try to improve the network? [19:17] <mrmargolis> I have run it on really fast connections, still takes longer than I was hoping [19:17] <mrmargolis> The command I am running is http://pastebin.com/K9j8DNjX [19:17] <mrmargolis> I know that S3 throttles individual connections, I doubt that ffprobe supports threaded download of the file... but that would likely help [19:19] <mrmargolis> I need to grab a handful of frames to make a guess at interlaced vs progressive, so I am reading more than just the headers, but not the whole file. [19:22] <klaxa> i doubt ffprobe/ffmpeg support that [19:22] <klaxa> however, maybe there is a project that uses multiple connections to download a file and output it in the right order via stdout [19:22] <klaxa> you could pipe that to ffprobe/ffmpeg [19:23] <mrmargolis> that's a good idea [20:23] <femtocoin> hi [20:23] <femtocoin> I am trying to concatenate mp4 video files and i get this message [20:24] <femtocoin> http://pastebin.com/b6AsGdPY [20:26] <femtocoin> ok ok cool [20:26] <femtocoin> wait a minute while i do proper pastebin [20:40] <femtocoin> Hi [20:40] <femtocoin> I posted the problem here [20:40] <femtocoin> http://pastebin.com/T3gUeB1H [20:40] <femtocoin> its about concating mp4 files [20:41] <femtocoin> i get weird warnings although the final mp4 "kindof works"...but trying to fastforward to a certain position breaks my player (VLC),.., maybe navigational information (fastforward in time etc) is lacking or broken? [20:41] <femtocoin> if anyone can look into it, i would appreceate it [20:51] <femtocoin> oh shit, i am playing that video and it broke [20:51] <femtocoin> lol [20:51] <klaxa> lol [20:53] <klaxa> you could try putting all the files into mpeg ts, just concat them in your shell and then put it back into mp4 [20:59] <viric> can mpeg ts be concatted? [20:59] <viric> with success, I mean [21:02] <re-G> i think yes [21:02] <femtocoin> klaxa [21:03] <femtocoin> what do you mean? [21:03] <femtocoin> mpeg ts,?? what is that how do i do that? [21:03] <femtocoin> i posted my commandline in paste bin [21:03] <femtocoin> http://pastebin.com/T3gUeB1H [21:04] <femtocoin> i use only mp4 files [21:04] <femtocoin> your sentence doesnt make any sense to me [21:04] <femtocoin> "just concat them in your shell and then put it back into mp4" [21:05] <femtocoin> i concat them and the result is an mp4 file, so what is that "putting it back into mp4"?? mean [21:06] <klaxa> see the concat protocol part in the docs (https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%2…) [21:06] <klaxa> and with shell i mean: cat file1.ts file2.ts file3.ts > all_files.ts [21:21] <femtocoin> what? Klaxa as you can see my command line i dont use *.ts files [21:21] <femtocoin> how do i create them? [21:21] <klaxa> ffmpeg -i some_file.mp4 -c copy -f mpegts some_file.ts [21:22] <klaxa> you can concat mpeg ts without having to worry about headers and such, you can't do that with mp4 [21:22] <klaxa> you then put it back to mp4 with: ffmpeg -i all_files.ts -c copy all_files.mp4 [21:22] <femtocoin> aha [21:23] <femtocoin> i am on windows, i need to binary copy then i think [21:23] <femtocoin> no 'cat' here) [21:23] <viric> copy /b [21:25] <femtocoin> if i have a long list of files must i do every time ffmpeg -i some_file.mp4 -c copy -f mpegts some_file.ts? [21:25] <femtocoin> cant i use a file list? [21:28] <viric> write a script [21:28] <femtocoin> Hi, i tried for one file and i get this error [21:28] <femtocoin> [mpegts @ 029ad380] H.264 bitstream malformed, no startcode found, use the h264_mp4toannexb bitstream filter (-bsf h264_mp4toannexb) [21:28] <femtocoin> av_interleaved_write_frame(): Invalid argument [21:29] <femtocoin> ok adding bitstream filter to command line as specified by error message, see what happens [21:31] <femtocoin> works [21:31] <femtocoin> i have all the timestamp *.ts files [21:31] <femtocoin> now i do concat [21:46] <femtocoin> ok klaxa [21:46] <femtocoin> i got it working but weird shit let me explain [21:47] <femtocoin> ffmpeg -i all_files.ts -c copy all_files.mp4 n<< didnt work i get an AAC [mp4 @ 03bf2020] Malformed AAC bitstream detected: use audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg [21:47] <femtocoin> av_interleaved_write_frame(): Operation not permitted [21:48] <JEEB> that's because you use different types of AAC bit streams for mpeg-ts and mp4 [21:49] <JEEB> add that bsf:a command and it should work [21:49] <JEEB> (after -i) [21:49] <femtocoin> ok, i created the *.ts files from *.mp4 files [21:49] <femtocoin> so when creating the ts files i add this filter? ok [21:50] <JEEB> eh? [21:50] <JEEB> you just said you got that error when creating mp4 from the ts? [21:50] <JEEB> ffmpeg -i all_files.ts -c copy all_files.mp4 <- this clearly has ts as input, and mp4 as output [21:50] <femtocoin> klaxa posted ffmpeg -i some_file.mp4 -c copy -f mpegts some_file.ts? [21:50] <femtocoin> ok JEEB [21:50] <femtocoin> i have 8 mp4 files [21:50] <femtocoin> i want to concatenate them [21:51] <femtocoin> the standard command line i got from the manual is not cutting it [21:51] <femtocoin> i get all kinds of timestamp errors [21:51] <femtocoin> so i did this [21:51] <femtocoin> ffmpeg -i some_file.mp4 -c copy -f mpegts some_file.ts [21:51] <femtocoin> for all 8 files, then do cat file1.ts file2.ts ... > final.ts [21:51] <femtocoin> then create mp4 from the final.ts file [21:51] <JEEB> yes? [21:52] <femtocoin> but when doing the last part i get that crazy error [21:52] <JEEB> and you get the error at the last point, right? [21:52] <femtocoin> aac [21:52] <femtocoin> yes [21:52] <JEEB> yes, then I thought correctly [21:52] <femtocoin> ok ok [21:52] <JEEB> and you should heed the goddamn errorr [21:52] <JEEB> it tells you how to fix it! [21:52] <JEEB> when creating the final mp4 [21:52] <femtocoin> sure i add the filter [21:52] <femtocoin> but not working)) [21:52] <JEEB> ok, then there's something else [21:52] <JEEB> post the command and terminal output on a pastebin [21:52] <JEEB> link here [21:53] <femtocoin> no problem [21:53] <femtocoin> moment [21:57] <femtocoin> http://pastebin.com/QwJHeMFT [21:58] <femtocoin> highlighted the error messages [21:58] <JEEB> ugh [21:58] <JEEB> -c -bsf:a aac_adtstoasc copy [21:58] <JEEB> guess what is wrong here [21:58] <femtocoin> ooh [21:58] <femtocoin> ok [21:58] <JEEB> -bsf:a is not a setting for -c :P [21:59] <JEEB> -c copy -bsf:a aac_adtstoasc [21:59] <femtocoin> LOOOL [21:59] <femtocoin> ok [21:59] <femtocoin> oopsy [22:00] <femtocoin> works like a charm [22:00] <femtocoin> oh by the way, when i select final file to be *,mpeg i dont have to add the filter, why is that? [22:01] <JEEB> because you're remuxing into a format that doesn't have a different bit stream format for AAC [22:01] <JEEB> ADTS is generally used in MPEG-TS and similar formats, ASC is used in MP4 [22:01] <femtocoin> okidoki [22:04] <femtocoin> JEEB, (and everyone who was helpfull, i freaken love you guys, it works like a charm) [23:14] <farsheed> Question: Any available sites for latest non-free ffmpeg binaries for linux64 with x11-grab? [00:00] --- Mon Dec 16 2013

1 0

ffmpeg-devel.log.20131214
by burek 15 Dec '13

15 Dec '13

[00:58] <BBB> ubitux: did you look at simd? is it ok for you or have big comments? [00:59] <ubitux> i didn't yet, i'll have a look tomorrow, but doubt i'll have a lot of comments though [01:56] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:f5cf0ea93a55: avformat/asf: clear uninitialized areas of packets before returning them [01:56] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:cf95dee3de59: avcodec/vc1dec: dont calculate unused values from uninitialized sprites [01:56] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:5f00b333a4c3: avcodec/vc1dec: zero SpriteData struct [01:57] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:48016f8febe6: avcodec/vc1dec: propagate errors from vc1_parse_sprites() [02:14] <wm4> should the hypothetical high level API be powerful enough to handle crap like dvdnav? [02:29] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:3f4290a2060b: swscale/x86/rgb2rgb_template: try to fix build without AVX [03:01] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:445c58a8c6be: swscale/x86/rgb2rgb: Make sure COMPILE_TEMPLATE_AVX is defined [03:37] <cone-382> ffmpeg.git 03Guillaume Martres 07master:c6afd0aacc31: hevc: fix PTL parsing [03:37] <cone-382> ffmpeg.git 03Guillaume Martres 07master:dddc9b7a8ec3: hevc: don't check for errors in PTL code [03:37] <cone-382> ffmpeg.git 03Guillaume Martres 07master:8e72e19f6468: hevc: remove unused PTL flags [03:37] <cone-382> ffmpeg.git 03Guillaume Martres 07master:c90cdf4b6444: hevc: pack PTL representation using uint8_t [03:37] <cone-382> ffmpeg.git 03Guillaume Martres 07master:ecb21d24373c: hevc: rename ptl structs and variables [11:13] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2cfccd8060b9: avcodec/vc1: Factorize imode enum out / remove duplication [11:23] <cone-938> ffmpeg.git 03Diego Biurrun 07master:70a7b24d56a8: avutil: Add deprecation ifdefs around obsolete intfloat code [11:23] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:acda7c8e20dc: Merge commit '70a7b24d56a823894440a372c46e89e212b89c35' [11:33] <cone-938> ffmpeg.git 03Luca Barbato 07master:7cbe1ea9df83: configure: Move the bz2 and zlib checks below phtreads [11:33] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:7431923da8b7: Merge commit '7cbe1ea9df83ec66403fbf6400353bcb2242bf06' [11:54] <ubitux> BBB: +%if ARCH_X86_64 ; TODO: 32-bit? (32-bit limited to 8 xmm reg, we use 13 here) [11:54] <ubitux> 16 for you afaict [11:56] <ubitux> where are the benchs? :p [12:45] <cone-938> ffmpeg.git 03Luca Barbato 07master:a5a3b398fd9d: configure: Reorder pthreads checks [12:45] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:f5013913da36: Merge commit 'a5a3b398fd9dce38ca50b20f182b17a256d209f2' [13:19] <cone-938> ffmpeg.git 03Luca Barbato 07master:c85aad9cb2af: doxy: Define a group for libswscale documentation [13:19] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:688c3d944de3: Merge remote-tracking branch 'qatar/master' [13:21] <saste> michaelni, ping on "ffserver: add stream Metadata option" [13:40] <BBB> ubitux: 16x16 = 16, 8x8 = 13, yes [13:41] <BBB> ubitux: will update comment [13:41] <BBB> ubitux: bench coming up, sec [14:02] <cone-938> ffmpeg.git 03Stefano Sabatini 07master:54c596fe7a5f: lavf/movenc: improve feedback in case of unsupported codec [14:02] <cone-938> ffmpeg.git 03Stefano Sabatini 07master:2cfe70ff3eb9: lavf/movenc: return meaningful error code from mov_write_header() [14:02] <cone-938> ffmpeg.git 03Stefano Sabatini 07master:66a703ea0168: ffprobe: only show tags when explicitly requested [14:03] <BBB> 9.7 -> 9.3 sec total decoding time for ped1080p.webm, and cycle timings from ~4100 -> ~750 for non-dc-only and ~950 -> ~130 for dc-only [14:03] <BBB> not bad, not bad [14:04] <cone-938> ffmpeg.git 03Timothy Gu 07master:b242c156e5b9: examples/resample_audio: check av_samples_get_buffer_size() return code [14:04] <cone-938> ffmpeg.git 03Timothy Gu 07master:c65fe9e9822c: examples/decoding_encoding: check av_samples_get_buffer_size() return code [14:09] <BBB> ubitux: patch updated [14:10] <BBB> give me a few minutes to test before I send it out [14:15] <BBB> ubitux: patch sent [14:16] <ubitux> BBB: did you upload ped1080p.webm somewhere? [14:34] <BBB> no, I could [14:34] <BBB> I probably should [14:34] <BBB> I'll try to find some space somewhere [14:35] <ubitux> mega.co.nz? [14:36] <BBB> nah something that sounds legit [14:36] <BBB> at 2 threads we beat libvpx already [14:36] <BBB> not bad [14:37] <BBB> and we're still massively c [14:37] <BBB> (libvpx goes from 8.3 -> 6.9, we go from 9.3 -> 5.9) [14:38] <ubitux> great [14:39] <ubitux> i didn't know libvpx was threaded [14:39] <BBB> threaded loopfilter and threaded tiles, afaik [14:40] <BBB> so this one uses threaded loopfilter [14:40] <ubitux> ok :p [14:41] <BBB> anyway, I'll do other 16x16 subforms now, and then 32x32, and in between try to fix that parallelmode bug we both saw [14:41] <BBB> and maybe that crasher you reported [14:41] <ubitux> :) [15:20] <BBB> I see basically all fixable runtime sitting in various loopfilter functions and 32x32 idct [15:20] <BBB> so the todo list is quite easy [16:57] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:017e234c204f: avcodec/vc1: fix mb_height for field pictures [17:42] <BBB> ubitux: also slightly updated patch on my github without the FIXME SWAPs [17:42] <BBB> I'll work on subidcts now, I don't feel like redoing the register ordering, it has no benefit [17:42] <ubitux> :) [17:44] <BBB> the subidcts have a real speed gain, in particular b/c in almost all cases the primary things that disappear are the slow VP9_UNPACK_MULSUB_2W_4X things [17:45] <BBB> (it's not like they can be sped up, they just do very difficult stuff) [17:45] <BBB> so if you can get rid of them in subidcts, it has massive benefit for the whole function [17:45] <ubitux> is there a benefit of having the 2 passes in VP9_IDCT16_1D? [17:45] <ubitux> they're at the end of the macro [17:46] <ubitux> (btw, weird align in the comments of the pmulhrsw calls) [17:47] <ubitux> (in "from 3 stages back" sry) [17:51] <BBB> alignment fixed [17:52] <BBB> the 2-pass is basically because they very specifically depend on integrating with the final piece of the idct, that is, they are very state-dependent [17:52] <BBB> this piece for example: [17:52] <BBB> SUMSUB_BA w, 6, 9, 15 ; t6, t9 [17:52] <BBB> SUMSUB_BA w, 7, 8, 15 ; t7, t8 [17:53] <BBB> that's actually the end of the 1d idct, interleaved with the writing out (pass 2) or transpose (pass 1) to make the whole thing more optimal [17:53] <BBB> so I think here it helps; for the 8x8/4x4, what you did was better [17:54] <BBB> new patch with alignment-fix on github btw [17:56] <ubitux> ok [17:56] <ubitux> +%macro VP9_STORE_2XFULL 6; dc, tmp1, tmp2. tmp3, tmp4, zero [17:56] <ubitux> '.' instead of ',' [17:58] <ubitux> in that macro, i'm not sure, but would it be somehow possible to do the add post packuswb? [17:59] <ubitux> so you would only do 2 add instead of 4 [17:59] <ubitux> might not be possible at all, just wondering [18:01] <ubitux> BBB: btw, no way to put [pw_512] into a reg in the second pass? [18:03] <ubitux> actually you might be a short in reg anyway :p [18:04] <BBB> right, each reg means two movas to store/load it [18:04] <BBB> dit fixed [18:04] <BBB> dot* [18:05] <BBB> add before instead of after, where? in VP9_STORE_2XFULL? [18:05] <ubitux> yes [18:05] <ubitux> like doing the add byte oriented or sth [18:05] <ubitux> probably not a good idea :p [18:05] <BBB> I think it can be in the [-255,255] range, so there's no way to be 8bit [18:08] <ubitux> no other comment from me :p [18:08] <ubitux> looks nice [18:11] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:c9f72e4b81ae: avcodec/vc1dec: fix mby_start for interlaced content [18:11] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2224159c787e: avcodec/vc1: fix DIFF2/NORM2 with width<=16 [18:12] <BBB> michaelni: merge request github/rbultje/ffmpeg/vp9-simd? [18:12] <BBB> michaelni: slightly updated version of the patch on the ml [18:12] <ubitux> you still haven't added yourself to the copyright btw [18:12] <BBB> oops [18:13] <BBB> fixed [18:13] <BBB> let's hope michaelni isn't mega-fast [18:36] <cone-938> ffmpeg.git 03Ronald S. Bultje 07master:8d4c616fc05f: vp9/x86: idct_add_16x16_ssse3. [18:36] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:2d50ebc20b61: Merge remote-tracking branch 'rbultje/vp9-simd' [19:25] <cone-938> ffmpeg.git 03Yu Xiaolei 07master:20bc574b862b: build fix: apetag.c depends on img2.c [19:38] Action: Daemon404 wonders how much faster ffmpeg is than libvpx now [19:40] <BBB> Daemon404: 1 thread libvpx 8.3 sec we 9.3 sec, 2 threads libvpx 6.9 we 5.9 (IIRC) [19:40] <BBB> Daemon404: libvpx is mostly simd'ed, we are not yet, so we're not yet faste [19:40] <BBB> Daemon404: probably after simd is done, we'll be faster [19:41] <Daemon404> ah [19:41] <Daemon404> i seem to remember ffvp8 being much faster [19:52] <smarter> Daemon404: BBB made libvpx fast ;) [19:52] <BBB> ffvp8 was much faster [19:53] <BBB> _after_ the simd was done [19:53] <BBB> ffvp9's simd is not done, again [19:53] <BBB> so it's not yet faster [19:53] <Daemon404> yes [19:53] <BBB> or you mean ffvp8 vs libvpx when you asked ffmpeg vs libvpx? [19:59] <BBB> Daemon404: you have to realize that if for sth. like 16x16 idct, I can make the function 5x faster, then simd is going to have a massively disproportionate effect on total speed [19:59] <BBB> so as long as they have disproportionally more simd than us, they will be faster [20:00] <Daemon404> [18:53] <@BBB> or you mean ffvp8 vs libvpx when you asked ffmpeg vs libvpx? <-- just a quip [20:00] <BBB> oh ic [20:00] <Daemon404> its not a matter of if [20:00] <Daemon404> but when [20:00] <Daemon404> is what i meant [20:00] <BBB> yeah [20:00] <BBB> help write simd [20:37] <kierank> smarter: do you know what they are doing about chroma siting for hevc interlaced? [20:41] <BBB> ubitux: if you want more review fun - https://github.com/rbultje/ffmpeg/commits/vp9-simd [21:01] <kierank> can someone pm me the ffmpeg incoming read username/password [21:01] <kierank> i remember the username but not the host and username [21:02] <kierank> i remember the password i mean [21:02] <Daemon404> whats the poitn of having a non-anonymous place for sampels to be uploaded [21:02] <Daemon404> thats the opposite of how everyone does it [21:05] <nevcairiel> i always wanted to write a small upload webapp like the one vlc has, with some fancy logic inside to help organize them, since people always pick the worst one-click hosters [21:05] <smarter> kierank: I don't know anything about interlaced stuff [21:07] <JEEB> kierank, I thought it was shared with mplayer? [21:07] <JEEB> and was anonymous [21:07] <JEEB> ftp://upload.mplayerhq.hu/incoming/ [21:08] <JEEB> at least I remember the ffmpeg trac at one point pointing you towards mplayer for the bigger samples [21:48] <rcombs> https://trac.ffmpeg.org/ticket/1582#comment:11 <-- anyone know what the details of full_chroma_int in swscale are, and whether or not that can be made the default behavior? [21:49] <cone-938> ffmpeg.git 03Timothy Gu 07master:96093fe18024: Changelog: correct typo [21:49] <cone-938> ffmpeg.git 03Stefano Sabatini 07master:de9ea40a40d8: doc/bitstream_filters: remove mp3_header_decompress filter [21:50] <ubitux> wut? [21:50] <ubitux> saste: no? [21:50] <ubitux> BBB: will look :) [21:51] <saste> ubitux, the commit was wrong [21:51] <ubitux> saste: 75ec40b083ff40655a81c709ba5c9d867b2ed8a4 [21:51] <ubitux> The decompress filter is left in place for interoperability and support of [21:51] <ubitux> files that used the compress filter. [21:52] <saste> ubitux, s/decompress/compress [21:52] <saste> compress is gone [21:52] <ubitux> ok [21:52] <ubitux> commit message was wrong, ok [21:52] <saste> I mean the commit message was wrong [21:57] <wm4> rcombs: usually the trade off is speed vs. quality [21:57] <wm4> but I think nobody really knows what swscale does and when it can subtly fail at something [21:58] <wm4> so bugs are possible too [21:58] <wm4> when using "obscure" flags [21:59] <rcombs> the behavior without it when doing 10bit->8bit is quite bad [22:00] <nevcairiel> and the speed with it is quite low :D [22:01] <rcombs> ouch [22:01] <nevcairiel> well test for yourself, it usually works fine, but has quite the performance hit [22:01] <wm4> the main use for libswscale was traditionally as conversion filter for playback in mplayer AFAIK [22:01] <wm4> so the defaults are tuned for speed [22:01] <rcombs> I'd only tried it for single screenshots [22:02] <nevcairiel> there are reasons why i wrote my own conversions for most common cases ;) [22:03] <rcombs> so, could improve either the +full_chroma_int option's speed, or the default's quality [22:04] <rcombs> I'm not sure which would be easier, but defaulting to discoloring the output seems like a Bad Thing" [22:07] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:892562e9218b: avformat/ipmovie: Check OPCODE_CREATE_TIMER size [22:12] <wm4> rcombs: well, every application is supposed to supply its own flags [22:12] <wm4> until recently, it even had it explicitly select a scaler algorithm [22:15] <cone-938> ffmpeg.git 03Diego Biurrun 07master:5db4e88ecd32: configure: Detect Solaris libc in an OpenIndiana/illumos compatible way [22:15] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:f357ef2e0ce1: Merge commit '5db4e88ecd32485341f6150c00f5ee5bfa74f62d' [22:15] <rcombs> well, is anyone against using full_chroma_int in ffmpeg by default? [22:17] <kierank> what does that thing even do [22:17] Action: kierank has never known [22:17] <nevcairiel> swscale is so brilliant that it converts everything to yuv420, even if it just has to convert from yuv444 10-bit to yuv444 8-bit, it can go through 420 if that flag is not set :p [22:17] <rcombs> kierank: I'm not sure of the specifics of it, but I know it changes the behavior of dithering so there's significantly less banding and fixes discoloration of the output [22:18] <rcombs> not sure how, and now I know it has negative performance implications [22:18] <nevcairiel> ie without the flag, it can drop lots of chroma information [22:18] <rcombs> nevcairiel: that's incredibly shitty [22:18] <kierank> I've always cargo culted and set the flag [22:18] <rcombs> in my test, the input was yuv420p10LE [22:18] <nevcairiel> not sure what happens in that case [22:19] <nevcairiel> whats the output? [22:19] <wm4> rcombs: welcome to swscale [22:19] <wm4> everyone seems to hate it [22:19] <rcombs> rgb24 [22:19] <nevcairiel> ah ok, if you enable the flag, it disables the cheap-but-fast "optimized" yuv->rgb converter [22:19] <wm4> but it does all-to-all conversions from >100 pixel formats, so it's kind of... needed [22:19] <nevcairiel> it feels like it does point scaling of chroma [22:19] <wm4> *for [22:20] <nevcairiel> with the flag it does proper upscaling of the chroma [22:20] <nevcairiel> which is SIMD optimized, but still slower [22:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:417927af3c99: hdsenc: Avoid integer overflow [22:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:b8ed15d6378f: hdsenc: Fix an off by one error in an array size check [22:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:797f2a791397: hdsenc: Check the init_file() return code [22:25] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:6659364d3a47: Merge commit '797f2a791397210ec1b591b326658805c5dbf104' [22:37] <BBB> nevcairiel is right, by default swscale converts everything to 420 _when scaling_ [22:38] <BBB> "scaling" is a very obscure term here and doesn't mean what you think it means [22:38] <BBB> it basically means "there is no direct conversion function OR the input/output sizes are not identical" [22:39] <BBB> and yes this means that when you go from 320x240 444 to 640x480 420, it will actually downscale the chroma to 160x120 420 before upscaling it back up to 320x240 for the 640x480:420 [22:39] <wm4> wow [22:39] <BBB> unless you set full_chroma_int [22:39] <BBB> or actually this is full_chroma_inp [22:39] <BBB> int=interpolation, inp=input [22:40] <cone-938> ffmpeg.git 03Martin Storsjö 07master:6451c8853a07: sdp: Check theora colorspace before producing the configuration string [22:40] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:09c13ff7bdbc: Merge commit '6451c8853a07ff2e28bda950fb5e83fcf88c5cf4' [22:40] <BBB> lots of fun [22:40] <JEEB> the lovely swscale [22:40] <BBB> \o/ [22:41] <BBB> swscale is a great conversion lib for any-to-any... it has some good conversions for old colorspace formats, like rgb<>yuv [22:41] <BBB> but it hasn't kept up with more revent developments like 444 or >8bpp [22:41] <BBB> so when you use these kind of things, it basically kinda sucks [22:41] <JEEB> I wonder how swscale compares to avery lee's similar thing [22:41] <JEEB> which also tries to support most paths without having too many specific paths [22:42] <wm4> what happened to the thing used with vapoursynth? [22:42] <JEEB> still around [22:43] <wm4> does it suck or rock? [22:44] <JEEB> relatively OK, still doesn't have too many generic paths IIRC [22:45] <Daemon404> the development methodology is shit [22:45] <Daemon404> "post zips on doom9" [22:45] <JEEB> yes [22:45] <wm4> lol [22:45] <wm4> I wonder why people are doing this [22:45] <wm4> git is so much more convenient [22:45] <Daemon404> because it is doom9 [22:45] <Daemon404> and theve been doing it that way for decade+ and the hate change [22:45] <Daemon404> why do you think people are sitll forking avs (see: avs+) [22:46] <wm4> meh [22:46] <Daemon404> a lot of the vapoursynth hate is "but it's not avisynth" [22:47] <Timothy_Gu> TBH *synth is a lot more powerful than lavfi [22:48] <Timothy_Gu> And easier to use. [22:48] <wm4> heh [22:48] <Timothy_Gu> I still can't manage deinterlacing my old DVD using FFmpeg yadif... (yeah i know it should go into #ffmpeg) [22:49] <wm4> hm, yadif usage should be pretty simple, though [22:49] <nevcairiel> some old dvds are especially evil though [22:51] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:9aba0a6f7b3d: rtpdec_h264: Check the return value of functions doing allocations [22:51] <cone-938> ffmpeg.git 03Michael Niedermayer 07master:12e81041200d: Merge remote-tracking branch 'qatar/master' [23:05] <Daemon404> Timothy_Gu, people use yadif because it can do realtime [23:05] <Daemon404> not because it is good [23:15] <Timothy_Gu> saste: why do you do http://git.videolan.org/?p=ffmpeg.git;a=commit;h=de9ea40a40d8324c44ba9c2027… ? [23:16] <Timothy_Gu> saste: see http://git.videolan.org/?p=ffmpeg.git;a=commit;h=75ec40b083ff40655a81c709ba… [23:16] <Timothy_Gu> "The decompress filter is left in place for interoperability and support of files that used the compress filter." [00:00] --- Sun Dec 15 2013

1 0

ffmpeg.log.20131214
by burek 15 Dec '13

15 Dec '13

[00:38] <slorbast> oh derp, an easy solution would be to convert the video into images, then use imagemagick to add the text, then ffmpeg the images back to a video at same FPS [00:44] <relaxed> slorbast: there's ffmpeg filters for that [00:46] <relaxed> slorbast: man ffmpeg-all|less +/^' drawtext' [00:47] <slorbast> relaxed, thanks I'll check it out [03:20] <SirCmpwn> given an mkv file with some font attachments in it [03:20] <SirCmpwn> can I extract them to a second file with ffmpeg? [03:22] <SirCmpwn> yes, I can [03:22] <SirCmpwn> -dump_attachment, if anyone was wondering [04:26] <SLAYBoz> what is best container out of these 3? flv/mpfour/mkv [04:28] <chiller-> ...best for what? [04:30] <zap0> gif is teh bestest!!!1111eleventy11!!11 [04:32] <SirCmpwn> gif is not a container :( [04:37] <zap0> stop being sensible. [05:26] <liam-kelly> Hello, I am having some issues running a command in ffmpeg, http://pastebin.com/vftYQ54v [05:32] <SirCmpwn> liam-kelly: build ffmpeg from source and include libx264 [05:35] <liam-kelly> Thanks. [05:40] <SLAYBoz> does ffmpeg support h265 encoding [06:16] <relaxed> SLAYBoz: decoding only right now [06:16] <SLAYBoz> why no encoding [06:17] <relaxed> because it's too new [06:22] <SLAYBoz> i cannot even playback [06:23] <relaxed> what does this return: ffmpeg -codecs 2>&1| grep hevc [06:23] <SLAYBoz> nothing [06:23] <relaxed> then you need to update ffmpeg to a more recent version. git head would be best [06:26] <SLAYBoz> okay fixed [06:26] <SLAYBoz> does vlc use ffmpeg to play [06:26] <SLAYBoz> it won't work with vlc [07:00] <SLAYBoz> what is the difference between aac and he-aac [07:11] <SirCmpwn> are there any containers that will take a font file as an actual stream, and not as an attachment? [07:24] <LithosLaptop> SLAYBoz: When you encode to HE-AAC from 44.1Khz input the output file will be 22.05Khz LC-AAC with additional SBR info to replicate the missing high frequencies [07:24] <LithosLaptop> just basically some tricks to make the audio sound semi-acceptable <= 80Kbps [07:24] <SLAYBoz> what if you encode original 22 khz file [07:25] <LithosLaptop> hmm not sure what it will do then [07:26] <LithosLaptop> but only use HE-AAC <= 80Kbps, because it will only worsen the audio once you go above 80Kbps [07:26] <LithosLaptop> in that case use LC-AAC [07:26] <SLAYBoz> what is the difference between aac-fdk aac-avcodec [07:27] <LithosLaptop> aac-fdk is a high quality AAC encoder that supports lots of different AAC profiles such as LD-AAC, HE-AAC, LC-AAC [07:29] <LithosLaptop> aac-avcodec only supports LC-AAC and you need about >=240Kbps for it to sound acceptable [07:30] <SLAYBoz> what are lib name for aac-fdk and aac-avcodec [07:30] <LithosLaptop> libfdk_aac [07:31] <LithosLaptop> and aac [07:31] <SLAYBoz> okay what about "aac-avcodec" [07:32] <LithosLaptop> Quality from high to low: libfdk_aac > libfaac > aac > libvo_aacenc [07:32] <LithosLaptop> aac-avcodec is aac [07:32] <SLAYBoz> i see [07:32] <SLAYBoz> libvo is worst? [07:32] <LithosLaptop> yes [07:32] <LithosLaptop> terrible encoder [07:32] <SLAYBoz> somebody told me that was best [07:32] <SLAYBoz> libvo is the google one [07:32] <LithosLaptop> noooooo [07:32] <LithosLaptop> yes [07:33] <SLAYBoz> what about "ffmpeg-aac" one [07:34] <LithosLaptop> I would think aac-avcodec and ffmpeg-aac is the same thing [07:34] <LithosLaptop> where do you see these names? [07:34] <SLAYBoz> handbrake [07:35] <LithosLaptop> aac-avcodec and ffmpeg-aac two seperate options? [07:35] <SLAYBoz> old versions had aac(faac) and aac(ffmpeg) new version has aac(avcodec) aac(fdk) [07:36] <LithosLaptop> yes aac(ffmpeg) and aac(avcodec) is the same thing [07:36] <SLAYBoz> are you sure? [07:36] <LithosLaptop> aac(fdk) will give you the best quality [07:37] <SLAYBoz> okay thanks [07:37] <LithosLaptop> yes because ffmpeg uses avcodec [07:37] <SLAYBoz> where does nero and apple stand compared to this list: libfdk_aac > libfaac > aac > libvo_aacenc [07:38] <LithosLaptop> in my opinion: apple > libfdk_aac > nero > libfaac > aac > libvo_aacenc [07:38] <SLAYBoz> i see [07:39] <SLAYBoz> it's not possible to add apple on ffmpeg? [07:40] <LithosLaptop> there is no source code / library available for ffmpeg to use as far as I know [07:41] <SLAYBoz> i don't know if you use handbrake but handbrake for mac comes with aac(apple) but rest doesn't [07:41] <LithosLaptop> aple would ned to relese souce code for the apple encoder [07:41] <LithosLaptop> *aple [07:41] <LithosLaptop> *apple [07:42] <LithosLaptop> mac probably allready comes with an apple aac encoder. I am not sure [07:42] <SLAYBoz> is libfdk_aac pretty recent? [07:43] <LithosLaptop> yes [07:43] <SLAYBoz> i never seen it before [07:43] <SLAYBoz> i see [07:44] <SLAYBoz> is it new encoder or is it just new to ffmpeg? [07:44] <LithosLaptop> usually only faac was available, you will see lots of guides online still mentioning faac / libfaac [07:44] <LithosLaptop> new encoder [07:44] <SLAYBoz> i see [07:45] <LithosLaptop> released last year by Fraunhofer for Android [07:45] <SirCmpwn> -threads 0 [07:45] <SirCmpwn> this will use as many cores as it can, right? [07:45] <LithosLaptop> anyway I need to go [07:45] <SirCmpwn> relevant codecs: h264, theora, vp8 [07:45] <LithosLaptop> cheers [08:03] <SirCmpwn> the answer is that you can't encode theora with several cores ;_; [08:40] <SLAYBoz> is .ts a container? [10:45] <iamtakingiteasy> hello, when i am trying to record a monitor source of pulseaudio with ffmpeg, as in 'ffmpeg -f alsa -i pulse out.wav' ; i am getting pretty pitched down sound. but when i try to do 'arecord -f cd > out.wav'; with the same monitor source all is recorded just fine. where to look for the problem and how to fix it? [11:21] <SirCmpwn> say I want to extract a short clip from a mkv file [11:21] <SirCmpwn> this file has subtitles, though, advanced substation [11:21] <SirCmpwn> I want to extract the softsubbed clip, so I need to be able to modify the subtitles so that the timing isn't off [11:21] <SirCmpwn> suggestions? [12:32] <SirCmpwn> so here's a weird thing [12:33] <SirCmpwn> ffmpeg -dump_attachment:t:<index> [12:33] <SirCmpwn> always dumps t:0 [12:33] <SirCmpwn> and ignore the index specified [12:59] <Compn> use mkvextract :P [13:05] <SirCmpwn> nah, I got it working [13:05] <SirCmpwn> it was just behaving strangely [15:26] <luc4> Hello! Any way to dump the popularimeter frame of id3v2 tags in mp3s? [15:29] <jure> ffmpeg -i input.mp3 -mod:id3v2 popularimeter -dump -o out.mp3 (j/k) [15:33] <luc4> jure: Unrecognized option 'mod:id3v2' [15:34] <jure> j/k = just kidding [15:37] <luc4> jure: that didn't make me laugh... [15:40] <jure> :) [15:42] <luc4> jure: maybe I'd get it if I was good with ffmpeg :-) [17:44] <pj_double_u> does anyone have experience with ffmpeg API / libx264 and low latency streaming? [17:45] <Compn> pj_double_u : gaikow uses x264 in low latency streaming [17:45] <pj_double_u> i've read some guides and have come a long way [17:45] <Compn> but thats a gaming website [17:45] <Compn> heh [17:45] <Compn> ask in #x264 mayyybe ? [17:46] <Compn> i dont know low latency stuff so good luck [17:46] <pj_double_u> actually i think i've hit a barrier concerning mpegts, rather than x264 [17:46] <Compn> ah [17:46] <Compn> you going to write a howto for us ? [17:46] <Compn> whats your setup and which part is lagging ? [17:46] <Compn> command lines, etc [17:47] <pj_double_u> basically the trick is: -tune zerolatency,fastdecode -preset ultrafast :) [17:47] <pj_double_u> i'm programming in C, not using cli [17:47] <Compn> ah [17:47] <pj_double_u> but should offcourse also work on cli [17:48] <Compn> running into 5mb mpegts probe slowdown ? [17:48] <pj_double_u> the weird thing is that the latency is on the client side. [17:48] <pj_double_u> ffmpeg always seems to hold one frame (video) back [17:48] <pj_double_u> as in av_read_frame () returns one frame in the past. [17:49] <Compn> http://stackoverflow.com/questions/16690898/what-are-the-correct-x264-setti… [17:49] <Compn> you saw that i asssume [17:49] <pj_double_u> yes. thanx :) [17:49] <pj_double_u> that fixed latency on server side. [17:49] <pj_double_u> the server-side is now latency free -> an encoded frame gets transported immediately [17:50] <Compn> ah [17:50] <Compn> what ffmpeg ver you using ? [17:50] <pj_double_u> 2.1.1 [17:50] <Compn> its possible that av_read_frame thing was changed , if so, go back to old ffmpeg :) [17:50] <pj_double_u> the problem has been in ffmpeg for ages i'm afraid [17:51] <Compn> ah [17:51] <pj_double_u> i've done a project some time ago with ffmpeg 0.5. same problem. always one frame latency introduced on the client side [17:51] <Compn> so 1/30th of a second is too slow for you ? :) [17:52] <pj_double_u> however now, i really need to get rid of this one frame latency.. :P [17:52] <pj_double_u> it seems ridiculous, but yes :) [17:52] <Compn> eheh [17:52] <pj_double_u> 1/50th even! :P [17:53] <pj_double_u> i'm trying to get the video of a camera on the screen of a client application as fast as possible. every frame counts! :) [17:53] <Compn> well the only person i know who uses x264 low latency is jason (x264 dev) [17:53] <Compn> there maybe others here, if you stick around [17:54] <pj_double_u> i will thank u [17:54] <Compn> np [17:55] <Compn> michaelni might know about the av_read_frame ... or you might be using ffmpeg incorrectly. i dont know [17:55] <pj_double_u> could be, that's what i'm trying to find out :) [17:55] <pj_double_u> or i might be hitting a limt [17:56] <pj_double_u> does anyone know if the mpegts demuxer always introduces one frame latency (for video atleast)? [17:56] <pj_double_u> because it's OK for a private data stream (KLV) [17:56] <Compn> pj_double_u : http://comments.gmane.org/gmane.comp.video.ffmpeg.libav.user/6654 [17:58] <pj_double_u> aha! exactly my 'problem'. [17:58] <pj_double_u> i'm reading it further now. [17:58] <Compn> sounds like there was 2 frame delay 2 years ago [17:58] <Compn> nice to hear its down to 1 frame :D [17:59] <pj_double_u> haha. there _is_ progress yes :) [17:59] <Compn> btw i found that by google for >>> av_read_frame one frame delay [17:59] <Compn> so you can findd other posts [17:59] <Compn> now i go kinda afk , feel free to ask me other q [18:00] <pj_double_u> thanx! [18:01] <Compn> btw when you get it working, please write a small example C file if you can showing how to get perfect zero latency for other users :) [18:01] <pj_double_u> i will. [18:01] <pj_double_u> maybe on the wiki (streaming guide)? [18:11] <Compn> yes [18:50] <pj_double_u> Some more info: if i pass AVSTREAM_PARSE_NONE to the video AVStream, then the delay is gone. [18:51] <pj_double_u> However! now av_read_frame() is basecally 'broken' because it does not promise to return exactly one frame.. [18:53] <jure> aresample vs ar [20:03] <maujhsn> llogan...U "Nut" how the hell are you? [00:00] --- Sun Dec 15 2013

1 0

ffmpeg-devel.log.20131213
by burek 14 Dec '13

14 Dec '13

[00:15] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:180a0b1bcb52: avcodec/hevc_sei: fix use of uninitialized variables in decode_nal_sei_frame_packing_arrangement() [00:36] <clever> Daemon404: and its fixed [00:39] <clever> VO: [x11] 1920x1072 => 1920x1072 Planar YV12 [00:39] <clever> [swscaler @ 0xc3f0d0]using unscaled yuv420p -> rgb565le special converter [00:40] <clever> [swscaler @ 0xc3f0d0]No accelerated colorspace conversion found from yuv420p to rgb565le. [00:40] <clever> ok, thats going to really suck! [00:41] <Daemon404> what exactly are you converting to that colorspace for [00:41] <clever> mplayer didnt auto-detect a decent VO, so its converting the 1080p frames to rgb565le [00:42] <clever> and sending them to xorg, over shm i think [00:42] <wm4> oh god vo_x11 [00:42] <clever> wm4: exactly what i was thinking [00:46] <clever> -vo sdl does work, and avoids the colorspace conversion [00:47] <wm4> depends entirely what sdl is doing internally [00:48] <clever> lets see, 30 frames with sdl takes 11 seconds [00:48] <clever> wait no, 50 [00:49] <clever> 50 frames with x11 takes 11 seconds [00:49] <clever> ok, strange, x11 and sdl have the same performance... [00:50] <clever> [gl] no GLX support present [00:50] <clever> wm4: would this be an xorg problem, or an mplayer problem? [00:50] <wm4> on that platform it probably supports egl and gles only [00:51] <wm4> mplayer seems to have some support for that, but AFAIK it's extremely crappy [00:51] <wm4> (works on some other ARM board only) [00:51] <clever> and i didnt enable it at compile time [00:51] <wm4> so try that [00:51] <clever> i suppose i could just make a vo_rpi that uses video_render [00:55] <clever> hmmm, maybe fbdev might give more performance [00:56] <clever> 10 seconds to render 50 frames, slight visual corruption, and it had a segfault inside uninit_vcodec [00:57] <clever> and fbdev2 wants bgra! [00:57] <clever> ah, fbdev wants rgb565le, ok, neither is good right now [01:02] <clever> wm4: yeah, looks like the current design just wont work, -vo null gets 11 fps [01:02] <clever> its just too much data to be shuffling arround [01:02] <clever> doesnt matter how fast the vo is, it wont beat null [01:09] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:db8a53d86a71: avformat/sdp: fix memleak on error [02:12] <clever> the root problem right now seems to be that just getting a frame out of the gpu takes too long (0.032982), so i'm trying to get 2 at once, and let the async tasks do its job [02:12] <clever> the only side-effect, is that it will return the 'wrong' frame, one frame old [02:12] <clever> but it may already be doing that, i dont know how much omx is buffering on me [02:16] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:c5f15f40b9b2: avformat/rtpdec_h264: fix null pointer dereferences [02:16] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:5d8e4f6da03c: avformat/rtpenc: check av_packet_get_side_data() return, fix null ptr dereference [04:24] <cone-204> ffmpeg.git 03Lou Logan 07master:d546a59a8139: docs/outdevs: add a few simple ALSA examples [09:46] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:bed4eeab3304: MAINTAINERS: remove ffserver maintainership status notice [09:46] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:93f08827253c: ffserver: improve error feedback in case of av_write_frame() error [09:46] <cone-169> ffmpeg.git 03Stefano Sabatini 07master:65a3429e7ac1: ffprobe: add cosmetical empty line [09:47] <cone-169> ffmpeg.git 03Even Wiik Thomassen 07master:43f116d1621a: examples/demuxing_decoding: return error when no codec found [10:37] <cone-169> ffmpeg.git 03Clément BSsch 07master:b02d87936b3b: examples/demuxing_decoding: print the decoding error when it happens. [11:56] <saste> do we have some native tool to shift timestamps, with no transcoding? [11:59] <ubitux> -itsoffset [11:59] <ubitux> ? [12:02] <saste> uhm seems so... [13:38] <BBB> ubitux: ok current vp9-simd branch works - it's not very clean, I'll likely do a semi-rewrite in terms of register numbering, but at least it's something [13:38] <BBB> ubitux: performance-wise this is pretty much going to be it for the full 16x16, I'll write subforms over the next few days, maybe this weekend [13:40] <BBB> I'm not totally unhappy about it :) [13:53] <ubitux> BBB: yeaah :D [13:54] <ubitux> on my side, i'm almost done with the "fm" if :( [13:55] <BBB> \o/ [13:56] <BBB> loopflter takes very long, don't worry about it feeling slow [13:56] <BBB> vp8's version took me forever also, and it's trivial compared to the vp9 one [13:59] <BBB> as for your /2 question, if the number is always positive, just use >>1 [13:59] <BBB> if the number can be negative, use (x+(x<0))>>1 [13:59] <BBB> +x<0 is the same as psubb(mx, pcmpgtw(pxor(my, my), mx)) [14:00] <BBB> er, gtb [14:00] <BBB> not gtw [14:01] <BBB> and then for the rightshift, do something to maintain the sign, e.g. mx>>1 = por(pand(mx, 0x8080808080808080), psrlw(mx, 1)) [14:01] <BBB> (since there's no psrab) [14:03] <ubitux> i used michael's trick for the /2 [14:03] <ubitux> (the +1 and average with 0) [14:04] <BBB> just make sure you understand that the rounding of / and pavgb is different [14:04] <ubitux> yes that's why i did a +1 [14:04] <BBB> pavgb is >>, so -> -inf, / is -> 0 [14:04] <BBB> you might need to do a +x<0 [14:04] <ubitux> yes i think my current code assume unsigned all the time [14:04] <BBB> pavgb(mx, pcmpgtb(0, mx)) [14:04] <ubitux> i need to check that& [14:05] <BBB> ok, if that assumption is correct, then that's ok, yes [14:06] <BBB> I'm currently toying with reordering register operations so we always use tX==mX [14:07] <BBB> that would basically mean introducing a few macro wrappers that do more swaps, e.g. SUMSUB_AB in addition to SUMSUB_BA (where AB is just BA followed by SWAP A,B) [14:07] <BBB> and likewise a macro wrapper for UNPACK_MULSUB_2W_4X [14:08] <BBB> but maybe it's not worth it, I don't know [15:20] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:8f9569cfacb9: avfilter/vf_pullup: Factor free_field_queue() out [15:20] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:47eb15b989a0: avfilter/vf_pullup: fix memleak on error [15:59] <cone-382> ffmpeg.git 03Carl Eugen Hoyos 07master:fb5518cfb76a: Force one stream in caf muxer. [15:59] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:1d0995e3a59e: Merge remote-tracking branch 'cehoyos/master' [16:51] Action: ubitux just ordered a rpi to test clever work [16:51] <Compn> lol [17:00] <cone-382> ffmpeg.git 03Pierre Yves MORDRET 07master:0f02ea0afe96: libavcodec/dvbsub: fix for Display Definition Segment [17:01] <ubitux> can we have a sample for this ^ ? [20:30] <kierank> ubitux: he said maybe [20:30] <ubitux> ok :) [20:31] <kierank> I do wonder what the sample is about [20:31] <kierank> he said it wasn't a test suite [20:35] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:7439475e69f3: avformat/network: check ff_socket_nonblock() return and print a debug message [20:35] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:7d7a70136286: avformat/ipmovie: Fix use of uninitialized memory in OPCODE_INIT_VIDEO_BUFFERS [20:35] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:0c23ee131257: avcodec/mjpegdec: use mallocz for progressive blocks [20:36] <cone-382> ffmpeg.git 03James Almer 07master:782d48c3c126: configure: remove redundant definition of __USE_MINGW_ANSI_STDIO [20:50] <cone-382> ffmpeg.git 03Diego Biurrun 07master:a1d7d5524799: build: Do not add -g to HOSTCFLAGS [20:50] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:7b2a19cb9e66: Merge commit 'a1d7d5524799bd90bc5d12e8b3063238cc0c02dd' [21:24] <clever> Compn: ive got an idea that may fix all of this extradata problems [21:25] <clever> Compn: OMX_IndexParamNalStreamFormatSelect [21:25] <clever> Sets the format of NAL units that will be presented to the decoder (OMX_NaluFormatStartCodes or OMX_NaluFormatOneNaluPerBuffer). By default the decoder will try to guess the type based on the codec configuration data it has been given. This is parameter is currently only relevant for AVC streams. [21:27] <cone-382> ffmpeg.git 03Diego Biurrun 07master:bdc111a16209: configure: Detect newer (>=4.1) versions of MinGW32 [21:27] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:2a459f5d87f8: Merge commit 'bdc111a162094c14660d1e88839d103a4d79e42a' [21:32] <cone-382> ffmpeg.git 03Diego Biurrun 07master:7c3388711b72: configure: Add -D__USE_MINGW_ANSI_STDIO=1 to CPPFLAGS on MinGW32 [21:32] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:1e3718e2a1e7: Merge commit '7c3388711b7243d059db39aa04b754baf2156934' [21:42] <cone-382> ffmpeg.git 03Diego Biurrun 07master:79d9884e9590: build: Merge pthreads/w32threads OBJS declarations [21:42] <cone-382> ffmpeg.git 03Michael Niedermayer 07master:0f242e62b4b4: Merge remote-tracking branch 'qatar/master' [00:00] --- Sat Dec 14 2013

1 0

ffmpeg.log.20131213
by burek 14 Dec '13

14 Dec '13

[00:00] <SirCmpwn> thanks a bunch [00:00] <SirCmpwn> will this fail if no audio streams are present [00:00] <llogan> negative mappings are also do-able: -map 0 -map 1 -map -0:s -map -1:s [00:01] <llogan> iDunno. try it. [00:01] <SirCmpwn> yeah [00:07] <SirCmpwn> the answer is yes, if you were wondering [06:29] <SirCmpwn> is there a way to convince ffmpeg to keep a similar output bitrate compared to the input bitrate when converting ogg to mp3 (and back again) [06:38] <relaxed> SirCmpwn: why not use a lossless codec like flac or alac? [06:38] <SirCmpwn> I need to play it in the browser [06:39] <SirCmpwn> and I want it to get as close to the original quality as possible [06:39] <SirCmpwn> it's worth noting that an ogg file can exceed the maximum mp3 bitrate [06:40] <relaxed> -c:a libmp3lame -q:a 0 will give you the highest quality [06:41] <SirCmpwn> will that waste space if the input quality is lower than 320 kbps? [06:43] <relaxed> test it and see [06:43] <SirCmpwn> yeah [06:45] <SirCmpwn> relaxed: looks like it tries to choose the best bitrate to represent the actual content in, so far as I can tell [06:46] <SirCmpwn> the maximum bitrate for an mp3 is 320kbps, and it gave me a file with 257kbps [06:47] <relaxed> yes, you can do the same with libvorbis [06:47] <SirCmpwn> excellent, tahnks for the help [06:48] <SirCmpwn> thanks* [06:48] <relaxed> for libvorbis the quality scale is reversed: 10 highest - 1 lowest [06:48] <relaxed> -q:a 10 [06:48] <LithosLaptop> lwas just going to say that :) [06:48] <SirCmpwn> thanks, I would have screwed that up [06:54] <relaxed> according to `man oggenc` the default is 3 [07:09] <SLAYBoz> what is better ffmpeg aac encoder or faac aac encoder [07:12] <relaxed> libfdk_aac [07:12] <SLAYBoz> huh [07:12] <relaxed> libfdk_aac is the recommended aac encoder [07:13] <SLAYBoz> what is that [07:13] <relaxed> but between the two options you gave, faac [07:13] <SLAYBoz> i see [07:13] <SLAYBoz> what is libfdk_aac then [07:14] <relaxed> "libfdk_aac is the recommended aac encoder" [07:14] <relaxed> but you have to compile ffmpeg with support for it if it's not already [07:14] <SLAYBoz> who made libfdk-aac [07:15] <relaxed> https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [07:16] <SLAYBoz> i don't get it [07:17] <relaxed> what don't you get? [07:17] <SLAYBoz> who made libfdk-aac [07:17] <relaxed> Fraunhofer [07:18] <relaxed> use google for more info [07:18] <SLAYBoz> then why would ffmpeg support it [07:18] <SLAYBoz> ffmpeg has their own aac [07:18] <relaxed> ffmpeg has their own vorbis too, and it sucks [07:18] <relaxed> so we recommend libvorbis [07:19] <SLAYBoz> then what vorbis doesn't suck [07:19] <relaxed> LIBVORBIS [07:19] <SLAYBoz> i heard nero aac is best [07:19] <relaxed> then use that [07:20] <SLAYBoz> which libnero_aac is that it [07:21] <relaxed> ffmpeg has no support for nero's encoder [07:21] <SLAYBoz> i see, is it because it's closed? [07:25] <SLAYBoz> what is libfdk-aac [07:26] <SLAYBoz> sorry i mean libvo_aacenc [07:27] <relaxed> an aac encoder [07:27] <SLAYBoz> who made that one [07:28] <relaxed> google [07:28] <SLAYBoz> but fraunhofer one is better? [07:28] <SLAYBoz> and what is this one? libaacplus [07:28] <relaxed> for fuck's sake [07:29] <SLAYBoz> what's wrong? [07:35] <relaxed> I've told you the recommended one three times. [10:50] <BoR0> I have one video with the following parameters: Stream #0:0[0x21]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt470bg), 720x576 [SAR 16:11 DAR 20:11], 25 fps, 25 tbr, 90k tbn, 50 tbc [10:50] <BoR0> let that be video A [10:50] <BoR0> I have video B with the following parameters: Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 400x300 [SAR 1:1 DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc [10:50] <BoR0> how can I change video B to video A so that resolution, SAR/DAR fps and tbr are equivalent? [12:49] <stonie_> hi.. can i produce mp4 with interlacing tff? [12:55] <brontosaurusrex> stonie_, probably using x264 options http://mewiki.project357.com/wiki/X264_Settings#tff [12:56] <stonie_> tried -top 1 with -flags ildct+ilme [12:56] <stonie_> ty lemme read [12:57] <stonie_> how can i set "-tff" [12:58] <brontosaurusrex> try just -ttf after other x264 settings [13:09] <brontosaurusrex> stonie_, working? [13:13] <stonie_> mh i dont know exactly.. it shows MBAFF only (with mediainfo) ... is that correct? [13:46] <benbro> does mp4 have meta info in it? [13:47] <benbro> such as markers of a timeline [13:53] <Mavrik> benbro, depends what do you mean [13:53] <Mavrik> but yeah, mp4 has meta data like most formats :) [13:57] <benbro> Mavrik: I have a video created from a slideshow and I want to check if there is info of when there is a slide transition [14:06] <brontosaurusrex> stonie_, should be fine [14:33] <benbro> how can I extract all keyframes? [14:34] <benbro> I've tried the following but get a muxing overhead error [14:34] <benbro> ./ffmpeg -i test.mp4 -vf "select=eq(pict_type\,I)" -qscale:v 2 frame-%03d.png [14:55] <rcombs> https://trac.ffmpeg.org/ticket/1582 <-- so, what exactly is +full_chroma_int, and why isn't it on by default? [14:57] <rcombs> best explanation I've found is "full chroma interpolation", but that seems rather vague, and I can't find anything documented that says it severely reduces banding and fixes discoloration [15:13] <stonie_> brontosaurusrex, ok thanks .. the receiver cant import those files directly, the gotta define the field order by hand before ingesting [15:13] <stonie_> what command line would you use for mp4 full hd (1920x1080) in good quality? [15:15] <stonie_> right now i came up with "ffmpeg -i testmaterial.avi -y -pix_fmt yuv420p -acodec aac -b:a 192k -vprofile high -preset slower -ac 2 -strict experimental -threads 0 -vcodec libx264 -b:v 10000k -aspect 16:9 -r 25 -s 1920x1080 -wpredp 2 -top 1 -flags ildct+ilme -coder 1 -flags +loop -me_method umh -subq 8 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 2 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -bf 3 -refs 4 -trellis 1 -par [15:15] <stonie_> titions +parti8x8+parti4x4+partp8x8+partb8x8 outfile.mp4" [15:16] <JEEB> ugh [15:16] <JEEB> stop setting settings manually that can be handled with presets :| [15:17] <JEEB> many of those things are either current or previous defaults, and you shouldn't have to touch them at all [15:17] <stonie_> ok - how would u optimize that command? or, which are via presets [15:18] <JEEB> most [15:19] <stonie_> which preset would you use? [15:20] <JEEB> just use the slowest one that is fast enough for you, and limit the reference frames if some hardware needs that [15:20] <JEEB> (because setting the level only sets the flag, doesn't limit refs [unlike with x264cli]) [15:22] <stonie_> ok ty [15:22] <rcombs> stonie_: also, you probably want -crf <something> and -maxrate 10000k instead of setting a constant bitrate (which is wasteful) [15:22] <JEEB> it's not even constant :P [15:22] <JEEB> it's just one-pass ABR [15:22] <stonie_> ok ill try that tyvm [15:22] <rcombs> yeah [15:23] <rcombs> either way, -b:v is rarely what you're looking for with x264 [15:24] <JEEB> basically ffmpeg -i testmaterial.avi -y -c:a aac -ac 2 -b:a 192k -strict experimental -c:v libx264 -preset your_favourite_preset (your possible profile/level/ref LIMITATIONS here) (your rate control stuff here) (possible interlacing-related stuff here) out.mp4 [15:24] <JEEB> I separated the audio to the front because you had it all over the place in your example :P [15:25] <JEEB> also you don't need to SET high profile, it WILL get used IFF it is needed, you only set the profile when you want to LIMIT the encoder to a feature set [15:25] <DaFrameSkipper> what does "-skip_threshold" "-skip_factor" "-skip_exp" do? and how do use them [15:25] <grkblood13> I got that thing working rcombs [15:25] <JEEB> if your preset doesn't use the features, then it doesn't really help if you try to set an overly high profile flag [15:25] <rcombs> grkblood13: good! [15:25] <stonie_> JEEB, ok thanks.. ill try some more variations... [15:25] <stonie_> but, how do i set the interlaced stuff then? it needs to be tff [15:27] <DeadSix27> someone is really called brontosaurusrex on here? [15:28] <rcombs> DeadSix27: yup. There's also someone called DeadSix27. [15:28] <DeadSix27> :O [15:28] <DeadSix27> *shocked* [15:29] <DeadSix27> well need to go. [15:30] <DaFrameSkipper> anyone have any what "-skip_threshold" "-skip_factor" "-skip_exp" does and how do use them? [15:30] <JEEB> stonie_, that would go into the (possible interlacing-related stuff here) place :P You will have to excuse me for not knowing those by heart. Looking at http://ffmpeg.org/ffmpeg-all.html there are multiple "interlace" filters, there's plenty of "make this stuff interlaced" filters at least. Although if your input is already interlaced I wouldn't be surprised if it was already being encoded as such? [15:30] <rcombs> ack, interlacing [15:30] <rcombs> please, kill me now [15:31] Action: saste kills rcombs [15:32] <JEEB> also I recommend not taking mediainfo's information at too much face value, even libx264's terminal output when it starts encoding is much better than that [15:32] <stonie_> ill try some more.. thanks alot [15:32] <stonie_> ok ye.. thats what i found out too [15:33] <stonie_> mediainfo just gives the header info [15:33] <JEEB> not even that :P [15:34] <JEEB> also I'm going to take this moment of you using the word 'alot' and paste this for you http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-ev… [15:34] <rcombs> ^this [15:35] <stonie_> haha nice .. ty [15:35] <stonie_> ALOT [15:35] <JEEB> anyways, if libx264 is saying it's using interlaced encoding in its line that it blurfs out, then I'm just going to note that you're getting interlaced output just fine [15:35] <JEEB> and it's something else stumbling your beloved piece of crap in plastic :) [17:01] <stonie_> what would you use indead of mediainfo? [17:01] <stonie_> to get as detailed info as possible [17:03] <DaFrameSkipper> anyone have any what "-skip_threshold" "-skip_factor" "-skip_exp" does and how do use them? [17:04] <ubitux> stonie_: ffprobe [17:04] <JEEB> DaFrameSkipper, http://ffmpeg.org/ffmpeg-all.html at least has some info on them :P Seem to be libvpx-specific options [17:05] <JEEB> or not [17:05] <DaFrameSkipper> its really vague [17:05] <JEEB> there's two skip_thresholds on that page [17:05] <JEEB> well, unfortunately then you'll have to go and grep the source code :) [17:06] <JEEB> you are not going to get more info on how those can be used otherwise [17:07] <jeeger> Hello! I'm currently recoding old mst3k episodes from avi to x264. Does the preset actually matter? Is the quality difference from -preset slow to superfast noticeable? Any other recommendations? [17:08] <JEEB> How much difference the difference presets make depends on a lot of stuff, but generally such a large difference does affect the result quite a bit. My recommendation is the one I use generally: Use the slowest preset that is fast enough for you [17:10] <stonie_> ty [17:22] <jeeger> JEEB Thanks. [18:35] <viric> mm I fail to use "-ss" with the concat filter. [18:36] <viric> if I put it prev to -i, it is unprecise. [18:36] <viric> If after -i, it's applied to the output before encoding. [19:42] <Bombo> i got a stream "0:0 video 0:1 audio1 0:2 audio2 0:3 subs1 0:4 subs2" how do i select everything but subs2? i tried "-c:v libx264 ... -map 0:0 -c:a libmp3lame ... -map 0:1 -c:a libmp3lame ... -map 0:2 -c:s none -c:s copy -map 0:4" [19:42] <Bombo> tried -sn for 0:3 too [19:42] <Bombo> complains about missing parameters for 0:3 [19:44] <Bombo> it works when i just copy 0:3 too "-c:s copy -map 0:3" instead of "-c:s none", but it contains the subs2 then [19:54] <Bombo> ah nevermind. got it ;) [20:33] <DaFrameSkipper> is there a way to skip frames automatically in ffmpeg? [20:36] <DaFrameSkipper> for example when im livstreaming? [20:38] <svm_invictvs> Heya [20:39] <svm_invictvs> I'm looking for the source to a specific version of libavformat [21:02] <alesan> hi, how can I pass a specific option to libx264, for example the --keyint infinite [21:03] <JEEBsv> -g was the ffmpeg keyint-like setting [21:03] <JEEBsv> now find out which value ~= infinite [21:04] <alesan> hi JEEBsv :) [21:07] <DaFrameSkipper> JEEBsv, any ideas how to dynamically drop frames for livestreaming? [22:36] <svm_invictvs> So I'mg etting this in a stack trace. [22:36] <svm_invictvs> http://mysticpaste.com/view/NlgUIBKYSs?2 [22:37] <svm_invictvs> I've read some people reporting crash bugs for those fucntions. Is tehre a known workaround for this? [23:42] <slorbast> Hey alls, I was wondering if it's possible to take a video and display text on the side based on timestamp information from say an IRC log? [23:43] <slorbast> apo_, any luck with twitch streaming? [23:43] <sacarasc> I think it is, slorbast, but I don't know how. [23:44] <slorbast> sacarasc, thanks, I'm perusing the webs for info but hoped someone had experience in here while I looked :) [23:45] <apo_> slorbast: nope [23:46] <apo_> slorbast: I can easily upload over 100 KB/s to my own server, but twitch won't even do 66 KB/s. [23:46] <slorbast> apo_, and still having issues getting to AMS server? [23:48] <apo_> slorbast: not with ffmpeg 2 [23:48] <apo_> but it didn't really change anything [00:00] --- Sat Dec 14 2013

1 0

ffmpeg-devel.log.20131212
by burek 13 Dec '13

13 Dec '13

[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_decodi… [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.exte… [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-soun… [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

1 0

ffmpeg.log.20131212
by burek 13 Dec '13

13 Dec '13

[00:34] <SirCmpwn> thanks llogan [06:25] <apo> hi [06:27] <apo> I've been trying for hours to get ffmpeg to stream to twitch.tv, but I either get a terribly choppy stream or awful quality... with xsplit I can stream at perfectly acceptable quality at about 800kbit/s, but with ffmpeg I just can't get it to work [06:27] <apo> I suspect that I have to set it to actively select the Amsterdam server, but when I do that, it just tries to start and then stops after a few seconds (but my channel page shows 'Loading' for a short time) [06:28] <apo> my settings are -i file -c:v libx264 -b:v 75KB -minrate:v 75KB -maxrate:v 75KB -bufsize 2M -qscale:v 23 -s 1280x720 -c:a libmp3lame -b:a 5KB -ar 44100 -f flv <stream url> [06:29] <apo> Any idea why rtmp://live.twitch.tv works, but rtmp://live-ams.twitch.tv doesn't? [06:41] <relaxed> apo: -qscale does nothing there [06:41] <apo> relaxed: okay [06:42] <apo> relaxed: doesn't really matter at the moment, I'm rather sure that the problem is that I can't select the proper server... [06:42] <relaxed> -b:a 5KB ? [06:42] <apo> 40kbit/s audio? [06:44] <relaxed> right, I never see it donted in KB [06:58] <apo> I wonder what return 141 means... [07:00] <apo> You have my input, and http://p.0au.de/3c4f3895/ [07:02] <relaxed> add -preset veryfast and/or try a smaller bufsize [07:03] <apo> Those presets are not part of 1.2.3 [07:03] <apo> and I did try the smaller buffer size [07:03] <relaxed> Try a more up-to-date version [07:04] <apo> the only x264 presets are some ipod stuff [07:04] <relaxed> http://johnvansickle.com/ffmpeg/ [07:08] <apo> It's still choppy, but at least it streams to Amsterdam now... [07:09] <apo> (No presets on that either, btw) [07:09] <relaxed> add -preset veryfast [07:11] <apo> still choppy \o/ [07:11] <apo> http://www.twitch.tv/ludwigvanboltzmann btw [07:12] <relaxed> -tune fastdecode [07:12] <relaxed> or -tune zerolatency [07:13] <apo> hm [07:13] <apo> not quite [07:13] <apo> a bit better, I think [07:14] <apo> but it does look quite a bit worse than what I got with xsplit ~_~ [07:15] <apo> ... I've been working on this for too long, and it's late (or early) [07:15] <apo> Thanks for the help, but I need to sleep now [07:15] <apo> \o [08:33] <mijo> Is there a way to extract the timestamps from a H263 bit stream received from a peer so that I could build .3gp video file? [09:12] <diverdude> Hello, i am trying to use the matplotlib.animation.writers['ffmpeg'] to create a movie, however if i set fps below 5 it gives me an error saying it cannot write to file. Why can I only go to 5 fps? [09:14] <relaxed> some codecs have frame rate requirements [09:14] <relaxed> which one are you using? [09:14] <diverdude> relaxed: hmm good question. I am not really sure [09:17] <diverdude> relaxed: mpeg4 [09:17] <relaxed> show me the command it's running [09:18] <diverdude> relaxed: mmm its a python script. i am basically invoking it like this: FFMpegWriter(fps=1, metadata={'artist':'me'},bitrate=16384) [09:19] <diverdude> relaxed: im not sure how to see which ffmpeg command its running under the hood [09:20] <relaxed> do you have a link to the code? in question? [09:22] <diverdude> relaxed: its code like this: https://github.com/matplotlib/matplotlib/blob/master/examples/animation/mov… [09:27] <relaxed> ok, that's not very helpful. [09:30] <diverdude> relaxed: hmmm no...what else can i supply you? [09:30] <relaxed> http://matplotlib.org/users/customizing.html?highlight=ffmpeg [09:31] <relaxed> there must be some ffmpeg log [09:36] <diverdude> relaxed: i have made a series of pngs instead :) Do you know how i can create a movie from those with 1fps? [09:40] <relaxed> how are they named? [09:42] <relaxed> ffmpeg -f image2 -pattern_type glob -framerate 1 -i *.png -c:v libx264 -crf 14 -preset veryslow output.mkv [09:43] <zap0> relaxed, i've only ever done 1.png 2.png 3.png etc.. does -pattern_type glob just do it in natural glob ordering? [09:44] <zap0> does the mean you don't need perfectly consecutive numbering? [09:44] <relaxed> there's glob_sequence too [09:45] <relaxed> seems to work from my short test [09:45] <zap0> glob_sequence (deprecated, will be removed) <-- from http://ffmpeg.org/ffmpeg-formats.html [09:46] <zap0> reading about it now [09:46] <relaxed> I used glob [09:46] <relaxed> of course "deprecated" in ffmpeg means it will be around for a decade [09:47] <zap0> :) [09:48] <relaxed> diverdude: stick "-pix_fmt yuv420p" after the input unless you know you don't need it. [09:48] <zap0> `glob` This is only selectable if libavformat was compiled with globbing support. <-- i wonder if this is typically turned on. [09:48] <relaxed> it is [10:30] <torrent> hi, iam trying to build ffmpeg with static libs on a amd64 machine in a linux32 chroot. but ffmpeg fails: [10:30] <torrent> http://nopaste.info/857e5f82c8.html [10:30] <torrent> http://nopaste.info/4e8425866e.html [10:31] <torrent> first the output of config.log followed by the output of configure [10:31] <torrent> *make [10:32] <kuch3n> looked in the config.log, iam installing the missing passages.. [10:43] <diverdude> relaxed: when i run ffmpeg -f image2 -pattern_type glob -framerate 1 -i *.png -pix_fmt yuv420p -c:v libx264 -crf 14 -preset veryslow output.mkv i get Unrecognized option 'pattern_type' and Failed to set value 'glob' for option 'pattern_type' [11:12] <saste> probably you have an old version [11:19] <relaxed> diverdude: show me the filename of one of the images [11:35] <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:35] <BoR0> and also to be good in performance [12:22] <kuch3n> iam stuck here now: http://nopaste.info/e057b0db7c.html [12:22] <kuch3n> with this "solution": http://web.archiveorange.com/archive/v/DUtyPwfZ9clDk5ukDnvs [12:23] <kuch3n> but i cant get it to work [12:25] <kuch3n> fontconfig.pc looks like this: http://nopaste.info/560d7a7e49.html [12:52] <relaxed> kuch3n: are you using the latest version from git? i thought this was fixed. [12:53] <ubitux> it is [12:54] <ubitux> but looks like a different issue here [13:01] <kuch3n> relaxed: thanks for the hint, was using 2.1, now 2.1.1.. trying it right now [13:03] <ubitux> kuch3n: he was suggesting git master/HEAD [13:03] <ubitux> but the issue you have looks unrelated to the recent fix [13:05] <deviker> Hi, what do DC AC and MV mean? [13:05] <deviker> (in the context of ffmpeg) [13:07] <ubitux> A and C coefficients (DC is the first/biggest, AC are the others of the MB) [13:07] <ubitux> A and D* [13:08] <ubitux> MV motion vector [13:08] <deviker> thx ubitux [13:08] <ubitux> don't remember the meaning of the A and D though, but that's a common name [13:08] <ubitux> try looking up "ac dc jpeg" on your favorite web search engine [13:10] <deviker> ok thx again [13:10] <kuch3n> this is how i build ffmpeg: http://nopaste.info/40462f5431.html [13:10] <kuch3n> shall i paste the whole script? [13:14] <ubitux> you have multiple --extra-cflags [13:14] <ubitux> and you also use CFLAGS/LDFLAGS [13:14] <ubitux> don't do that [13:29] <kuch3n> ubitux: so i should put stuff from ldflags to --extra-ldflags? [13:30] <mijo> Hello ppl. Is there a way to extract the timestamps from a H263 bit stream received from a peer so that I could build .3gp video file? [13:30] <ubitux> kuch3n: one --extra-{c,ld}flags should be enough [13:33] <kuch3n> LEAR [13:38] <kuch3n> same problem: http://nopaste.info/290c206ce5.html http://nopaste.info/91de3beea1.html [13:58] <relaxed> kuch3n: why are you setting CFLAGS and --extra-cflags ? [13:59] <relaxed> you have --extra-cflags twice [14:25] <kuch3n> relaxed: have a look [14:25] <kuch3n> @ 12:38 changed it already but it didnt resolved the problem [15:23] <bencc> can I find the timestamps in a movie where a transition starts? [15:23] <bencc> I have a video of a slideshow [15:23] <bencc> and I want to know when there is a transition between slides or animation in a slide [16:02] <BoR0> how can I convert a video file to output wmv3 ? [16:04] <relaxed> BoR0: wmv2 is the highest supported [16:04] <BoR0> I noticed that [16:05] <kuch3n> BoR0 -vcodec [16:06] <relaxed> why do you want wmv3? [16:17] <BoR0> I am working on a set top box that uses Microsoft Multimedia software, so they have limited support of formats [16:17] <BoR0> does ffmpeg support vc1 at least? [16:18] <relaxed> recent Windows supports h264/aac [16:19] <BoR0> this set top box has windows ce on it [16:19] <BoR0> I tried with h264, no success [16:19] <BoR0> I get audio only with aac [16:20] <relaxed> ugh, try mpeg4/aac [16:20] <BoR0> I tried that as well [16:20] <BoR0> and mpeg2 [16:21] <BoR0> Note MPEG-2 video compression is not supported in the f-MP4 container format. [16:21] <BoR0> The following settings are supported for MPEG-2 encoders for the set-top box client. [16:21] <BoR0> Video: 2.0-3.1 Mbps cbreak X: 352, 480, 528, 544, 640, 720 [16:21] <BoR0> Y: 480, 576, 23.976, 24p, 25p, 25i, 29.97i, 29.97p [16:21] <iive> BoR0: VC1 is mostly supported. I'm not sure if interlace and advanced format is implemented. [16:21] <BoR0> maybe some of these params need to be specified additionally? [16:22] <cbreak-work> cbreak! [16:22] <BoR0> iive, but the question is how can I use ffmpeg to convert any format to vc1? [16:22] <Mavrik> BoR0, usually streaming to STBs is done with MPEG2-TS format, not MP4 [16:23] <BoR0> ./ffmpeg -i test_kb600.transcoded.wmv -strict experimental -vcodec mpeg2video test.wmv [16:23] <BoR0> is this the correct way to get a mpeg2 out of wmv? [16:23] <relaxed> -f mpegts output.ts [16:24] <BoR0> Stream #0.0[0x100]: Video: mpeg2video (Main), yuv420p, 400x300 [PAR 1:1 DAR 4:3], 104857 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc [16:24] <BoR0> Stream #0.1[0x101]: Audio: mp2, 44100 Hz, stereo, s16, 128 kb/s [16:24] <BoR0> no audio and no video on the STB [16:25] <iive> BoR0: you said STB, is it DVB compatible? [16:25] <Mavrik> BoR0, why are you packing MPEG2 video into wmv container? [16:26] <BoR0> I have no idea. all I want to do is convert wmv to mpeg so that my STB can play it [16:27] <relaxed> ffmpeg -i input -c:v mpeg2video -q:v 3 -c:a ac3 -b:a 192k -f vob output.mpg [16:28] <BoR0> still no audio/video on the STB [16:28] <relaxed> ffmpeg -i input -c:v wmv2 -q:v 3 -c:a wmav2 -b:a 192k -f asf output.wmv [16:29] <relaxed> if that doesn't work then just quit [16:30] <BoR0> only audio with that command [16:30] <relaxed> try wmv1 [16:30] <BoR0> with audio wmav2? [16:30] <relaxed> why not [16:31] <BoR0> same thing, no video [16:33] <relaxed> ffmpeg -i input -c:v mpeg4 -q:v 3 -vtag XVID -c:a libmp3lame -b:a 192k this_is_stupid.avi [16:34] <BoR0> no audio no video :( [16:34] <BoR0> how can this STB be so crappy [16:34] <BoR0> in the documentation it's stated that vc1, mpeg2 and h264 and wmv [16:34] <BoR0> are supported [16:37] <relaxed> ffmpeg -i input -c:v mpeg2video -q:v 3 -c:a mp2 -b:a 192k -f dvd output.mpg [16:38] <BoR0> no audio and no video [16:38] <BoR0> :) [16:38] <relaxed> smash it on the ground [16:38] <BoR0> is there some reverse engineered version of wmv3? [16:39] <BoR0> I downloaded a video off the internet with wmv3 and it played fine [16:40] <relaxed> is the sole purpose of this crappy machine to playback video? [16:40] <BoR0> yes [16:41] <relaxed> then install linux on it with vlc, mplayer, or mpv and make it useful [16:41] <bencc> I have a video with 5 static seconds, than a transition and another 5 static seconds [16:41] <bencc> can ffmpeg find the timestamp where the transition starts and ends? [16:41] <BoR0> thanks for the help man [16:42] <BoR0> I guess I'll have to go that way :) [16:43] <BoR0> if ffmpeg is able to decode wmv3, why would it not be able to encode? [16:44] <relaxed> just because you can read a book doesn't mean you can write one [16:44] <BoR0> is it so hard to encode wmv3? [16:51] <BoR0_> my connection dropped [17:02] <bencc> how can I use scene-detection? [17:02] <bencc> can't find docs [17:06] <ubitux> look at the select filter [17:10] <bencc> ubitux: thanks. looking [17:37] <bencc> ./ffmpeg -vf "-vf select='gt(scene\,0.9)'" -i test.mp4 -vsync 0 -f image2 /tmp/thumbnails-%02d.jpg [17:37] <bencc> Option vf (set video filters) cannot be applied to input file [17:37] <bencc> how can I get thumbnails? [17:38] <saste> bencc, wrong syntax [17:38] <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:38] <GstBlub> [rtsp @ 0x59400] UDP timeout, retrying with TCP [17:38] <GstBlub> [rtsp @ 0x59400] method SETUP failed: 454 Session Not Found [17:39] <saste> also you need to specify -vf after -i [17:39] <GstBlub> That URL works fine in windows media player and vlc [17:39] <GstBlub> what am I doing wrong? [17:41] <GstBlub> This is with ffmpeg 2.1 btw [17:48] <tolis> how i can remove a moving finger print from a realtime movie with which filter if it is possible? thanks in advance [17:50] <saste> tolis, you can use the removemovingfingerprint filter [17:51] <tolis> there is documentation about this to read it saste ? [17:51] <saste> tolis, it was a joke, there is no filter for such a very specific task [17:51] <tolis> :) [17:51] <tolis> so there is no solution :( [17:51] <bencc> what's the syntax error? [18:00] <Compn> GstBlub : to get rid of udp warning, use the tcp switch (i forgot its name now) should be in the manual [18:02] <GstBlub> Compn: rtsp_transport? [18:03] <Compn> possibly [18:03] <Compn> yes [18:03] <Compn> -rtsp_transport tcp [18:06] <GstBlub> Compn: that seems to work, but shouldn't it still work considering it's trying to fall back to tcp? [18:10] <Compn> yes [18:10] <Compn> one sec lemme test [18:11] <Compn> GstBlub : what ver ffmpeg you got ? [18:11] <GstBlub> 2.1 [18:15] <Compn> GstBlub : you can use vlc to record it [18:15] <GstBlub> yeah I know but I can't use vlc in my project, I'm just trying to figure out what I'm doing wrong in my project using ffmpeg [18:16] <GstBlub> or if it is a ffmpeg bug [18:16] <Compn> looks like a bug in ffmpeg yes [18:16] <Compn> mplayer ffmpeg://rtsp://strm01.novotempo.org.br/radionovotempo-vivo [18:16] <Compn> works like that haha [18:17] <Compn> but only playing 10 second audio then stopping [18:22] <GstBlub> yeah i think that's correct, it's not a live stream. vlc also stops playing after a while [18:22] <GstBlub> why would mplayer work though? unless it's using a different version of ffmpeg that doesn't have this bug? [18:27] <LucaS05> hi. Does the library has features like b-frames, lumi-masking or trellis quantization? [18:28] <zap0> what is trellis quantization [18:29] <towolf> hi. i have a question about the ts_from_file feature for jpg series here: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/144093.html [18:29] <towolf> i'm taking jpgs at about 1.24 seconds, very roughly 1 fps. [18:30] <towolf> now i want $SPEEDUP to be 60. so i get 24 minutes per day. the example convert to constant frame rate, but i want VFR in mp4 container. when I remove the fps=60 filter it starts dropping a lot of frames, why? [18:33] <towolf> do i have to set timebase or something? i thought, when i do "setpts="(PTS-STARTPTS)/60" it will change timestamps of 1.2, 2.4, 3.6 to 0.02, 0.04, 0.06 and those frames will play at this 50-60fps rates [18:33] <towolf> but it drops a lot of frames [18:35] <LucaS05> i want to simulate the xvid codec, and it uses features like those, so can i use them with ffmpeg? [18:44] <Compn> GstBlub : could be , im using an old mplayer [18:47] <GstBlub> Compn: I created a ticket for it: https://trac.ffmpeg.org/ticket/3222 [18:50] <Compn> GstBlub : btw whered you get the url from ? [18:50] <Compn> what website url [18:51] <Compn> put it in bug trac [18:53] <GstBlub> I don't know where i got it from (nor do I speak/understand that language). Yeah, I put it in the bug report as well [19:16] <LucaS05> nobody can help me? [19:24] <c_14> NEW KERNEL [19:24] <c_14> \o/ [19:25] <c_14> Also new firefox. [19:25] <c_14> Sadly Old Vehk. [19:25] <c_14> Sorry about that. [19:25] <c_14> Wrong chonnel. [20:13] <bencc> can a filter have a state? [20:13] <Compn> on/off ? [20:13] <bencc> I mean, react to a diff between two frames in the context of some state of the diff between previous frames [20:13] <Compn> if frame=interlaced ? [20:13] <bencc> I want to find timestamps of transitions between slides in a powerpoint video [20:14] <Compn> ah no clue [20:14] <bencc> so I have several frames without any change and than some frames of slide transition or animation [20:33] <bencc> anyone using this? https://github.com/stvs/ffmpeg-static [20:33] <bencc> I'm getting: ERROR: opus not found [20:54] <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 rtp dat [20:54] <jangle> not delivered. is there somthing I have to do special in order to setup the rtp side of the equation? [21:09] <Compn> jangle : might be easier to read openrtsp client part of live555 project [21:09] <Compn> read the source of openrtsp [21:09] <jangle> ok thanks [23:56] <SirCmpwn> hey there [23:56] <SirCmpwn> how can I ignore input streams that can't be passed along to the output? [23:56] <SirCmpwn> I'm trying to convert mkv to webm and it fails when there are ssa streams [23:57] <JEEB> use -map to map only those streams to output that can be used [23:57] <SirCmpwn> can this be done in an automated fashion? [23:57] <JEEB> -map 0:v -map 0:a maps the video and audio from the first (zeroth) input [23:57] <SirCmpwn> is there a way I can use -map without examining the streams first [23:57] <SirCmpwn> perfect, tahnks [23:57] <SirCmpwn> thanks* [23:57] <SirCmpwn> yep, works great, you're a lifesaver [23:59] <llogan> that will still map all video and audio streams present in the input, IIRC. maybe you want that. [23:59] <SirCmpwn> I could live with it, but I'd rather take the first one alone [23:59] <SirCmpwn> or the default one alone, perhaps [23:59] <llogan> 0:v:0 [00:00] --- Fri Dec 13 2013

1 0

ffmpeg-devel.log.20131211
by burek 12 Dec '13

12 Dec '13

[00:18] <wm4> michaelni: thanks [01:07] <clever> Daemon404: now its just being a pain, it crashes with 2 different errors [01:07] <clever> without gdb, it gives *** glibc detected *** ./ffplay_g: munmap_chunk(): invalid pointer: 0xafec2008 *** [01:07] <clever> but if i try to debug that, it gives Program received signal SIGSEGV, Segmentation fault. [01:07] <clever> and a corrupt stack [01:07] <clever> which ends in memcpy [01:08] <michaelni> sounds like a job for valgrind [01:08] <clever> michaelni: and valgrind gets upset over the omx interface, it doesnt understand the ioctl's [01:08] <clever> so it complains about all kinds of unset locations [01:10] <clever> michaelni: if i'm operating in YUV420 at 1920x1072 with a linesize of 1920, the 2nd plane should be 960 * 1072 bytes in size? [01:15] <michaelni> yuv420 is 2x2Y 1x1Cb 1x1Cr [01:15] <michaelni> for a 2x2 image [01:17] <clever> hmmm, the code should be the same as before but its now giving even less output [01:18] <Daemon404> clever, as michaelni said, it should be 960 x 536 for chroma planes [01:18] <clever> ah, my test tv sucks [01:18] <clever> ahh, halve the height too, forgot about that [01:18] <clever> explains the problems perfectly [01:19] <clever> got distracted by the simplicity of your bit shifting and inverting trick [01:19] <clever> forgot that height needs the same thing [01:20] <clever> and the pocket tv from 3 decades ago doesnt help, not much contrast when dealing with a Y only image [01:21] <clever> and ive double-checked, the linesize and stride match, so i can just memcpy the entire plane at once [01:21] <clever> i added a check to make it fail if it doesnt match in the future [01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:81ed7efbe24e: avcodec/indeo3: check the return code of ff_set_dimensions() [01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:11679e1b90f6: avcodec/pthread_frame: Fix memleak of AVCodecContext on error [01:22] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:42874666a6cb: avcodec/snowdec: check av_frame_ref() return value [01:23] <Daemon404> [00:21] < clever> and ive double-checked, the linesize and stride match, so i can just memcpy the entire plane at once <-- i told you you cannot [01:23] <Daemon404> avframe does not necesarily have width == stride [01:23] <Daemon404> it only does when teh width happens to also match the alignment on that particular platform [01:24] <clever> in this case, it does match, i will fix the code if i encounter another file which doesnt [01:24] <Daemon404> ... [01:24] <Daemon404> that is a retarded attitude. [01:24] <Daemon404> it's not soem rare occurrence, it's standard operating procedure [01:24] <clever> just trying to make it as simple as possible right now [01:25] <clever> ive been staring at no image at all for days, so justtrying to get something out of it [01:30] <clever> and i forgot to enable the v plane, oops [01:30] <Daemon404> :V [01:38] <cone-808> ffmpeg.git 03Reinhard Tartler 07master:2a0fb7286d67: alsdec: check block length [01:38] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:43f925536844: Merge remote-tracking branch 'qatar/master' [01:42] <clever> and now its drop everything time, the main server i admin was shut off for fail reasons [01:57] <clever> and i cant do a thing, support phone# isnt answering [02:23] <clever> Daemon404: and i have color! [02:23] <clever> not the right colors, but thats still a major leap in progress [02:28] <Daemon404> probably switch u and v [02:28] <clever> there was a few patched of the green it was giving before [02:29] <clever> fixing the memory leak now, then going to test it on the big tv to see whats wrong [02:29] <clever> the pocket tv is too crappy to clearly see the issue [02:32] <clever> Daemon404: looks like the colors arent aligned [02:33] <clever> one of those standard color bar frames may help [02:33] <Daemon404> smpte bars [02:35] <clever> found a decent mov with those, now to see how well my patch handles mov [02:35] <clever> i still dont have the extradata problem ironed out [02:35] <clever> so i'm having to manualy extract the annex b formated header and put that into a 2nd file [02:35] <clever> not sure how mov is going to complicate that [02:43] <clever> nope, no output at all on the mov file [04:45] <clever> Daemon404: still there? [04:47] <clever> http://gallery.earthtools.ca/index.py/paste/before.png [04:47] <clever> http://gallery.earthtools.ca/index.py/paste/color.png [04:48] <clever> its missing 2 whole bars, the alignment is off, and the top is heavily corrupt [04:49] <clever> and probly due to starting at the wrong offset, all the colors are wrong [05:08] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:39d11d599cd2: avformat/oggparseopus: factor opus_duration() out [05:08] <cone-808> ffmpeg.git 03Michael Niedermayer 07master:7f39352a1b66: avformat/oggparseopus: calculate pts/dts for initial packets after seeking [06:15] <clever> ok, half the corruption was just scaling not scaling it down [09:42] <ubitux> meh decoding example is leaking again? arh. [09:45] <ubitux> http://pastie.org/8544060 decoding example hacked for random fuzzing [09:46] <ubitux> *seek* fuzzing [09:46] <ubitux> (removing the 0 && [09:46] <ubitux> ) [09:48] <ubitux> http://pastie.org/8544067 http://pastie.org/pastes/8544068/text [09:49] <ubitux> could be adjusted to sometimes attempt outbound seek [10:47] <Mavrik> hmm, I'm trying to fix TTX remuxing... does anyone know of a good MPEG2-TS stream analyzer I could use to find out where things break? [11:00] <saste> ubitux, nice [11:26] <ubitux> wtf [11:26] <ubitux> wtf is going on in this thread o_o [11:32] <saste> we have a trac fight [11:51] <ubitux> this thread is awesome [11:51] <saste> the guy is mental [11:52] <saste> what about adding the tag "funny"? [11:53] <ubitux> saste :D [11:54] <ubitux> players #4 enter the game [11:54] <ubitux> -s [11:59] <ubitux> > You have no right to talk about professionalism when you have displayed such a poor attitude. You are deserving of any insults you have been given. [11:59] <ubitux> :D [12:23] <michaelni> ubitux, saste btw there are some coverity issues in the examples [12:23] <kierank> Mavrik: not for less than £10k [12:24] <Mavrik> yay. :) [12:24] <kierank> the answer is almost always fucked timestamps [12:25] <Mavrik> mhm, first issue were broken VBI/TTX data in PMT [12:25] <Mavrik> so now the next suspect are indeed timestamps [12:26] <Mavrik> or mpegtsen.c doing something funky with packets [12:27] <kierank> timestamps are optional in dvb-ttx [12:28] <kierank> because of a mistake in the original spec [12:30] <Mavrik> hmm, I see how this could mess everything up, I'll look into it. Thanks for advice :) [13:12] Action: Compn troooooolls [13:12] <Compn> bbl [14:12] <TimNich> michaelni: that mxf patch should be OK, I don't think we expected audio only originally. [14:16] <Compn> ubitux : i dont have pkg-config on mingw , rather i dont have it installed because its a giant pain in the butt [14:16] <Compn> maybe the newr mingw fixed all that [14:18] <ubitux> Compn: not relevant ;) [14:18] Action: Compn trolls hard [14:19] <ubitux> Compn: stop spouting non sense in that ticket :p [14:19] <Compn> bah [14:20] <JEEB> pkg-config seems to work just fine in general (as well as it does elsewhere), the only problem I've noticed is that certain configure scripts expect you to have CROSS-PREFIX-pkg-config, and don't fall back to normal pkg-config :< (although that's a thing everywhere, and can be worked around by creating shell scripts for those prefixed things) [14:21] <nevcairiel> pkg-config on windows is annoying [14:21] <nevcairiel> especially if you try to distribute pre-compiled libs and dont have the final path under your control [14:33] Action: Compn gets ready to troll the big one [14:33] <ubitux> Compn: maybe you can try to propose a solution or come up with a patch instead? ;) [14:34] <ubitux> oh come on Compn... [14:34] <ubitux> are you serious? [14:35] <cone-263> ffmpeg.git 03Carl Eugen Hoyos 07master:945a440d11ac: Force one stream for raw muxers. [14:36] <Compn> ubitux : yes, sending annoying users to libav is what i've been doing for a long time :) [14:36] <ubitux> that's stupid [14:36] <Compn> i do it in mplayer, i send those users to vlc :) [14:36] <Compn> in #videolan i send them to mplayer :) [14:37] <ubitux> you should stop that [14:37] <ubitux> the user actually raised an interesting problem [14:37] <ubitux> even though the form quite sucks [14:37] <Compn> he refuses to answer a single question [14:37] <Compn> theres not much i can help him with [14:38] <ubitux> it doesn't matter we figured out the problem [14:38] <Compn> yes the problem is pebcak [14:39] <Compn> but ok , time to stop trolling now [14:39] Action: Compn gives ubitux a hug [14:59] <michaelni> TimNich, the patch fixes the crash but i dont think it succeeds muxing the audio or our demuxer is buggy in demuxing it [15:00] <michaelni> at least in my test there was unexpectedly less audio coming out but then i didt investiagte why [15:04] <TimNich> I think the whole issue of audio only in mxf needs looking at because it wasn't an expected scenario. I need to try the demuxer with some audio only mxf muxed elsewhere, its just finding the time at the moment as I have two major projects on that are behind schedule. :( [15:27] <saste> Compn, you need to install pkg-config yourself with mingw [15:27] <saste> it is annoying but it is definitively possible [15:27] <saste> you just need to install gtk and stuff [15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:0f65503799c8: avcodec/bitstream: remove unused variable [15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:b6eee405ffd9: avcodec/utils: Print warning if avcodec_set_dimensions() failed [15:38] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:0fe6906d96cc: avfilter/aeval: Fix use of uninitialized variable [15:40] <michaelni> pkg-config needs gtk ?? [15:42] <ubitux> no, glib [15:54] <saste> https://trac.ffmpeg.org/wiki/MingwCompilationGuide => pkg-config [15:55] <ubitux> installing gtk is likely a simple way of getting glib :p [16:22] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:7441d1ec330d: avformat/aviobuf: fix null dereference in avio_close_dyn_buf() [16:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:95d2fc6a76f3: avformat/hdsenc: Check rename() return value [16:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:572965c9a6b8: avformat/hdsenc: fix unintentional integer overflow in hds_write_packet() [16:43] <ubitux> 37a749012aaacc801fe860428417a6d7b81c103f made the example leak with the old method [16:43] <ubitux> i'm not sure if this is actually fixing some code (so the example before my modification could have been working) [16:44] <ubitux> but we released with that (maybe broken) behaviour [16:45] <ubitux> fuck this shit [16:45] <ubitux> seriously :( [16:51] <michaelni> the non refcouted api should be only defined by avcodec from prior the whole refcounted code was added [16:54] <michaelni> that also implicates that when the examples worked with old avcodec without leaking then they have to work with current [16:55] <michaelni> old == prior to refounting [16:59] <ubitux> michaelni: see #3219 [17:00] <ubitux> anyway, any app relying on that logic without ref counting will be leaking hard [17:00] <ubitux> old usage and new usage with no ref counting is leaking [17:01] <ubitux> the api wasn't very clear anyway, so maybe the example was wrong in the first place [17:01] <ubitux> still& [17:15] <nevcairiel> the qp_table probably needs some handling as well, since its one of the things that leaks [17:16] <nevcairiel> i think there is an upcoming change on the libav ML that should fix the sidedata leak [17:18] <nevcairiel> the good news is that you can update the example to no longer use two different frame allocation functions [17:18] <nevcairiel> unless you want to keep it for documentaiton sake =p [17:19] <ubitux> that's of course for documentation sake [17:19] <ubitux> also, being able to test the 3 methods is quite useful& [17:20] <ubitux> those examples are actually pretty useful [17:20] <ubitux> maybe we'll finally realize how bad our api is ;) [17:39] <iive> ubitux: could you do a very quick explanation on how ref counting is used in avcodec. I assume that get_buffer increases it with one, and release_buffer decreases it. What else uses it? [17:40] <ubitux> i have absolutely no idea. [17:40] <ubitux> i "fixed" ref counting in the example merely by trial and error between memleak and invalid reads [17:41] <iive> one usage might be video_decode output pitcture, In that case the application might +1 when getting the image and -1 when image is no longer visible (e.g. when getting the next picture). [17:42] <iive> i mean, ref count have much more sense in filters. [17:50] <nevcairiel> for filters to be able to refcount, the decoder needs to start with that though [17:51] <nevcairiel> only if the decoder gives you a pitcture of which you control the lifetime, you can safely use it further [17:51] <nevcairiel> my main use-case is multi-threading, it made handing the frames to a processing thread so much easier, since i know and control how long the frame is valid [18:10] <wm4> ubitux: anton still has some patches in review, I think [18:10] <ubitux> ok [18:11] <wm4> the result should be that the old api just works [18:11] <wm4> and that there's no difference between avcodec_free_frame and av_frame_free [18:11] <wm4> (all of which should have done right when refcounting was introduced...) [18:29] <iive> nevcairiel: but this means that you must have a function that frees the picture after it is not needed. This breaking the old decoding API completely. [18:29] <nevcairiel> not if you turn off refcounting [18:29] <nevcairiel> thats why there is a switch [18:33] <wm4> iive: why? [18:34] <wm4> the old API requires either 1. that you free the frame (with avcodec_free_frame or the other one), or that you pass the frame to the decoder again [18:34] <wm4> both of these could unref the old frame [18:34] <iive> wm4, read the previous line I wrote. [18:35] <wm4> <iive> i mean, ref count have much more sense in filters. [18:35] <wm4> ? [18:35] <iive> well, not literally. above that. [19:48] <cone-263> ffmpeg.git 03Timothy Gu 07master:d6c5fd9f15c1: tools/: Add gen-rc tool for generating Windows resource files [20:39] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:6722e564a82b: avformat/hdsenc: fix off by 1 error in array size check [20:39] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:81c1197494f5: avformat/utils: Check avcodec_open2() return code in av_find_stream_info() [21:31] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:9ab5cf5417d7: avutil/avstring: fix () position [21:32] <ubitux> mmh there is no simd byte shift instruction? [21:33] <ubitux> (x86) [21:33] <michaelni> no unless it was recently added [21:33] <ubitux> meeh :( [21:34] <michaelni> annoyed the hell out of me when optimizing libpostproc [21:35] <ubitux> BBB: can i assume 0 d E d 127? [21:37] <ubitux> i need to do a: X*2+Y/2 <= E, with X and Y in [0;0xff], but since i can easily divide (mul is ok with a few add), i was considering doing a X*4+Y d E*2 [21:37] <ubitux> i *can't* easily divide [21:38] <michaelni> you can average with 0 to get a /2 [21:39] <ubitux> michaelni: oh, nice, thanks :) [21:40] <michaelni> beware of the rounding though [21:41] <ubitux> rounding with bytes? [21:41] <ubitux> is it relevant? [21:43] <michaelni> avg with 0 does a (a+1)>>1 [21:45] <ubitux> ah, i'll have to -1 then meh [21:46] <michaelni> if you average with 1 you get a (a+2)>>1, dunno if thats easir but if you can -1 the output for free somewhere [21:48] <ubitux> i don't think the avg with 1 will help [21:48] <ubitux> but maybe i'm missing something [21:56] <ubitux> anyway i can have the 1 in a reg for free [21:57] <ubitux> (i need it later for something else) [21:57] <ubitux> lucky \o/ [21:59] <clever> ok, i'm able to get yuv420 frames out of the omx api now, but something isnt right with how i'm handling them [21:59] <clever> http://gallery.earthtools.ca/index.py/paste/color.png clearly doing something wrong [21:59] <clever> it should look like http://gallery.earthtools.ca/index.py/paste/before.png [21:59] <ubitux> share the code [21:59] <clever> ubitux: http://pastebin.com/gHg6Cdfq [22:00] <llogan> clever: heh. nice commenting. [22:01] <clever> http://ext.earthtools.ca/download/rpi/frames/ and here is a dump of the first 7 frames [22:01] <clever> which oddly, differe in a few areas [22:02] <clever> the input mkv is also in that dir [22:03] <clever> if i cat the frames together and play them with mplayer frames.yuv -demuxer rawvideo -rawvideo w=960:h=540 then it doesnt decode right [22:03] <ubitux> memcpy(buf,src,stride * height); isn't this valid only for Y? [22:03] <clever> int stride = decoder->stride >> !!p; [22:03] <clever> if p is greater then 0, it will halve the stride [22:04] <ubitux> then isn't else if (p==2) src = decoder->outbuf->pBuffer + (stride*height) + ((stride/2)*(height/2)); wrong? [22:04] <clever> oh, yeah [22:04] <clever> let me change that [22:04] <ubitux> don't we have a pix fmt for that layout already btw? [22:05] <ubitux> well you can still copy for testing [22:05] <clever> somebody mentioned that a few times lastnight, but never said what the exact function was [22:05] <ubitux> but i'm pretty sure you could just set a 3 pointers :p [22:05] <clever> they also mentioned the case when the gpu stride doesnt match the ffmpeg linelength [22:05] <ubitux> function? you just make the decoder output the appropriate layout [22:05] <clever> this buffer is coming directly from the gpu [22:05] <ubitux> yeah but you could for the linesize, not sure how to do so [22:06] <ubitux> could *set* [22:06] <ubitux> anyway, better make it works first [22:06] <ubitux> you're almost done, right? [22:06] <clever> i ws told that the linesize field is read-only, but i could create the entire AVFrame from scratch [22:06] <ubitux> i guess it's time for me to buy a rpi [22:06] <clever> and point the custom AVFrame to my own buffers [22:07] <clever> the other problem i have, is the annex b format vs what ffmpeg gives me [22:07] <ubitux> you still haven't solve that?... [22:07] <clever> nope [22:08] <clever> and strangely, omxplayer is sending extradata bare, and works perfectly [22:08] <clever> ive tried mirroring what it does, and it doesnt work [22:09] <clever> so for any file i want to play, i have to manualy extract the video track, find the header size, copy it to a header file, then code it to read that file and prepend it [22:09] <Daemon404> [21:05] <@ubitux> but i'm pretty sure you could just set a 3 pointers :p <-- yeah but DR is a benefit [22:09] <Daemon404> imo [22:09] <Daemon404> as a downstream api user. [22:09] <clever> there is an api on the gpu to pipe the video data directly to the screen, without passing it thru the code at all [22:09] <clever> but the entire reason i'm doing this is to get video filters to work [22:10] <Daemon404> funnily enough [22:10] <Daemon404> i own about 6 arm boards [22:10] <Daemon404> but none are rpi [22:10] <Daemon404> :V [22:10] <Daemon404> so cant help debug [22:11] <clever> and the api here appears to be a semi-custom one, for just the rpi [22:11] <Daemon404> omx isnt exactly a well liked thing [22:11] <Daemon404> amongst devs [22:11] <clever> the firmware running on the gpu core does the actual parsing and decoding, using special instructions on the gpu core [22:11] <clever> and i have a feeling that some parts of that firmware differ from platform to platform, even with matching die's [22:12] <Daemon404> both the if p==1 and p==2 are wrong [22:12] <Daemon404> in your paste [22:12] <clever> i just edited those [22:13] <Daemon404> both? [22:13] <clever> yeah [22:13] <Daemon404> k [22:13] <clever> it also gave corruption if i just let it increment stride between all passes [22:14] <Daemon404> paste the new code then [22:14] <clever> http://pastebin.com/BeguDGj2 is currently compiling [22:14] <Daemon404> p==1 is still wrong [22:15] <Daemon404> youre only skipping half the luma buffer, [22:15] <Daemon404> er, 1/4 [22:15] <Daemon404> er ignore me. [22:15] <clever> it looks pretty decent now, 90% of it is perfect [22:15] <clever> let me screenshot [22:16] <Daemon404> also that src += at the end does nothing [22:16] <clever> oh, yeah, have to remove that now [22:17] <clever> http://gallery.earthtools.ca/index.py/paste/almost.png [22:17] <clever> except for the top and bottom, its perfect [22:17] <Daemon404> are you sure omx ends it raw [22:17] <Daemon404> without some header [22:17] <Daemon404> sends* [22:17] <clever> http://ext.earthtools.ca/download/rpi/frames/frame7.yuv [22:17] <clever> thats an exact copy of the buffer [22:18] <clever> 00000000 eb eb eb eb eb eb eb eb eb eb eb eb eb eb eb eb |................| [22:18] <clever> * [22:18] <clever> 00000070 eb eb eb eb eb eb eb eb a9 a9 a9 a9 a9 a9 a9 a9 |................| [22:18] <clever> looks like about 0x75 bytes/pixels worth of Y for the white bar, followed by the yellow bar [22:19] <clever> frame 1 is a bit more off [22:19] <clever> http://pastebin.com/RUjKEJfh frame 1 [22:19] <clever> the first 16 bytes dont match the rest [22:24] <clever> Daemon404: hmmm, can gimp show the y u and v components of a pixel? [22:25] <clever> thats interesting, there is a 2 pixel distortion at the boundry of each color, when running mplayer on a proper computer [22:25] <ubitux> do you know pgmyuv? @_@ [22:25] <Daemon404> clever, sounds liek alignment stuff [22:25] <clever> the 2 drasticaly different colors must have landed on the same 2x2 block [22:26] <Daemon404> omx might have N-bit slignment for panes [22:26] <Daemon404> in memory [22:26] <Daemon404> check its docks [22:26] <Daemon404> er docs [22:26] Action: Daemon404 stabs his hands [22:26] <clever> ubitux: i tried image magic to convert it, it also gives corruption [22:27] <clever> Daemon404: there are alignment requiremenets when i create the buffer itself [22:27] <clever> posix_memalign(&decoder->output_buffer, portdef.nBufferAlignment, portdef.nBufferSize); [22:27] <clever> this ensures that the buffer has the proper alignment when it gets allocated [22:28] <Daemon404> clever, planes may need to start on an aligned place [22:28] <Daemon404> hence the 2 byte padding [22:29] <clever> i dont think there is any padding at all [22:29] <clever> buffer size is 783360 [22:29] <Daemon404> so it can overread/write the previous buffer [22:29] <clever> Got new port settings width=960, height=540 [22:29] <clever> 518,400 pixels total [22:30] <Daemon404> *1.5 = 77760 [22:30] <Daemon404> *1.5 = 777600* [22:30] <Daemon404> 777600 != 783360 [22:30] <clever> yeah, thats not what the math gave last night [22:30] <clever> it was a perfect match when i was using the 1080 40mbps file [22:30] <Daemon404> ... [22:30] <clever> i didnt recheck the math on this 960x540 file [22:30] <Daemon404> because that clip happened to have a widt hand height that matched perfectly with teh alignment requirements [22:31] <clever> yeah [22:31] <Daemon404> this is why you reads docs an dont just do imperical tests [22:31] <Daemon404> er emprical [22:31] <Daemon404> fff typos. [22:37] <clever> Daemon404: the documents say that you must never put 2 planes in the same buffer payload [22:37] <clever> which is exactly what the gpu is doing to me! [22:38] <clever> they are breaking their own rules, or i am not reading them right [22:39] <Daemon404> YOU must not [22:39] <Daemon404> they can [22:39] <Daemon404> english! [22:40] <clever> lol [22:40] <clever> but it doesnt say you or they [22:41] <clever> 'when the uncompressed image data format is planar, data from 2 different planes cannot reside in the same buffer payload' [22:41] <ubitux> this is just the definition of planar [22:41] <Daemon404> it depend if theyre talking about input or output. [22:42] <Daemon404> ubitux, no it is not [22:42] <wm4> what is a "buffer payload"? some omx thing? [22:43] <clever> i believe it refers to the buffers used to pass data in and out of the gpu [22:43] <clever> and to pass data arround inside the gpu when 2 components are linked with a tunnel [22:44] <clever> aha, the slice height is 544, but the actual height is 540! [22:45] <nevcairiel> that happens [22:45] <clever> now to modify the math to include that... [22:45] <nevcairiel> needs to be mod16 or something like that [22:45] <Daemon404> like i said [22:46] <clever> yeah, thats why i was checking this field [22:46] <clever> the example code i was going on never touched it [22:46] <clever> but the example was also using OMX_COLOR_Format32bitABGR8888, which is much simpler [22:46] <clever> 4 bytes per pixel, done [22:50] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:f6173fed608b: postproc: fix null pointer dereference with invalid option strings [22:50] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:37437d97a8e6: tools/probetest: Check av_realloc() return code [22:54] <clever> Daemon404: yep, much much much better [22:54] <clever> the artifacts are now so small, its hard to tell if its the tv or decoding [22:55] <clever> need to screenshot and zoom in to compare things [22:58] <clever> only 2 rows of pixels are bad, at the very bottom [22:58] <clever> looks like i cut off the u and v for a single row [22:58] <cone-263> ffmpeg.git 03Diego Biurrun 07master:3bb91a1b5c4a: configure: Add -D__USE_MINGW_ANSI_STDIO=1 to CPPFLAGS on MinGW64 [22:58] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:95ad2483c33a: Merge commit '3bb91a1b5c4a0c5ec9c4d3b6649b23285c3d7f26' [23:00] <clever> hmmm, but this test pattern has no horizontal marks, so the entire image could be shifted up and i wouldnt know it [23:01] <clever> back to the 1080 image to see how well that one does [23:11] <clever> Daemon404: 1080 video looks great now [23:11] <clever> so that just leaves the extradata issue [23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:b769cf4b44c8: hevc: do not dereference pointer before NULL check in verify_md5() [23:14] <cone-263> ffmpeg.git 03Gildas Cocherel 07master:33452aede6ac: hevc: store the VPS list as an AVBufferRef, just like the others *PS [23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:1dbb3cfa17c1: Merge commit 'b769cf4b44c8112827c2fdfcab74bd95600fd6d3' [23:14] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:12a404244523: Merge commit '33452aede6acab78f726cd1924824585f00765cc' [23:20] <cone-263> ffmpeg.git 03Guillaume Martres 07master:17a10d51b835: hevc: set time_base when possible [23:20] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:dee6d5f51c72: Merge commit '17a10d51b8351ce9a57fcb6537b6a3c6ec8ba5e9' [23:24] <cone-263> ffmpeg.git 03Anton Khirnov 07master:eb891b3114f4: Replace all uses of avcodec_free_frame with av_frame_free(). [23:25] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:4cbf3eb9e6a8: Merge commit 'eb891b3114f499e96b9faddd0b0ae856345dfbd9' [23:36] <cone-263> ffmpeg.git 03Anton Khirnov 07master:943135621830: lavc: deprecate avcodec_free_frame() [23:36] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:409a143e4b49: Merge commit '943135621830ac3857d3cf766cfc280a95bb3c13' [23:41] <cone-263> ffmpeg.git 03Anton Khirnov 07master:674fa49110a6: avconv: do not call avcodec_get_frame_defaults() [23:41] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:e22e943ef90e: Merge commit '674fa49110a661694188a958be13d529b7c8c5dd' [23:47] <cone-263> ffmpeg.git 03Anton Khirnov 07master:95a8a5aca60c: lavc: call av_frame_unref() instead of avcodec_get_frame_defaults(). [23:47] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:27e79779821e: Merge commit '95a8a5aca60ce37d3abdf121a0285c2e317cf521' [23:56] <cone-263> ffmpeg.git 03Anton Khirnov 07master:84f131921ffb: avplay: do not call avcodec_get_frame_defaults(). [23:56] <cone-263> ffmpeg.git 03Michael Niedermayer 07master:5a15bd6f2f40: Merge commit '84f131921ffb43d8070d5680e91f6a24d66ccac4' [00:00] --- Thu Dec 12 2013

1 0

ffmpeg.log.20131211
by burek 12 Dec '13

12 Dec '13

[00:01] <saste> gazarsgo, crop and/or pad and/or scale [00:02] <gazarsgo> these filters are pretty powerful, thanks. sorry about the stream of consciousness [00:10] <lenswipe_dev> hey guys [00:11] <lenswipe_dev> anyone know if ffmpeg can play an m4a stream? [00:11] <sacarasc> ffplay probably can. [00:19] <llogan> lenswipe_dev: ffmpeg -i input.m4a -f alsa -ar 44100 hw:0 [00:19] <lenswipe_dev> llogan, It's actually via node.js but thanks [00:20] <lenswipe_dev> i wanted to know if ffmpeg had the capability to do it [00:20] <llogan> yes, ffmpeg can playback an audi ofile via alsa output device [00:20] <llogan> or oss or pulse [00:21] <llogan> ...and sndio [00:21] <llogan> but maybe you weren't asking about playback [00:33] <lenswipe_dev> llogan, well for one thing - i can absolutely garuntee it wont be via alsa :p [00:33] <lenswipe_dev> this is on a windows host :P [01:33] <jack_thompson> is there an simple/example player like ffplay that compiles only with the development files installed? [01:34] <jack_thompson> the included ffplay requires libavutil/colorspace.h which isn't part of the development files... [01:34] <jack_thompson> so to compile it i still need the complete source.. (in which it is included)... [01:35] <jack_thompson> but i'd like to have an example that decodes video/audio to sdl... [01:35] <jack_thompson> just like ffplay does... [01:35] <jack_thompson> but an example that compiles separately from the /entire/ codebase... like a project using libavcodec would do.. [01:36] <jack_thompson> is there a very very simple player like ffplay? [01:36] <jack_thompson> somewhere? [01:37] <jack_thompson> i dont have time to make ffplay compile with only the development files... [06:45] <aplund> is there any way to get seek and duration parameters to match the titles and chapters of a dvd (when using /dev/dvd as an input) ? [06:46] <aplund> as in, a way built into ffmpeg and not needing another utility [07:21] <aszlig> good morning [07:24] <aszlig> what's the easiest way to send async a/v to a remote stream using one audio stream and two video streams as input? [07:24] <aszlig> having a hard time to find any resources on the web, because most people would see async audio/video as a problem rather than the desired effect [07:31] <aszlig> https://redmoonstudios.org/~aszlig/fdbc/stream.sh <- this is how i'm using it right now [07:32] <aszlig> if i use it without the external tcp://-stream audio works fine, but with the tcp stream i get audio dropouts [07:34] <aszlig> so i'm just assuming this to be a sync issue, because video runs without frame drops but audio is stuttering [08:13] <aszlig> hm, never mind, this seemed to be an issue on the remote service [08:13] <aszlig> thanks anyway [09:33] <Schtern> how do I set bitrate in ffmpeg [09:33] <JEEB> for overall average bit rate, -b:v for video, -b:a for audio [09:34] <Schtern> I've used -bitrate flag before, however doesn't work [10:06] <stonie_> how may i force interlaced mpeg2? i try "-flags +ildct+ilme -top 1" - from the header its tff but in premiere it looks progressive? [10:16] <re-G> is there 'official' ultrafast preset any more? [10:18] <re-G> oh, it's internal. without preset file [10:21] <relaxed> re-G: `x264 --fullhelp` to see it [10:54] <stonie_> how do i interlace material? [10:55] <stonie_> into mpeg2 [13:17] <vivienschilis> hi guys [13:17] <vivienschilis> is it prossible to do ffprobe -show_frames [13:17] <vivienschilis> limitting the number of frames to inspect [13:25] <saste> vivienschilis, -read_intervals [13:36] <vivienschilis> saste: thanks [15:13] <grkblood13> does signed 16bit encoding use two's complement for negative numbers? [15:16] <zap0> 16bit encoding of what? [15:18] <grkblood13> pcm [15:18] <grkblood13> pcm_s16le [15:35] <JEEB> I would say it's a standard 16 bit signed value, little endian :P [15:41] <Mavrik> which means it does :) [17:00] <chele> Hello guys. Is there a way to extract the timestamps of a H263 video stream recieved from a peer terminal? [17:02] <Mavrik> chele, ffprobe -show_frames <your input> [17:03] <Mavrik> use -print_format parameter to make output something easily parsable for you :) [17:16] <chele> Mavrik: And could I build .3gp from that? The thing is I receive H263 bit stream from a peer and I need somehow to build .3gp. I receive also the audio bit stream but that one is fixed(AMR_NB). [17:17] <chele> I'm reading 3gp file format spec and without the timestamps I could not build .3gp and reproduce it at the peer side. Is there any way to get/guess/calculate this information? [18:02] <DeadSix27> anyone an idea why every frame is being dropped? (i used that command line before, and it worked fine then) [18:02] <DeadSix27> see: http://pastebin.com/4reBN9Jh [18:05] <DeadSix27> oh i forgot 1 parameter [18:06] <DeadSix27> well that disabled sound [19:06] <LucaS05> hi. i want to simulate the xvid codec. is it possible with ffmpeg? [19:09] <angell> Hello everyone, I'm writing a program to play video files (mainly wmv, mp4, avi and mpeg files). However, I'm looking for a way to play these files from memory, in other words, supplying the control a pointer to the memory block where the file is, instead of supplying it a file path. Any suggestions? [19:16] <llogan> LucaS05: yes. also ffmpeg can use the external encoder libxvid [19:17] <llogan> or using the native encoder: ffmpeg -i input -c:v mpeg4 -vtag XVID -q:v 4 output.avi [19:17] <llogan> ok!!! [19:38] <L3top> Hello. New to ffmpeg. Trying to reduce some file sizes to fit on dvds. I have ffmpeg -i final.mpg -ab 32k -r 29.97 -aq 1 -qscale 7.5 finalnew.mpg [19:38] <L3top> which I am pretty happy with... but the audio is out of sync by about half a second. Any clues on how I might correct this? [19:39] <llogan> ffmpeg has "-target ntsc-dvd" [19:40] <llogan> also -aq and -ab are mutually exclusive [19:40] <llogan> and -r 29.97 should be -r ntsc or -r 30000/1001 [19:43] <L3top> ty [19:43] <L3top> I see there is a map function and offset to handle my synch problem [19:44] <DeadSix27> is it normal that encoding in vp8 barerly uses my cpu? [19:44] <LucaS05> do you have some advices for developing a codec with ffmpeg? [19:44] <DeadSix27> i mean x264 uses pretty much my whole processing power [19:45] <DeadSix27> while on vp8 it doesnt even use 40% [19:45] <JEEB> libvpx is crappily optimized compared to libx264 [19:46] <JEEB> so if you want to encode VP8 or VP9 with it, enjoy [19:46] <DeadSix27> is there a better ? [19:46] <JEEB> for vp8 there for a moment was a project called xvp8, but that was a really fleeting thing, and died off rather quickly [19:46] <JEEB> because people just didn't care [19:47] <DeadSix27> well i do care! [19:47] <DeadSix27> guess that wasnt enough [19:47] <JEEB> VP8 was a worse format than >(constrained baseline) H.264, and x264 was already a highly optimized, oiled machine as an encoder. And thanks to adobe flash and even browser support, H.264 really wasn't a worse alternative. [19:47] <JEEB> soo... yeah [19:48] <DeadSix27> why "was" ß [19:48] <DeadSix27> ? [19:48] <DeadSix27> imo its still [19:48] <llogan> waß [19:48] <JEEB> because VP9 is already out and VP8 is even less useful etc. [19:48] <DeadSix27> does ffmpeg support vp9? [19:49] <DeadSix27> (encoding) [19:49] <JEEB> yes, via a new enough libvpx [19:49] <DeadSix27> ah libvpx-vp9 [19:49] <DeadSix27> uses even less cpu power [19:50] <JEEB> do note that while VP9 is kind of more useful, it's also very, very much more slower [19:50] <JEEB> yes [19:50] <JEEB> also VP9 lacks a specification, and Google doesn't seem to see this as a problem :P [19:50] <DeadSix27> does youtube use vp9? or vp8 still? [19:50] <DeadSix27> i assume vp9 [19:50] <llogan> L3top: generally you shouldn't experience a sync problem in the first place [19:51] <JEEB> it does use vp9 for some videos, generally vp8 if you want to note only the VPx formats [19:51] <JEEB> it does still use mostly H.264 [19:51] <DeadSix27> ye [19:51] <DeadSix27> i know [19:51] <JEEB> in one way or another [19:51] <DeadSix27> i just meant the vpx videos [19:51] <L3top> I think it was related to that mutually exclusive thing llogan. Once I eliminated and began tweaking it went away. [19:51] <L3top> thanks again [19:51] <DeadSix27> i dont have webm enabled on youtube though [19:52] <DeadSix27> h264 in flash runs smoother (atleast in their setup) [19:52] <JEEB> x265 is looking good performance-wise, but the developers have nothing to do with x264 :) [19:52] <DeadSix27> i noticed so [19:52] <DeadSix27> you think its going to be a good successor? [19:52] <JEEB> the format is good (HEVC/H.265) [19:52] <DeadSix27> yep h265 [19:52] <JEEB> it was known as HEVC before that :) [19:52] <DeadSix27> but i mean.. x264 was pretty revolutionary [19:52] <DeadSix27> look how often its used [19:53] <JEEB> x264 actually is a pretty goddamn good encoder :D [19:53] <DeadSix27> yep [19:53] <DeadSix27> and thats why i asked [19:53] <JEEB> anyways, x265 can already beat x264 in numbers, but the result is not as pretty [19:53] <DeadSix27> "you think its going to be a good successor?" [19:53] <DeadSix27> we'll see i guess [19:53] <JEEB> in numbers as in SSIM [19:53] <JEEB> yes, we'll see [19:53] <DeadSix27> as soon ffmpeg supports encoding of x265 ill try it out more widely [19:53] <JEEB> they've been ripping out things from x264 and sticking them into x265 [19:54] <JEEB> it has worked out relatively OK [19:54] <DeadSix27> I did download a x265 build but was to lazy to try it out further [19:54] <JEEB> http://fushizen.eu/u/jeeb/2013-12-03-x265_x264_test/hyouka_op/ [19:54] <JEEB> you can compare these [19:54] <DeadSix27> gotta love the hyouka op [19:54] <JEEB> the ssim directory contains the raw SSIM data [19:54] <JEEB> on the clips [19:55] <JEEB> Total: 13.501 (Y': 12.4967 Cb: 16.1191 Cr: 17.3511 ) , and x264 Total: 13.4168 (Y': 12.5562 Cb: 15.3001 Cr: 16.6475 ) [19:55] <DeadSix27> did you downscale the 1080p bd? [19:55] <JEEB> yes [19:56] <JEEB> to 720p [19:56] <DeadSix27> noticed [19:56] <DeadSix27> well picture-wise my bad eyes cant spot a diference [19:56] <DeadSix27> except in the numbers [19:56] <JEEB> x265 blurs a lot [19:57] <DeadSix27> also, as we talked.. vp9 was still encoding [19:57] <DeadSix27> (a 1:30m video) [19:57] <DeadSix27> and is still encoding* [19:57] <DeadSix27> terrible fps rate [19:57] <DeadSix27> of 1.1 [19:58] <JEEB> I think with this (--preset placebo for both, --tune ssim for x264 and --aq-mode 1 for x265) I had a 3.5fps with x264 and 0.7fps or so with x265? Don't remember exactly [19:59] <JEEB> multithreading-wise x265 looks pretty good at least [19:59] <DeadSix27> whats your hardware? [19:59] <JEEB> i5 3570K [19:59] <JEEB> standard clocks [19:59] <DeadSix27> idk much about intel [19:59] <DeadSix27> is that a quad ? [19:59] <JEEB> yes [19:59] <JEEB> ivy bridge [19:59] <DeadSix27> on my 6core amd i get usually 4-5fps on x264 [19:59] <DeadSix27> with similiar settings [20:00] <DeadSix27> didnt test x265 [20:00] <DeadSix27> but its OC'd [20:00] <DeadSix27> anywway [20:00] <DeadSix27> gotta drink a tee while vp9 is encoding [20:01] <DeadSix27> guess i have enough time [20:01] <JEEB> x265 was much less useful until someone from outside of the project came and posted a CRF patch that implanted the x264's CRF ABR into x265 [20:02] <JEEB> because 1pass ABR is... [20:02] <JEEB> uhh [20:02] <JEEB> it sucks [20:02] <DeadSix27> "outside thw project" [20:02] <DeadSix27> someone of x264 ? [20:03] <JEEB> nah [20:03] <JEEB> just some random chinese guy methinks [20:03] <JEEB> posted a patch on the mailing list [20:03] <DeadSix27> lol. [20:06] <llogan> was it "The Chinese Guy"? [20:20] <rager> hullo folks [20:21] <rager> I've gotten a bit further in my quest to make ffmpeg work nicely for me on android [20:21] <rager> JJMpeg lets me pretend that I'm using java libs instead of C ones - I figure I can actually write some JNI code after I understand the API's better [20:24] <rager> how would I go about extracting metadata from my video stream to determine orientation? [20:27] <JEEB> if it's in the container, you should be looking at how ffprobe/ffmpeg read it from libavformat's information [20:27] <JEEB> it should be available in a field in libavformat [20:28] <rager> it's a weird java wrapper that lets you write the glue code in java instead of C to interact with libav [20:28] <llogan> if it's metadata look for "rotate=90" or something like that [20:29] <rager> http://ffmpeg.org/pipermail/ffmpeg-devel/2011-March/109915.html < found this, at least [20:29] <llogan> the metadata my be specific to the stream and not global, but i don't really know [20:30] <DeadSix27> llogan: no it was the "random chinese guy" [20:30] <DeadSix27> not chinese guy in general. [20:32] <JEEB> if he meant the chinese guy who had a couple of commits in x264 from '04, it wasn't him. I think he's currently working on the x265 project paid by MCW, though. [20:32] <saste> rager, also: doc/examples/metadata.c [20:32] <rager> ah, thanks [20:33] <llogan> JEEB: yes, that's who i was referring to. [20:33] <saste> JEEB, you're in the field since a long time [20:34] <saste> if you remember people from the past 2004 (I can't even say what I was then ehehe) [20:34] <JEEB> I only remember that guy because he also was open sourcing his own "x265" and we noticed he actually had a couple of commits when we looked into it [20:34] <JEEB> *couple of commits in x264 [22:08] <SirCmpwn> I'm losing timing info between frames when using GIFs as input sources [22:09] <SirCmpwn> just ffmpeg -i foobar.gif ... [22:32] <zap0> 999% of GIFs are badly encided [22:33] <zap0> 99.9 encoded/ [22:34] <DeadSix27> 99.9 peroid? [23:38] <llogan> SirCmpwn: maybe you can use -default_delay if the delays are not variable... but i've never really messed with gifs [00:00] --- Thu Dec 12 2013

1 0