Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2013

1 participants
60 discussions

ffmpeg-devel.log.20131119
by burek 20 Nov '13

20 Nov '13

[00:35] <llogan> baptiste: greetings and salutations [04:02] <cone-903> ffmpeg.git 03Anton Khirnov 07master:a553c6a347d3: lavc: use buf[0] instead of data[0] in checks whether a frame is allocated [04:02] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:56e122787e73: Merge commit 'a553c6a347d3d28d7ee44c3df3d5c4ee780dba23' [04:10] <cone-903> ffmpeg.git 03Tim Walker 07master:37a3cac78c6b: dcadec: simplify an expression [04:10] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:8540368582fe: Merge commit '37a3cac78c6b13dc4e2c4f33ef53eed722d6f7b9' [04:15] <cone-903> ffmpeg.git 03Tim Walker 07master:69d4dbfd1faa: aac_ac3_parser: simplify an expression [04:15] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:32ab5b82f4b4: Merge commit '69d4dbfd1faa99563065329656bbe597d612ca03' [04:24] <cone-903> ffmpeg.git 03Kostya Shishkov 07master:16e7b189c548: mpegvideo: Fix swapping of UV planes for VCR2 [04:24] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:0dd8e96b32b2: Merge remote-tracking branch 'qatar/master' [06:02] <wm4> michaelni: why in the flying fuck is AVFMT_FLAG_KEEP_SIDE_DATA not the default? IMHO this is 1000% broken [07:51] <jedir0x> so how about that libavfilter sample :) [07:51] <jedir0x> is there any more documentation other than the doxygen stuff and the sample for implementing filters? [07:59] <wm4> jedir0x: ffmpeg.c and ffplay.c [07:59] <wm4> unfortunately [08:00] <ubitux> wm4: don't you have an example in mpv? [08:00] <ubitux> :-° [08:00] <wm4> ubitux: uh, not really, it's just a usage? [08:01] <wm4> and it does awkward stuff to connect two filter chains [08:01] <ubitux> to add to the confusion, the examples are still broken [08:01] <ubitux> :( [08:02] <wm4> is the example at least marked as broken? [08:10] <ubitux> yes, in the trac [08:11] <ubitux> :( [08:11] <ubitux> it seems nicolas & stefano are not motivated to fix it [08:12] <wm4> "in the trac" [08:12] <wm4> nobody looks there [08:12] <wm4> doesn't it cause you physical pain that users will just copy&paste the incorrect example into their code? [08:20] <ubitux> wm4: it does [08:20] <ubitux> definitely [08:22] <wm4> at least adding a big fat warning to the example itself would perhaps be helpful [08:23] <nevcairiel> what i cant help but wonder,where the examples ever correct and just aged over time and got outdated, or were they wrong from the start? :p [08:24] <wm4> in the lavfi case, I'd expect they were not converted correctly to the new API [09:48] <plepere> assembly question [09:49] <plepere> I have mx as a function argument. I whish to access ff_hevc_epel_filters[mx - 1]. ff_hevc_epel_filters is declared in hevcdsp.h [09:50] <plepere> how can I access the table in assembly ? [09:51] <nevcairiel> add "cextern ff_hevc_epel_filters" at the top of the file (in RODATA) [09:51] <plepere> I doubt that a simple movb r0,[ff_hevc_epel_filters+mx-1] works [09:51] <nevcairiel> once you have done that, it should work [09:51] <plepere> ok, and I must add the include hevcdsp.h too ? [09:52] <nevcairiel> no [09:52] <plepere> ok [09:52] <plepere> thank you [09:52] <nevcairiel> actually, don't include the ff_ [09:52] <nevcairiel> its added automatically again [09:52] <plepere> ok [09:52] <nevcairiel> example usage can be found in h263 loopfilter asm [09:53] <plepere> awesome, thanks [10:23] <ubitux> ok i fixed the example [10:23] <ubitux> but i cheated [10:29] <ubitux> this code should work, but it doesn't& [10:33] <cone-128> ffmpeg.git 03Clément BSsch 07master:1f7b7d544717: doc/examples: fix mem issues in filtering_video. [10:40] <durandal11707> saste: working on another filter? [10:41] <saste> durandal11707, not at the moment [10:41] <saste> i'll probably work on perlin and lua if time/motivation allow [10:42] <ubitux> hey saste, about the binding [10:42] <ubitux> what about just writing a simple high level api on top of a few libraries? [10:42] <ubitux> mkdir libsimpleffmpeg [10:43] <ubitux> we could discuss the features we need [10:43] <saste> ubitux, just ... simple ... [10:43] <saste> it's not really that [10:43] <ubitux> we don't need to provide much things at first [10:43] <saste> also i'm not really sure that will help [10:44] <ubitux> also, we could also just mkdir python, and write a C binding [10:44] <saste> the point is, if you have a binding, writing a high-level API (for your scripting language) is easier than writing it in C [10:44] <saste> there is already pyffmpeg [10:44] <ubitux> merge it \o/ [10:45] <wm4> merge ffms2 [10:45] <ubitux> saste: pyffmpeg is doing like everyone else [10:45] <ubitux> it's calling ffmpeg. [10:46] <ubitux> i was more into proposing a real binding, with language specific idioms [10:53] <durandal11707> oh dear, why it is so fucking complicated to call specific filter for specific frame? [10:53] <durandal11707> and, enable=expr is not solution [10:53] <ubitux> :) [10:54] <ubitux> because filters have context [10:54] <ubitux> and because they can keep or vomit N frames when you feed one [10:59] <durandal11707> yes, but i'm not talking about such filters.... [10:59] <ubitux> would you want a pure callback for filters doing a 1-to-1 filtering? [11:01] <durandal11707> imagine you want to do simple retarded slideshow transition with blend filter [11:08] <saste> https://github.com/Wessie/python-ffmpeg [11:08] <saste> there is also this one, but seems a bit like vapourware [11:09] <ubitux> "These bindings might never be finished!" [11:09] <ubitux> 10 mths ago [11:09] <ubitux> nice [11:15] <plepere> to set a register to a specific value, is it better to create a table elsewhere and move from memory or is there another way ? [11:15] <plepere> I want to set m1 to (6, 5, 4, 3, 5, 4, 3, 2, 4, 3, 2, 1, 3, 2, 1, 0) for instance [11:18] <plepere> should I simply define in RODATA like rnd_rv40_2d_tbl in h264_chromamc ? [11:19] <ubitux> probably yes [11:21] <plepere> ok thanks [11:47] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:607e5038a9a5: avcodec/pcm-dvd: fix 20bit 2 channels [11:47] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:87c416d93a09: avcodec/pcm-dvd: fix 20/24bit 1 channel [11:49] <cone-128> ffmpeg.git 03Martin Storsjö 07master:fa48be9b954a: configure: Don't use symlinks for creating the out of tree makefile [11:49] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:b31587af4b07: Merge remote-tracking branch 'qatar/master' [11:49] <durandal11707> michaelni: put that pcm-dvd into more coverage [12:26] <ubitux> michaelni: about the jacosub failure, how should i interpret it? [12:29] <michaelni> jacosub ? [12:30] <ubitux> yes the probing issue [12:30] <ubitux> you raised a while ago [12:30] <ubitux> with probetest, at size=16 [12:30] Action: michaelni runs memtest /dev/brain [12:30] <ubitux> 14:33:54 < michaelni> ubitux, probetest says: Failure of jacosub probing code with score=51 type=1 p=CAB size=16 [12:30] <ubitux> 14:34:12 < michaelni> thats tools/probetest 8192 500000 [12:31] <michaelni> yes [12:31] <ubitux> what does this output mean and what can i do to fix it? [12:32] <michaelni> the output means that for random input jacosub was detected with core of 51 [12:32] <michaelni> Score [12:32] <ubitux> mmh [12:38] <ubitux> michaelni: can i see what input is tested? [12:40] <michaelni> that should be easy to add to probetest [12:40] <wm4> michaelni: why is side data "merged" by default? [12:40] <michaelni> ubitux, and should be quite usefull feature [12:41] <wm4> (when demuxing) [12:42] <michaelni> if side data isnt merged then applications that arent AVPacket based would break. The merging sort of keeps the same ABI working [12:42] <wm4> what if an application uses libavformat but its own decoding? then lavf will corrupt the packats by adding side data [12:43] <wm4> also side data has been around for a very long time, before this merging was introduced [12:43] <wm4> libav just does fine with it [12:43] <wm4> and btw., this si an libav ABI incompatibility [12:43] <wm4> what if someone uses ffmpeg libavformat and libav libavcodec? [12:44] <wm4> also, if some raw data contains the merge marker at the end of the packet, random things happen [12:44] <wm4> I seem to be able to come up with 1000 reasons why this side data merging and splitting is an extremely bad idea [12:45] Action: ubitux is more worried about slowliness [12:45] <ubitux> hopefully we don't use them much [12:45] <michaelni> "what if an application uses libavformat but its own decoding?" if it doesnt support side data it likely wont work, as the data is likely there for a reason [12:46] <ubitux> Failure of jacosub probing code with score=51 type=1 p=CAB size=16 [12:46] <ubitux> 00000000 40 37 40 30 93 01 48 e0 09 96 10 90 78 0f 0c 10 @7@0..H.....x... [12:46] <ubitux> sounds like a legit file :)) [12:46] <ubitux> (@<frame> @<frame>) [12:46] <ubitux> maybe i could check for increment [12:47] <michaelni> "libav just does fine with it", maybe, maybe not, has someone done proper tests on that? [12:48] <michaelni> "and btw., this si an libav ABI incompatibility" and the other way around breaks ABI to previous ffmpeg & libav [12:49] <michaelni> "what if someone uses ffmpeg libavformat and libav libavcodec?", this wont work as libav libs are not drop in replacements for ffmpeg libs [12:49] <michaelni> "also, if some raw data contains the merge marker at the end of the packet, random things happen", elaborate please, what things? [12:49] <wm4> sorry but you're full of shit [12:49] <wm4> you keep adding ABI hacks so that ffmpeg is a drop-in replacement for libav [12:49] <michaelni> wm4 "I seem to be able to come up with 1000 reasons" <-- this is hit [12:49] <michaelni> Shit [12:50] <wm4> so if you have some data, e.g. from a raw demuxer, it could contain the merge marker at the end of the packet, and then libavcodec would try to interpret that as side data [12:51] <michaelni> if theres a problem we should fix it, and if the merging is a problem we should change it with the next ABI bump, that is if its better not to merge [12:51] <wm4> so you could probably construct a file that fails to play with ffmpeg, but works fine with libav [12:51] <wm4> what if users actually want to access the side data? [12:53] <michaelni> "so you could probably construct a file that fails to play with ffmpeg, but works fine with libav", yes you can construct that probably, and id guess you can do that probably for any 2 non trivial programs unrelated to multimedia too [12:54] <michaelni> if the user wants to access the side data, she can set the flag that disables merging or split it out, is this a problem for some use case ? [12:54] <wm4> it requires setting yet another mysterious flag - that is not needed on Libav, because Libav doesn't do this insane crap [12:55] <cone-128> ffmpeg.git 03Clément BSsch 07master:722fb81dc5c8: avformat/jacosubdec: make probing less tolerant. [12:55] <ubitux> michaelni: fixed [12:55] <michaelni> ubitux, thx [12:57] <michaelni> wm4, yes, there are applications for which the merged data is simpler to handle and some for which the split data is. The question is which way is overall more convenient and does overall cause fewer problems [12:58] <michaelni> are there any bug reports for either variant causing problems ? [13:04] <ubitux> about sws nv12 yuv420p: [13:04] <ubitux> 12:59:28 <+kierank> Because it always calls hscale [13:04] <ubitux> 12:59:28 <+kierank> Because its a piece of shit [13:04] <ubitux> 12:59:50 <+kierank> It does a "scale" with 2^n, 0,0,0 [13:04] <ubitux> 12:59:57 <+kierank> And the shifts down [13:04] <ubitux> 13:00:13 <@elenril> because it looked like a good idea at the time? [13:04] <ubitux> 13:00:28 <+kierank> Be damned if I know [13:04] <ubitux> might be relevant to discuss here as well ^ [13:05] <ubitux> (because i'm curious about that too) [13:10] <Compn> what do you want it to scale first ? [15:13] <ubitux> michaelni: careful when merging the recent cosmetics [15:13] <ubitux> they dropped some ( ) protecting around args in macros [15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:ef627bf9ecdd: swscale: add nv12/nv21->yuv420 converter [15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:94d7ca2b58af: swscale: fix used stride in planarToNv12Wrapper() [15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:4729b529e60f: swscale/x86/rgb2rgb: extend framework to also include AVX [15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:1de064e21e7f: swscale/x86/rgb2rgb: change cpu optim identifiers to lower case [15:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:3033cd755592: swscale/x86/rgb2rgb_template: add mmx/sse2/avx optimized deinterleaveBytes [15:21] <ubitux> oh wow [15:21] <ubitux> some michaelni speed awesomeness [15:22] <JEEB> nice [15:58] <ubitux> michaelni: and now you add http://git.videolan.org/?p=vlc.git;a=commitdiff;h=5d15f59a0e726adad5bc86b15… ? :) [16:00] <michaelni> yes that should be ported, yes [16:02] <michaelni> i might look into it but my todo list is long ... [16:02] <ubitux> michaelni: well, afaict from today your todo list is quite flexible :) [16:52] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:8769113accf1: mpeg4videoenc: K&R formatting cosmetics [16:52] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:18df75fa2fe2: Merge commit '8769113accf1f3b78634dec60b37f7354ed6d88d' [17:28] <Daemon404> looking at the icl failures... [17:28] <Daemon404> finally. [17:58] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:d234c7a07c13: mpeg4videodec: K&R formatting cosmetics [17:59] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:2c6e693c9754: Merge commit 'd234c7a07c1313fd215e8e242492bf71f5f3321e' [18:07] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:c673fc919c37: hevc_sei: drop unused parameter [18:07] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:8983dea426e3: Merge commit 'c673fc919c374c60b1e6d80d8822712eadf67f16' [18:19] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:3a16ec19d242: vf_interlace: check one av_frame_clone allocation [18:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:0a382aa99bd2: Merge commit '3a16ec19d2426457419cb8a7304f97982699efda' [18:19] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:6a71efff33e7: avfilter/vf_tinterlace: check clone return value [18:30] <cone-128> ffmpeg.git 03Vittorio Giovara 07master:6f1ec8edf241: avcodec.h: include version.h before using version macro [18:30] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:066dbfe1655b: Merge commit '6f1ec8edf2416441e2348f3a0915c9fee179d7da' [20:15] <cone-128> ffmpeg.git 03Compn 07master:ef7f7516426e: riff: add DYM4 mpeg4 fourcc [20:16] <Compn> chinese broadcasting industry fourcc :) [20:17] Action: Compn grumbles at the prospect of every single country having 3-4 different fourccs per each main codec (mpeg4, h264, mjpeg, etc) [20:18] <Compn> michaelni : how about unknown codec probing ? [20:18] <Compn> think codec probing could be done , similar to demuxer probing ? [20:20] <Compn> hey its llogan :) [20:21] <llogan> hey Compn [20:22] <Compn> i want to remove some excess verbiage from index page of ffmpeg :) [20:22] <llogan> which verbage? do you have a patch? [20:23] <Compn> sure [20:23] <Compn> http://e9b44f1821e394a0.paste.se/ [20:24] <Compn> a bunch of words that say 'click here' , which we already have links to [20:25] <Compn> probably the last sentence from the top paragraph too. [20:27] <llogan> i wonder if anyone astucally reads any of that [20:27] <llogan> *actually [20:30] <llogan> Compn: ok with me, but you should probably still post the patch on -devel [20:32] <Compn> nah [20:32] <Compn> too much to do :) [20:33] Action: Compn deletes it [20:34] <llogan> lazy! [20:35] <Compn> let it be written, let it be done [20:35] <Compn> (it is done) [20:35] <Compn> ahhhh much cleaner index page [20:35] Action: Compn wonders what other diego-talk he can delete from the pages [20:36] <llogan> It's called "DB formatting". [20:38] <Compn> want to put twitter or facebook or g+ on 'contact' page ? [20:38] <Compn> i guess we dont want to do support on those, so no :) [20:40] <llogan> you could make a "social" or "other" or whatever section [20:54] <Compn> llogan : did you see that deprecated bugreport is still going ? [20:55] <Compn> whats the status on that ? :) [20:55] <llogan> i don't know. i quit caring and can't give ass of rat about debian anymore [20:56] <llogan> also it gave me a good excuse to get of fof my ass and drop it as the distro for all of my work servers [20:57] <Compn> maybe i should run with it and initiate plan issue-trademark-cease-and-desist [20:58] <Compn> must contact fabrice for that [20:58] <llogan> maybe we can hire mru's lawyer [20:59] <llogan> (that was a joke) [21:00] <Compn> i was trying to think of funny reply, but brain is on break right nopw [21:01] <llogan> heh. latest name in the spam queue: Elfa Kabongo Omar-Bongo [21:01] <Compn> haha [21:01] <Compn> sounds kinda racist, but also funny [22:10] <cone-128> ffmpeg.git 03Diego Biurrun 07master:57f13fd7e993: dv_tablegen: Remove CONFIG_SMALL preprocessor check [22:10] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:d5d29ae3b037: Merge remote-tracking branch 'qatar/master' [22:32] <cone-128> ffmpeg.git 03Stephen Hutchinson 07master:69cf626f9c1b: cmdutils: Add -buildconf option. [22:39] <Zeranoe> I have been notified that there might be some regression with the H.264 decoder in the 2.1 release. I guess something to do with "AVC: nal size". Was there anything changed to the decoder that might cause that? [22:56] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:f836b0c581f7: swscale/x86: SIMD deinterleaveBytes() depends on YASM [23:10] <ubitux> michaelni: 69cf626f9c1b is quite a shitty commit [23:18] <michaelni> ubitux, elaborate please [23:18] <ubitux> michaelni: strtok/av_strtok, pkg-config hack, obvious non conforming coding style, ... [23:20] <michaelni> whats the problem with strtok ? [23:23] <michaelni> about pkg-config, what do you suggest ? [23:25] <ubitux> michaelni: we have a av_strtok() for that purpose [23:25] <ubitux> about pkg-config i don't know but that hack likely doesn't handle a lot of cases [23:26] <saste> strtok -> non portable (mingw or some windows thing) [23:27] <michaelni> saste, strtok or strtok_r ? [23:27] <cone-128> ffmpeg.git 03Stefano Sabatini 07master:80e5859d7a00: doc/muxers/segment: remove wrong default indication for segment_list_flags option [23:27] <saste> strtok [23:27] <saste> no i mean strtok_r [23:28] <saste> strtok is non-thread-safe, but probably is not important for ffmpeg [23:28] <ubitux> gtg, 'night [23:28] <saste> ubitux, good' [23:28] <michaelni> ubitux, night [23:29] <michaelni> anyway i can replace it by av_strtok if prefered? [23:30] <saste> and yes the commit is *extremely* hackish [23:31] <saste> also what's the point of the option? [23:31] <michaelni> i can also revert it if wanted [23:33] <michaelni> IIRC av_log() cannot handle lines longer than 1024 chars or so [23:34] <michaelni> also why did noone reply to the patch with these complaints, it was posted in august ... [23:37] <michaelni> just need to know if revert or "improve" is preferred for 69cf626f9c1b ? [23:40] <saste> michaelni, what's the point of the patch? [23:40] <saste> what's wrong with a plain configure line? [23:41] <michaelni> it can get truncated if its too long [23:42] <michaelni> also its not very readable [23:42] <saste> uhm yes [23:43] <saste> i stumbled against the av_log limitation [23:43] <saste> are you aware of any efficient way to deal with that? [23:43] <saste> at some point i was experimenting with printing a context option through AVBprint, but the resulting line was always truncated [23:49] <michaelni> one could do dynamic mem allocation in av_log() (which needs ENOMEM handling, and probably a mutex) [00:00] --- Wed Nov 20 2013

1 0

ffmpeg.log.20131119
by burek 20 Nov '13

20 Nov '13

[00:03] <ddsss> why am I getting this error: Incompatible sample format 'u8' for codec 'libmp3lame', auto-selecting format 's16' [00:03] <ddsss> [mp3 @ 0x23892e0] Unsupported sample rate. [00:04] <ddsss> Im not even converting to mp3: avconv -i test1.wav -ar 11025 -ac 1 -acodec pcm_u8 test2.wav [00:18] <brontosaurusrex> what would be a "tv to pc" scale filter? >> this will have to work: ffmpeg -report -i "$expanded" -pix_fmt yuv420p -vf hqdn3d,yadif=0:0,scale=768:576,crop=736:560:12:6,setdar='4:3' -map_channel 0.1.0 -map_channel 0.1.0 -c:a libfdk_aac -vbr 5 -c:v libx264 -preset fast -crf 21 -threads 1 -x264opts fullrange=on "$expanded.mp4" [00:18] <brontosaurusrex> since i have enough ;) [00:23] <llogan> ddsss: what's avconv? [00:24] <ddsss> llogan, yes [00:24] <llogan> ok!!! [00:24] <ddsss> llogan, selective dislexia [00:24] <ddsss> llogan, same as ffmpeg I thought? [00:25] <llogan> it's not from FFmpeg [00:25] <ddsss> llogan, hmm. k. [00:26] <llogan> use ffmpeg from FFmpeg if you want help here. getting a static build is easy [00:26] <llogan> wget http://ffmpeg.gusari.org/static/32bit/ffmpeg.static.32bit.$(date +"%F").tar.gz [00:26] <llogan> tar xzvf ffmpeg.static.32bit.$(date +"%F").tar.gz [03:10] <coolot> Good day to you all. got a question regarding installing FFMPEG. I am trying to follow the installation and compilation guide of it (https://ffmpeg.org/trac/ffmpeg/wiki/UbuntuCompilationGuide) however when compiling libvpx (VP8/VP9 video encoder and decoder) i bumped into an error which i have no idea. Thanks in advance for the help. [03:10] <coolot> coolot@Coolot:~/ffmpeg_sources/libvpx$ ./configure --prefix="$HOME/ffmpeg_build" --disable-examples [03:10] <coolot> Configuring selected codecs [03:10] <coolot> enabling vp8_encoder [03:10] <coolot> enabling vp8_decoder [03:10] <coolot> enabling vp9_encoder [03:10] <coolot> enabling vp9_decoder [03:11] <coolot> Configuring for target 'x86-linux-gcc' [03:11] <coolot> enabling x86 [03:11] <coolot> enabling runtime_cpu_detect [03:11] <coolot> enabling mmx [03:11] <coolot> enabling sse [03:11] <coolot> enabling sse2 [03:11] <coolot> enabling sse3 [03:11] <coolot> enabling ssse3 [03:11] <coolot> enabling sse4_1 [03:11] <coolot> enabling avx [03:11] <coolot> Neither yasm nor nasm have been found [03:11] <coolot> Configuration failed. This could reflect a misconfiguration of your [03:11] <coolot> toolchains, improper options selected, or another problem. If you [03:11] <coolot> don't see any useful error messages above, the next step is to look [03:11] <coolot> at the configure error log file (config.log) to determine what [03:11] <coolot> configure was trying to do when it died. [03:24] <buu> coolot: Have oyu worked out the part where it wants you to install yasm or nasm? [03:30] <Samus_Aran> I read that as "nsa" then "nasa", I think it's time I sleep. :) [03:31] <Samus_Aran> goodnasm. [03:37] <coolot> Buu : i think i am already done with it. i am just following th e guide [03:37] <coolot> Yasm [03:37] <coolot> Yasm is an assembler used by x264 and FFmpeg. [03:37] <coolot> Ubuntu 13.10, Ubuntu 13.04, and Mint 15 users can alternatively install the yasm package from the repository instead of compiling. [03:38] <coolot> cd ~/ffmpeg_sources [03:38] <coolot> wget http://www.tortall.net/projects/yasm/releases/yasm-1.2.0.tar.gz [03:38] <coolot> tar xzvf yasm-1.2.0.tar.gz [03:38] <coolot> cd yasm-1.2.0 [03:38] <coolot> ./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin" [03:38] <coolot> make [03:38] <coolot> make install [03:38] <coolot> make distclean [03:38] <coolot> . ~/.profile [03:38] <coolot> x264 [03:38] <coolot> H.264 video encoder. See the x264 Encoding Guide for more information and examples. [03:38] <coolot> cd ~/ffmpeg_sources [03:38] <coolot> git clone --depth 1 git://git.videolan.org/x264.git [03:38] <coolot> cd x264 [03:38] <coolot> ./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin" --enable-static [03:38] <coolot> make [03:38] <coolot> make install [03:38] <coolot> make distclean [03:38] <coolot> Buu : i already compiled and install it. [05:03] <I_pay_for_help> hi all i need your help and im ready to pay [05:03] <I_pay_for_help> hls + user agent+ cookie ==> rtmp [05:03] <I_pay_for_help> i have wireshark log to make it simple if you need it [05:05] <I_pay_for_help> ?? [05:09] <shevy> hmm guys... I am going to collect some random videos, in various formats, i.e. all about "funny animals" [05:10] <shevy> now I would like to ideally merge this all into one file, and when I find a new video, I would like to perform an "append" action onto what already exists [05:11] <shevy> my question is... what would be a good candidate to store things? Quality I dont mind really, filesize is also not a problem (though of course, smaller is better for archival purposes). Should I go with .mkv, .avi or .mp4, and what codecs should I use? [05:31] <I_pay_for_help> hi all i need your help and im ready to pay [05:31] <I_pay_for_help> hls + user agent+ cookie ==> rtmp [05:31] <I_pay_for_help> i have wireshark log to make it simple if you need it [07:20] <luoluoluo> Hi, when using ffmpeg in Android jni, I got app crashed. The backtrace showed something like "#00 pc 002c7f44 /xxx/xx/x/xx (ff_mjpeg_encode_picture_header+6692)" [07:21] <luoluoluo> I searched "ff_mjpeg_encode_picture_header" for a while, but cannot figure out what's the problem. [07:21] <luoluoluo> What could be wrong? Did you encounter this before? [07:28] <I_pay_for_help> hi all i need your help and im ready to pay [07:28] <I_pay_for_help> hls + user agent+ cookie ==> rtmp [07:29] <I_pay_for_help> i have wireshark log to make it simple if you need it [07:49] <I_pay_for_help> hi all i need your help and im ready to pay [01:28] <I_pay_for_help> hls + user agent+ cookie ==> rtmp [01:29] <I_pay_for_help> i have wireshark log to make it simple if you need it [10:25] <I_pay_for_help> hi all [10:26] <durandal11707> hi [10:28] <I_pay_for_help> im stuck with hls (nginx) protected [10:28] <I_pay_for_help> i need to restream it :( [10:28] <I_pay_for_help> i dont know how to parse user agent and other stuff [14:36] <ddsss> how do I add an artist tag to mp3? [14:38] <sacarasc> -metadata artist="I Like Cheese" or something. [14:38] <ubitux> what if you don't like cheese? [14:39] <sacarasc> Then why would you have that band's song? :O [14:40] <relaxed> everyone likes cheese [14:41] <sacarasc> My friend doesn't, except in burgers or on pizza. [14:42] <gix> any idea why transcoding an ac3 file to wav (ffmpeg -i in.ac3 out.wav) results in muffled/quiet audio in the wav file? [14:43] <hay> hi all.. I am having issues with adding a mp3 stream from a local station to my UScreenCapture video input... anyone did it already and got it working? [14:47] <hay> I am using the following command: http://pastebin.com/e8N9wPWB and it seems new streams for sound are being added constantly as I see in the VLC player... what am I doing wrong? thanks in advance :) [14:56] <ddsss> is it possible to tag wav files? [17:25] <ddsss> how to strip info chunks from .wav files? [18:37] <Wizord> hello, I have some mediafiles downloaded, each of theese files is part of stream. running `file <filename>` yields '<filename>: data', is there a way to figure out what these files are and parse/remux/convert them? [18:37] <Wizord> example file http://m1el.eu/hearing-dl/348_b74a63aadf3fc2f5-p_Seg1-Frag0001 (numbers from 1 to 2000) [18:37] <Wizord> hex dump of first few kilobytes: http://m1el.eu/hearing-dl/head.xxd.txt [19:08] <Wizord> ok, I'll ask the other way: is there a way to extract an h.264 stream if it's not encrypted in any way in this file? [19:08] <Wizord> does the h.264 stream itself has some markers/magic numbers? [19:09] <Mavrik> not really [19:09] <Mavrik> I mean... depends on how it's stored... NAL units do have markers [19:10] <Mavrik> now the questionable thing is if you have NAL units that are stored in header parts of a container [19:10] <Mavrik> hmm... it seems you have an mp4 file that. [19:11] <Wizord> but I cant read it with ffmpeg/mplayer/whatever [19:12] <Mavrik> Wizord, well your file starts with MDAT [19:12] <Mavrik> you need a MOOV atom to decode mp4 (or mov) format successfully [19:12] <Mavrik> without it the file is useless [19:12] <Wizord> hm [19:12] <Mavrik> if your file is chunked for streaming the MOOV is probably stored somewhere else [19:13] <Mavrik> or is even generated on the fly by the streaming servr [19:13] <bneff> I'm creating an mp4 from a ip camera stream. The mp4 plays fine, but when I scrub in quicktime I get severe artifacts. Any suggestions? [19:16] <Wizord> Mavrik: this file is given as is, I don't know what the server is, but I assume that it is some adobe product [19:17] <Wizord> and I've captured everything that was transported via network [19:17] <therube> Wizord: i believe you're correct on that, Adobe hds or something or the other. see if something here might help? http://forum.videohelp.com/threads/342430-F4F-capturing-converting [19:18] <Mavrik> Wizord, well check for MOOV atom [19:19] <Mavrik> Wizord, also your file seems to have a strange non-standard header [19:19] <Mavrik> it starts with duration info and some serverip duration [19:19] <Mavrik> and then continues with MDAT [19:19] <Wizord> Mavrik: is it "MOOV" as in ASCII string? [19:19] <Mavrik> yes, MOOV atom starts with MOOV string :) [19:19] <Mavrik> probably lowercase [19:21] <Wizord> nope, nothing [19:22] <Wizord> well, if it is an mp4 file, MAYBE it's possible to extract stream from it? [19:23] <Mavrik> without MOOV it's useless [19:23] <Mavrik> moov has file index which tells you what in that garbage is a stream [19:23] <Wizord> I see [19:23] <Mavrik> and parameters that tell decoders how to decode streams [19:24] <Mavrik> an mp4 file without moov is usually unrecoverable [19:24] <Wizord> > tell decoders how to decode streams <-- but most used streams (h.264/mp3/ogg/whatever) can be decoded alone, aren't they? [19:25] <Mavrik> H.264 only if it was encoded properly [19:25] <Mavrik> it can have PSS/SPS packets repeated within stream (for streaming mode) or written once in file header (for non-streaming) [19:25] <Mavrik> guess which mode has MP4 which is a format with a header. [19:25] <Mavrik> (yes that caused me alot of pain.) [19:29] <Wizord> I remember how I cut out ogg files from a game datafile using only magic numbers. I guess it's harder with media formats produced deliberately to mess up with people who want to dump streams. [19:31] <Mavrik> if you say so. [19:32] <bneff> hmm if I "transcode" the clip using ffmpeg, the scrubbing works great. [19:32] <Mavrik> bneff, probably camera uses a huge GOP size [19:33] <Mavrik> or breaks stream in several other hideous ways :) [19:33] <bneff> Mavrik: gop is 15 [19:33] <bneff> Mavrik: could it be related to IDR vs I-Frame or something like that? [19:36] <bneff> Mavrik: only other thing I can think of is quicktime can't tell which is an I-frame..maybe some missing header in h.264 or mp4? [19:42] <Mavrik> bneff, IDR frames are I-frames :) [19:42] <Mavrik> maybe it uses intra-encoding [19:43] <Mavrik> can't really tell from such description :/ [19:47] <Wizord> WTF. mp4 includes chunk length (4 bytes) and chunk name (+4 bytes) in chunk length itself? [19:47] <Wizord> which means it's possible to create INCORRECT chunk? [19:57] <bneff> Mavrik: Sorry, I've been googling everyone so different links have me confused. Do you have any recommendations on how I could look at the working mp4 and compare it to the non-working mp4? [20:04] <bneff> Mavrik: ooh just found ffprobe -show_frames...this might be enough. Thank you [20:05] <Mavrik> bneff, also full ffmpeg output could help [20:05] <Mavrik> debug 99 and verbose or whatsit [20:09] <bneff> Mavrik: will look at that too. I noticed the pkt_duration is wrong in the broken clip, as well as the pkt_dts. I'll see if I can fix those and test again [00:00] --- Wed Nov 20 2013

1 0

ffmpeg-devel.log.20131118
by burek 19 Nov '13

19 Nov '13

[01:32] <cone-904> ffmpeg.git 03Vallimar 07master:6f8a27dd3ba3: avcodec/old_codec_ids: fix missing FF_API_XVMC check [01:32] <cone-904> ffmpeg.git 03Vallimar 07master:6f5c36832dfc: avfilter/vf_mp: fix missing FF_API_XVMC check [02:43] <BBB> STRIP libavfilter/x86/vf_gradfun.o [02:43] <BBB> strip: unrecognized option: -wN [02:43] <BBB> Usage: strip [-AnuSXx] [-] [-d filename] [-s filename] [-R filename] [-o output] file [...] [02:43] <BBB> make: [libavfilter/x86/vf_gradfun.o] Error 1 (ignored) [02:43] <BBB> ? [02:43] <BBB> what is that? [02:43] <BBB> I see that a lot [02:49] <{V}> BBB, http://linux.die.net/man/1/strip wildcard and stripping a specific symbolname apparently [02:50] <{V}> https://trac.ffmpeg.org/ticket/3037 [02:52] <BBB> I don't have a trac account, but if it hits a developer, I'd say it's major? [02:57] <iive> what distro are you running? Debian? [03:13] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:a8dec360c5db: avformat/utils: dont count attached pics toward the probesize [05:35] <Zeranoe> I believe this commit: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b18c7c8d3ddfbf171fe0ab… introduced "libxavs.c:161:5: error: 'avctx' undeclared (first use in this function)". I will submit a bug report tonight if this doesn't get a quick fix on here. [07:46] Last message repeated 1 time(s). [07:46] <ubitux> Zeranoe: http://pastie.org/8488946 [07:47] <ubitux> can you try this? [07:53] <cone-27> ffmpeg.git 03Clément BSsch 07master:71cd83e34cf7: avcodec/libxavs: attempt to fix compilation after b18c7c8d. [07:53] <ubitux> Zeranoe: well, just pushed, tell me if that fixes it for you [07:54] <Zeranoe> ubitux: Oh, alright, was working on testing locally. I'll just pull then [08:04] <Zeranoe> ubitux: I appreciate the quick support. The error is now: libxavs.c:116:23: error: 'ctx' undeclared (first use in this function) [08:07] <ubitux> ah& ofc... [08:09] <cone-27> ffmpeg.git 03Clément BSsch 07master:260fc0d95b02: avcodec/libxavs: 2nd attempt to fix compilation after b18c7c8d. [08:09] <ubitux> Zeranoe: ^ [08:16] <Zeranoe> ubitux: Fixed, thanks again [09:32] <ubitux> thx BBB for the patch [09:32] <ubitux> will review today [10:12] <plepere> f..... [10:13] <plepere> I got my assembly working correctly ! [10:13] <ubitux> :) [10:13] <plepere> it was because dststride didn't account the fact that dst was 16bit [10:13] <plepere> so I had to do 2 times the increment [10:14] <cone-27> ffmpeg.git 03Michael Niedermayer 07master:cda3c0047554: avcodec/h261enc: remove unused variables [10:22] <plepere> I have a question : [10:22] <plepere> currently, I work with functions with blocks with a width ranging from 2 to 32. [10:24] <plepere> In my intrinsics optimized functions, I do some tests to check what level of optimization I must do. 16 by 16, 8 by 8, 4 by 4, or 2 by 2 [10:24] <plepere> should I do the same in assembly ? [10:26] <kierank> you can write macros to do that [10:27] <plepere> well I think I'll do the tests to point to the right macro depending on the parallelism level I can do. [10:28] <ubitux> plepere: you're supposed to have one function for each level [10:28] <ubitux> which you generate with macro if you can [10:29] <plepere> so I need to do the test before calling the function ? [10:29] <ubitux> aren't you supposed to have a callback for each size? [10:30] <plepere> I have the width size as function parameter [10:30] <ubitux> what function is that? [10:30] <plepere> all of the qpel for instance [10:31] <ubitux> ah, the depth thing [10:31] <plepere> no [10:31] <plepere> wait, I'll do a pastebin showing what I mean [10:32] <plepere> http://pastebin.com/hrsiqV96 [10:33] <plepere> there's a lot of code, but the thing I'm asking about is : I'm doin if(!(width&15)) do 16 times parallelism. if 8, do 8 times parallelism [10:33] <ubitux> the alignements check? [10:34] <ubitux> ok [10:34] <plepere> not always [10:34] <plepere> and when using CAL, it never is aligned [10:34] <ubitux> why not always 16, and do a slow path for the padding? [10:35] <plepere> ubitux : so you're proposing 16 * 16 till we reach width - 15, and then do 2 by 2 ? [10:36] <ubitux> if (width & 15), you make a slow path (which could be a resegmentation with width & 7, width & 3, ...) of size width & ~15 [10:37] <ubitux> and you do all the rest on 16 [10:37] <ubitux> not sure i'm clear enough [10:38] <plepere> hmm. So I keep the test in the function, but I do a fast 16 times parallelism, and the rest is 8 times parallelism that finishes 2 by 2 if necessary [10:40] <ubitux> plepere: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/x86/vf_gradfun_i… [10:40] <ubitux> see this [10:41] <ubitux> the function filters the line in a "slow mode" (c function) for the padding, and use a fast code for the remaining pel [10:41] <ubitux> you would do the same, except that you would have nested small sub-slow mode if necessary [10:42] <ubitux> (if you really want to be fast for the little padding area) [10:42] <nevcairiel> which width values can really occur? if its really only a slow number of values, one function per value might be better [10:43] <plepere> ubitux, I'll loo at the code [10:43] <plepere> nevcairiel, it can be 2, 4, 8, 12, 16, 24, 32 [10:43] <plepere> but I'll have to test again if you want to be sure [10:43] <ubitux> width can't be odd but can go down to mod 2, like h264> [10:43] <ubitux> ? [10:44] <plepere> I think so [10:44] <ubitux> ok [10:45] <ubitux> anyway the slow path will be for at most 15 px per line [10:45] <ubitux> so you can hardcode in a few instructions those [10:46] <nevcairiel> if the width is always only between 2 and 32, doing slow mode for at least 15 of those seems inefficient [10:46] <ubitux> at least? [10:46] <ubitux> at most you mean [10:46] <plepere> ok, I printed the width on a short video, and the width can take 4, 8, 12, 16, 32 and 64. [10:46] <plepere> but a majority is 8 [10:46] <ubitux> [16][16][16][...][16][<16 slow path] [10:47] <ubitux> always this ^ [10:47] <ubitux> and you can specialize the < 16 part [10:47] <nevcairiel> but if the maximum size is 64 [10:47] <nevcairiel> and 8 is rather common [10:47] <nevcairiel> an optimized 8 might be good [10:47] <ubitux> oh wait sorry it's not the full size of the video [10:48] <nevcairiel> its block size, isnt it [10:48] <ubitux> ah in that case& [10:48] <nevcairiel> up to 64 [10:48] <nevcairiel> personally i might even go with optimized functions for each block size [10:48] <nevcairiel> not sure if worth it though [10:48] <ubitux> indeed [10:48] <ubitux> you make a 16-bit macro to reuse with 16, 32 and 64 [10:49] <ubitux> and you make special functions for 4, 8 and 12 [10:49] <nevcairiel> and 24 [10:49] <ubitux> i didn't see it in the list :) [10:49] <plepere> the width really varies with the video. tried on HD, and the 32 and 16 are much more present. and 24 seems to be a valid width size [10:49] <nevcairiel> it was in the earlier list, no idea :) [10:50] <ubitux> plepere: well, you can start by making if just like your intrinsics, but you should have a callback per size IMO [10:50] <ubitux> plepere: i had a full video width in mind at first, so forget what i said :) [10:51] <plepere> I might as well change things now, and do the testing before calling the function and have different functions through macros [10:52] <nevcairiel> first step would be finding out which sizes can really occur, probably need to consult the calling code or the spec, then restructer the dsp function pointers to store them per-width [10:52] <nevcairiel> restructure* [10:52] <nevcairiel> but this indeed sounds more efficient in the long run [10:54] <plepere> however, the width testing should be done before calling the functions. [10:54] <ubitux> you wouldn't "test" [10:54] <nevcairiel> just use the width as an index into the table, i guess [10:54] <ubitux> you would use a width id as a cb index [10:55] <plepere> ok [10:55] <ubitux> meh [10:55] <plepere> so c->put_hevc_epel[0][1] = ff_hevc_put_hevc_epel_h_8_sse; [10:55] <plepere> becomes c->put_hevc_epel[0][1][8] = ff_hevc_put_hevc_epel_h_8_8_sse; [10:56] <plepere> for a 8 by 8 function [10:56] <nevcairiel> wonder how other things do it, if its more efficient to store it not by the width itself but some number derived from the width (so the array isn't as big) [10:57] <ubitux> you probably have a 0 N values to identify each width [10:57] <ubitux> i doubt the codec has "64" stored as such [10:57] <nevcairiel> comes back to checking the calling code :) [10:57] <tachyean> i'm trying to capture jpeg images from an rtmp stream and save them to disk, i've managed to do it but when i run the ffmpeg command i must wait between 1 and 2 minutes for the capture to start, there is any way i can make it start sooner than 1 minute? [10:58] <tachyean> this is the command i'm running: http://pastebin.com/wKBwTPB6 [10:58] <ubitux> tachyean: ask #ffmpeg [10:58] <tachyean> i've asked [10:58] <ubitux> you won't have more help here, this is for development on ffmpeg [10:58] <tachyean> ok [10:58] <plepere> good luck, though [10:58] <tachyean> i'm sorry for bothering ^^! [10:59] <tachyean> thank you! [10:59] <plepere> I'll ask around how the width is handled in the codec [11:01] <ubitux> based on log2_cb_size i'd say [11:01] <ubitux> which is strange if you said 12 and 24 as width [11:02] <ubitux> probably the 3/4 partition then [11:03] <ubitux> you might have to either generate a block width id, or use log2_cb_size and the partition mode [11:07] <ubitux> BBB: oh wait, SWAP can take N arguments? :o [11:07] <plepere> yes, I'll check that [11:08] <plepere> thanks a bunch. [11:15] <plepere> the dsp function pointing file will be completely unreadable ! I'll have almost 100 functions ! [11:15] <nevcairiel> thats usually where macros come in [11:15] <plepere> yeh [11:15] <plepere> I'll see as I advance [11:17] <plepere> mraulet also told me that it would be interesting to fuse the (un)weighted prediction functions with the qpel ones. [11:18] <plepere> since they are used together on the same blocks [11:20] <wm4> j-b: what security bugs does mpv have? [11:20] <j-b> the same as libav/ffmpeg [11:21] <nevcairiel> the same as vlc then? :D [11:22] <j-b> yep [11:22] <j-b> but we don't advise users to build libav/ffmpeg statically like JEEB does. [11:22] <j-b> or whatever mpv-builds does [11:22] <wm4> oh so it's about static linking [11:22] <plepere> http://pastebin.com/iz9XvgYV <-- is there another way of doing this ? it seems awfully repetitive. [11:22] <JEEB> I don't recommend that either unless the user seems to need a newer libav* [11:23] <JEEB> <JEEB> if a user needs a newer libav* on *nix and your distro does not provide, i don't see a real alternative to using contrib-like solutions [11:23] <JEEB> <JEEB> I really hope I am not correct about this, but to be frank I just don't see it [11:23] <wm4> anyway, mpv-build is not _required_ [11:23] <JEEB> yes, definitely not required [11:23] <JEEB> it's just the simpler way to get a solution to the problem I noted [11:23] <wm4> it's merely a way to build mpv with a local copy of ffmpeg (easier due to distro madness etc.), so static linking is kind of required here [11:24] <ubitux> building mpv with ffmpeg is easier than building vlc with ffmpeg at least [11:24] <ubitux> :) [11:24] <j-b> ubitux: right. [11:24] <ubitux> even without static [11:24] <j-b> ubitux: I really should take sides then, I guess [11:25] <j-b> ubitux: please go fuck yourself [11:25] <ubitux> hahaha [11:25] <ubitux> wtf :') [11:25] <wm4> wat [11:25] <JEEB> ^^; [11:25] <wm4> why is he so angry [11:25] <ubitux> :D [11:25] <ubitux> dunno [11:27] <wm4> vlc is a nice project, but due to its size it's rather obvious that building it will be harder [11:28] <plepere> is there a way to simplify function pointers ? such as hevcdsp->put_hevc_qpel[0][0][*] = FUNC(put_hevc_qpel_pixels, depth); if all values point to the same C function ? [11:29] <nevcairiel> could always loop [11:29] <plepere> ok [11:30] <nevcairiel> not sure if thats something usually done [11:30] <plepere> http://pastebin.com/iz9XvgYV is what I'd have for one function. [11:30] <plepere> I have to do this for 15 others at least [11:31] <nevcairiel> well you could macro that so that you only end up calling one macro for every of those [11:31] <ubitux> a innefficient to have such as huge table though [11:32] <plepere> macros in a macro. inception much ? [11:32] <nevcairiel> I dunno how it looks in the end, but usually you can greatly factor out the repetetive things in DSP init [11:39] <ubitux> and now j-b trolling ffmpeg on libav channel [11:39] <ubitux> did i make him that upset? [11:41] Action: wm4 gets popcorn [11:41] <JEEB> he probably had a bad morning? [11:41] <JEEB> I did really seemingly walk on a land mine with him [11:41] <JEEB> noting to a user that it's most probably simpler to build mpv-build than VLC's contribs to get a player with a newer libav* inside [11:42] <JEEB> (that user seemingly needed a newer libav* than his distro gives) [11:43] <ubitux> where was that? :) [11:44] <JEEB> #videolan [11:45] <{V}> trac's down? [11:46] <ubitux> JEEB: oh i see [11:46] <ubitux> he thought i was teasing him about that because i'm on the chan [11:46] <ubitux> heh i guess i should try to tell that to him [11:54] <ubitux> trac down [12:28] <michaelni> trac is up again, ping me if you see problems [12:28] <michaelni> that is ping me and beastd if he is here [12:56] <smarter> plepere: I tried fusing the (un)weighted prediction with the qpel stuff but gave up [13:11] <smarter> can't remember why exactly, hmm [13:12] <BBB> ubitux: yes [13:18] <smarter> I think what annoyed me was that depending on whether you use fused mc+(put_un)weighted_pred, the result is an uint8_t buffer, buf if you do two mcs (so that you can do a weighted average afterwards), you end up with an uint16_t temporary buffer [13:25] <smarter> ah right, I remember I just wanted to avoid the temporary buffer by writing the interpolation result in the frame, but you can't do that when the interpolation result is 16 bits [13:26] <smarter> so you need two set of MC functions, which annoyed me too much to do :) [13:30] <smarter> plepere: also don't write put_hevc_qpel[0][0][4] = , put_hevc_qpel[0][0][8] =, ... or you'll be wasting space with empty members in the array, instead use put_hevc_qpel[0][0][0] =, put_hevc_qpel[0][0][1] =, etc [13:32] <smarter> (and use a macro or a for loop to avoid repeating yourself) [14:20] <cone-903> ffmpeg.git 03Paul B Mahol 07master:74906d3727ec: avcodec/libopusenc: change default frame duration to 20 ms [14:24] <wm4> durandal_1707: did you have a look at the mp3 that failed probing yet? [14:26] <durandal_1707> wm4: no, and i do not plan to [14:29] <plepere> thank you for the tips, smarter. [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.0:0227ecc21f1a: build: avoid stdin stall with GNU AS probing. [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.0:cebad79898a4: avformat/utils: dont count attached pics toward the probesize [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.1:7f174cec8bd5: build: avoid stdin stall with GNU AS probing. [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.1:f401e600638b: avformat/utils: dont count attached pics toward the probesize [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/1.2:25c67b216534: avformat/utils: dont count attached pics toward the probesize [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/1.2:d04e78805aa4: build: avoid stdin stall with GNU AS probing. [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.0:9a22d6dd6326: avformat/utils: dont count attached pics toward the probesize [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.0:ff4c53e8b306: build: avoid stdin stall with GNU AS probing. [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.0:93716f7bea11: avformat/image2: allow muxing gif files. [15:19] <cone-903> ffmpeg.git 03Lou Logan 07release/2.1:5c8845a55478: Fix example in pullup documentation. [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:3193b85be333: avcodec/tiff_common: allow count = 0 in ff_tadd_bytes_metadata() [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.1:7ce0f4ea3b20: avformat/image2: allow muxing gif files. [15:19] <cone-903> ffmpeg.git 03Clément BSsch 07release/2.1:c38af02626fb: build: avoid stdin stall with GNU AS probing. [15:19] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:842def7d7813: avformat/utils: dont count attached pics toward the probesize [16:07] <plepere> san someone tell me if what I'm doing is good practice or if I should re-organize how I'm writing my asm ? : http://pastebin.com/74AAHyCR [16:09] <plepere> *can [16:09] <plepere> thanks in advance [16:12] <cone-903> ffmpeg.git 03Valeriy Argunov 07master:cc20fbcd39c7: rtmphttp: Check for both 0 and AVERROR_EOF [16:12] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:cbefb3d9098b: Merge remote-tracking branch 'qatar/master' [16:14] <ubitux> use m0..mN names instead of explicit xmmN probably [16:14] <ubitux> weird alignment btw [16:14] <ubitux> you can also name the registers from teh prototypes [16:15] <plepere> I tried that, but it returned errors. [16:15] <plepere> it's cglobal put_hevc_mc_pixels_2_8, 9, 12, 0 , dst, dststride, srd, srcstride,width,height [16:15] <plepere> that I should do ? [16:16] <ubitux> yes, then don't forget the suffix when using [16:16] <ubitux> such as dstq, widthd, etc [16:16] <plepere> how do I know the suffix ? [16:17] <ubitux> it's the size [16:17] <ubitux> q 64 d 32 .. [16:17] <plepere> so dst should be w and src should be b N [16:17] <plepere> ? [16:18] <plepere> using dstq gives me an ugly image. :p [16:18] <ubitux> dstq srcq ? [16:19] <plepere> never mind. I'm terrible at programming. works like a charm now [16:21] <smarter> plepere: nitpick: you're supposed to align everything on ',' and leave a space after it [16:21] <plepere> ok smarter. [16:22] <plepere> easy way to do this on eclispe ? [16:22] <smarter> I only know how to do it with emacs :P [16:22] <plepere> so all , should be one above the other. right ? [16:22] <ubitux> in eclipse, iirc it's: click on the top right cross to close it and open a text editor [16:22] <smarter> haha [16:22] <plepere> haha, nice one [16:23] <smarter> plepere: look at vp*asm for good examples :) [16:23] Action: JEEB golfclaps [16:24] <plepere> ok, I got this [16:25] <smarter> also the other day I reformated hevc_deblock.asm (but I haven't reviewed it yet): https://github.com/smarter/libav/blob/hevc_dbl_asm/libavcodec/x86/hevc_debl… [16:43] <plepere> see you all tomorrow [16:44] <plepere> thanks for all the fish. [16:46] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:7d0e927a31ed: avformat/mpegts: fix resync seek [17:49] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:d4a6133ab8ca: Add decoder dependency to the HEVC parser. [17:52] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:3f2ce316cda3: Add a Makefile rule for the little-endian G.726 decoder. [17:52] <nevcairiel> curious why someone would care so much for h261 encoding o.o [17:53] <smarter> nevcairiel: it has been proposed as a fallback codec for WebRTC [17:53] <smarter> https://www.ietf.org/mail-archive/web/rtcweb/current/ [17:53] <nevcairiel> seriously, they didnt find any older codecs [17:53] <smarter> H.120 [17:55] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.1:a289b0b91a79: avformat/mpegts: fix resync seek [18:08] <ubitux> trac down? [18:08] <ubitux> (michaelni? ^) [18:12] <ubitux> seems re-up [18:13] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:2974050cf578: Add a lavc Makefile dependency for the elbg filter. [18:13] <michaelni> ubitux, yes, dont ask me what it was i just read that its down and checked and it already was up [18:16] <michaelni> maybe beastd was making a backup or something [21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:5db49fc38d91: avcodec/pcm-dvd: fix 20bit 2 channels [21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:ab184b298d4a: avcodec/pcm-dvd: fix 20/24bit 1 channel [21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:4adf1fe34f17: avcodec/pcm-dvd: fix incorrectly printed warning about changed block sizes [21:06] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:918cab1a9f68: avcodec/pcm-dvd: print actual block size values in block size changed warning [22:39] <michaelni> mraulet, anything new i should cherrypick / merge ? also, not sure you already saw https://trac.ffmpeg.org/ticket/3115 (hevc crash) [22:40] <mraulet> i will merge in the master everything you can cherry pick [22:41] <mraulet> our hevc branch contains an shvc decoder that is not standard yet :-) [22:41] <mraulet> but I need to merge tiles and wpp related stuff, it works well in combination with frame-based now [22:42] <mraulet> I need to check your file [22:42] <mraulet> file/ticket [22:43] <michaelni> ok, thanks [23:22] <baptiste> hevc ? nice [23:24] <ubitux> BBB: sorry i'm delaying the review to tomorrow [23:29] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:f0f04fd84294: avcodec/asvenc: remove code allocating dummy coded_frame [00:00] --- Tue Nov 19 2013

1 0

ffmpeg.log.20131118
by burek 19 Nov '13

19 Nov '13

[02:20] <ItsMeLenny> what was the command just to convert the video without the audio? [02:21] <ItsMeLenny> i guess just one stream [02:24] <klaxa> add -an to the command line [02:25] <klaxa> that will drop audio [02:59] <ItsMeLenny> klaxa, thanks, i found that, it wasnt the one i was thinking of tho, but is probably much better for what i needed to do [02:59] <klaxa> that's nice to hear :) [07:18] <prkhr4u> Could not find codec parameters for stream 0 (Video: mpeg4, yuv420p): unspecified size exact output @ http://pastebin.com/xpyYYP7V [10:14] <Peace-> hi is there a way to NOT show the window when i play sounds with ffplay? [10:15] <ubitux> -nodisp [10:18] <Peace-> ubitux: mm ok this could work ... but for video it disable video too [10:19] <ubitux> yes [10:19] <Peace-> i am trying to patch dolphin to play audio and video when the mouise is overing a file on kde [10:19] <Peace-> well i could do a little script that check if it' sa video or an audio [10:20] <Peace-> let me try [10:21] <ubitux> in combination with ffprobe that should be easily doable, but ofc you can also patch ffplay easily [10:24] <Peace-> ubitux: i have this idea i check the extension of a file if the extension is flac oga wav etc then ... nodisp else [10:24] <Peace-> ... [10:25] <Peace-> so no ffprobe but ... maybe you idea could be better [10:25] Action: Peace- investigate [10:26] <ubitux> Peace-: ./ffprobe -v 0 -show_entries stream=codec_type -of flat input [10:26] <ubitux> (you can output json or whatever) [10:27] <ubitux> you will get output like that: [10:27] <ubitux> streams.stream.0.codec_type="data" [10:27] <ubitux> streams.stream.1.codec_type="video" [10:27] <ubitux> streams.stream.2.codec_type="audio" [10:27] <ubitux> you have all kind of writers (xml, json, compact, csv, ..) [10:29] <ItsMeLenny> does anybody know why MTS files wont play correctly in VLC on ubuntu, they worked fine on my friends mac, what seems to happen is it plays the top 1/8 of the screen then smears the rest of the image downwards [10:30] <JEEB> unless you are using some special VLC package that's newer than what the general ubuntu repos contain, both the VLC and the libav* libraries are old [10:31] <ItsMeLenny> oh [10:31] <ItsMeLenny> which is a shame because nobody will be able to see what this amazing dancer is doing https://drive.google.com/file/d/0B_kjh0L1etroRzFMMV9Db0xjNXc/edit?usp=shari… <-- image of the problem [10:31] <JEEB> since VLC 2.1 was released seemingly too close to the last Ubuntu release [10:32] <JEEB> and because debian/ubuntu was still within a libav (the project debian/ubuntu is using instead of the ffmpeg project) version transition, the libraries are quite old as well [10:32] <JEEB> on OS X VideoLAN is building the libraries themselves and the person has grabbed probably the newest version? [10:33] <ItsMeLenny> ahh [10:33] <ItsMeLenny> yeah i think they had close to the original version [10:33] <ItsMeLenny> but i have vlc 2.2.0, and the thing is, movie player plays the video without the audio, where as vlc plays the audio with the video skewed [10:34] <JEEB> so you built your own VLC? [10:34] <JEEB> some random nightly [10:34] <JEEB> in any case, this probably is more related to #videolan than to #ffmpeg [10:37] <ItsMeLenny> yeah nobody responds in videolan :P but yeah a random nightly, their nightly im pretty sure [10:37] <ItsMeLenny> ahh maybe i was in #vlc before not #videolan [10:38] <JEEB> never been to #vlc, #videolan is the general videolan-related channel [10:52] <tachyean> hello [10:54] <tachyean> i'm trying to capture jpeg images from an rtmp stream and save them to disk, i've managed to do it but when i run the ffmpeg command i must wait between 1 and 2 minutes for the capture to start, there is any way i can make it start sooner than 1 minute? [10:56] <tachyean> this is the command i'm running: http://pastebin.com/wKBwTPB6 [10:56] <tachyean> any1? [11:29] <tachyean> -analyzeduration 0 was the problem, thank anyway [11:30] <tachyean> thanks* [13:03] <vl4kn0> Hi, I've got single filter link: buffersrc -> fps -> buffersink, where fps is initialized with argument "fps=4". Now I feed the filter graph exactly by the doc/examples but I always get more AVFilterBufferRef coming out of the filtergraph than going in. (About 167 per one decoded frame). Is there anything I should look out for? [13:41] <Mavrik> vl4kn0, proper PTS [14:09] <sspiff> hmmm, I did ../configure --disable-everything --enable-demuxer=mpegts --enable-decoder=dvbsub, but I can't seem to open a TS file anymore, any suggestions? [14:10] <sspiff> avformat_open_input fails, I'm still trying to find out why :) [14:11] <JEEB> hint: you might need a protocol [14:11] <JEEB> (file is a protocol as well) [14:13] <sspiff> JEEB: thanks! [14:16] <sspiff> JEEB: even without --enable-protocol=file, it gives a list of enabled protocols at the end of ./configure though, including file [14:45] <DrSlony> Hi! Please help, why do my screencasts end up playing 2-3 times as fast? Watch the seconds in the clock in the taskbar. Screencast here http://rawtherapee.com/bugs/issue795/rt795_zoom-center.mp4 Log file here http://paste2.org/fwhUxZKc [14:46] <DrSlony> When I found this a week or two ago I was using ffmpeg-1.0.7 or 1.2.4, so I installed 2.1 and no change. [14:47] <klaxa> using -r for the input causes that [14:48] <klaxa> x11grab is not able to get frames fast enough, therefore waits until it has accumulated enough frames for the desired framerate and puts those frames into a second [14:48] <vl4kn0> Mavrik: I set frame->pts like this: frame->pts = av_frame_get_best_effort_timestamp(frame); just like the doc/examples says [14:48] <klaxa> that's why it is playing back too fast [14:48] <DrSlony> so how do i overcome that? [14:48] <klaxa> try either using a lower framerate or omit it completely, i think that will result in a variable framerate [14:49] <Mavrik> vl4kn0, make sure timebases are properly set on filters [14:49] <vl4kn0> Mavrik: wil ldo [14:49] <vl4kn0> will do* [14:49] <Mavrik> fps filter needs a valid timebase since it works according to realtime :) [14:55] <vl4kn0> Mavrik: I'm using AVStream->codec->time_base for filter initialization which reports: time_base=1001/48000, but AVStream->time_base reports: 1/48000. Which one should I use? [14:57] <Mavrik> vl4kn0, the time base your packet PTS are in [14:57] <Mavrik> that's usually the stream TB [15:06] <vl4kn0> Mavrik: I set the time_base for buffersink to AVStream->time_base and now it works. But the doc/examples/filtering_video.c uses AVStream->codec->time_base and the same function for calculating frame->pts. Why is that? Can I safely assume that the program will work everywhere with every codec as expected? [15:07] <Mavrik> vl4kn0, hmm, I don't really understand the question [15:07] <Mavrik> time_base sets the units in which timestamps on packets are expressed in the stream [15:08] <Mavrik> if you have timebase of 1/48000 that means that packets with timestamp "1" and "2" are 1/48000th of a second apart [15:08] <Mavrik> and packets "1" and "48000" are 1 second apart [15:09] <Mavrik> so if you want to check how many frames do you have in 1 second you need to know the same timebase that timestamp number on packet is - that's why you need the value from AVStream [15:11] <vl4kn0> Mavrik: let me ask again then. doc/examples uses time_base from AVCodecContext instead of AVStream. For me, time_base from AVCodecContext does not work. Why is that? [15:12] <Mavrik> weeelll..... [15:12] <Mavrik> lemme see how to explain that [15:13] <Mavrik> you can have several streams in one container... and those streams can contain different type of frames with different requirements... so timestamps for each stream can be represented in different timebase [15:13] <Mavrik> (e.g. usually video frames are timestasmped in 1/90000 timebase, audio in 1/sample_rate timebase) [15:14] <Mavrik> however, when you store them into a container (e.g. MKV), you still need to sync them there somehow [15:15] <Mavrik> so the container may have it's own timebase in which packet timestamps (which are different than video/audio frame timestamps, but related) are stored [15:15] <Mavrik> and AVCodecContext has a "global" container timebase, while each stream's AVStream structure has timebase for that stream [15:15] <Mavrik> decoded frames always carry PTS in steam timebase, while encoded AVPackets have PTS in CodecContext's timebase [15:15] <Mavrik> IIRC. [15:17] <vl4kn0> Mavrik: cool, I did not know that. Thanks for explanation. [15:21] <Mavrik> hmm, I might have been wrong about AVPacket timebase - it seems it gets adjusted [15:33] <ddsss> is there any way to test .wav files for correctness? [15:36] <JEEB> how would you? other than for the headers, it's just raw pcm audio [15:37] <ddsss> JEEB, yeah. I thought that much. Headers are "audio/x-wav; charset=binary" - so I asume magic byte is fine. [15:39] <JEEB> that looks like http headers, not headers of the actual wav file [15:39] <JEEB> as it should contain the type of audio, amount of tracks etc. [15:39] <ddsss> JEEB, I just ran: file -ifile.wav [15:39] <ddsss> JEEB, I just ran: file -i file.wav [15:40] <JEEB> ffmpeg -i welp.wav or ffprobe welp.wav and see what it can output [15:40] <JEEB> if it gets the audio type and amount of channels right [15:42] <ddsss> JEEB, avprobe w8wn8.wav, gets this: http://paste.ubuntu.com/6437787/ [15:43] <ddsss> JEEB, looks good to me? [15:43] <ddsss> JEEB, but for some reason IOS7playback doesn't always work with that file. [15:44] <JEEB> have fun reading through the API :) [15:44] <JEEB> regarding various limitations of what that API can take in [15:45] <ddsss> JEEB, API of what? [15:45] <JEEB> whatever that thing you just noted is/uses [15:47] <sspiff> JEEB: turned out, I needed --enable-parser=dvbsub, in case you're interested :) [15:50] <JEEB> sspiff, well yes -- kind of thought it was something like that :P [15:53] <sspiff> JEEB: thanks for the hint, I wouldn't have found it as fast as I did without it :) [16:00] <MPLAYER_> I followed the centos compilation guide and it is working great, however i was wodnering if it is a standalone binary or does it use external binaries or libraries? [16:02] <MPLAYER_> for example the yasm binary which is compiled during the installation guide [16:02] <MPLAYER_> does the ffmpeg binary use this external binary or not? [16:02] <MPLAYER_> or is this yasm binarie included in the ffmpeg binary [16:08] <JEEB> yasm is a x86 assembler [16:08] <JEEB> it compiles asm to object files [16:08] <JEEB> which can then be linked [16:09] <JEEB> also what the binary needs can be seen with ldd [16:09] <JEEB> as far as libraries go [16:36] <MPLAYER_> wht i just mean [16:36] <MPLAYER_> is the binary of ffmpeg a standalone binary [16:37] <sacarasc> Depends if you compiled it as static or not. [16:37] <MPLAYER_> as it doesnt depend on the locations of the yasm binary [16:37] <klaxa> i don't think yasm is required after compiling? [16:37] <MPLAYER_> and the x264 command [16:38] <relaxed> yasm is used to build the binary, that is all. [16:38] <klaxa> ffmpeg uses libx264 either as a shared library or compiled in a static binary [16:38] <MPLAYER_> so the ffmpeg binari in the centos compilation guide is really standalone [16:38] <MPLAYER_> i can move it along in the distro [16:39] <klaxa> if you compiled it with --extra-ldflags=-static it should be [16:39] <MPLAYER_> and delete al the other files [16:39] <MPLAYER_> the guide lists --extra-ldflags="-L$HOME/ffmpeg_build/lib" [16:40] <relaxed> then no [16:40] <klaxa> then it will not be a static build [16:42] <JEEB> <MPLAYER_> is the binary of ffmpeg a standalone binary <- just use ldd to see what libraries the ffmpeg binary needs [16:42] <JEEB> as I already said [16:42] <JEEB> and then start looking into what of those you can and which of those you want to remove [16:45] <relaxed> You can use yum to list the package to install based on a specific file's name and location. It would be trivial to write a small shell script that iterates over each lib from `ldd`'s output and install everything you need on each host. [16:47] <relaxed> or this http://johnvansickle.com/ffmpeg/ [17:12] <MPLAYER_> If I have a server with 24 cores and I have nodejs running on it and nginx and ffmpeg. Do I have to divide the number of cores for each process or can I set for each process that there are 24 cores available? [17:14] <relaxed> I think libx264 will only use 12, but you can force it to use <=12 with -threads $number [17:15] <relaxed> actually you might be able to force >12, I've never been in the position to try :) [17:16] <MPLAYER_> but do I have to set for nginx also the no of cores at 24 or can i best divide them to each other for eaxample 12 for ffmpeg and 12 for nginx [17:17] <MPLAYER_> or both at 24 [17:18] <relaxed> That might be wise. Try some different loads and monitor `htop` to see how effectively they're used. [17:22] <relaxed> maybe start with -threads 6 [17:46] <DrSlony> klaxa you were right, without -r the fps matches real time, though more jaggy [19:05] <cccp3> windows problem!- if i use say, ffmpeg -i img%06d.ppm e.avi -r 500 - in a batch file, instead of the simply %06d showing to ffmpeg, it uses its path, (ikr that it is windows' fault, just speading the word) [19:05] <cccp3> well, its path then a "d" [19:06] <cccp3> say, path is d:\batch.bat then it will be d:\batch.batd instead of %06d.ppm [19:07] <cccp3> hellooo? [19:07] Action: cccp3 rings a bell that sounds all over the earth [19:07] Action: cccp3 shouts bye and leaves [20:15] <slackerr> hi all. where can i find some encoding settings for ffmpeg to obtain youtube-like videos in quality from 144p, 240p .. to 1080p [20:15] <slackerr> for network streaming [20:17] <llogan> slackerr: are you hosting these videos? is it live streaming or progressive download? [20:18] <slackerr> llogan: both cases. rtmp hosting for streaming live videos, and also youtube-like viewing of placed media [20:19] <slackerr> i tried to find settings in web, but now without success [20:23] <llogan> slackerr: ffmpeg -i input -c:v libx264 -crf 28 -preset slow -vf scale="1280:trunc(ow/a/2)*2" -c:a libfdk_aac -vbr 4 -movflags faststart output.mp4 [20:23] <llogan> for progressive download that could be a good start [20:24] <llogan> https://trac.ffmpeg.org/wiki/x264EncodingGuide [20:25] <llogan> if there is a minimum client transfer rate you want to support then use -bufsize and -maxrate [20:25] <llogan> http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#VBV_Encoding [20:25] <llogan> Example 3 [20:27] <llogan> scale="1280:trunc(ow/a/2)*2,format=yuv420p" would be better depending on input format [20:27] <slackerr> llogan: did you mean 'progressive download' is typical youtube video placed somewherre on server? [20:28] <llogan> "streaming" generally means the encoder is working in real time and "progressive download" means the viewer is downloading a video from the server and playing it. the video was previously encoded. [20:31] <slackerr> ok. i understood. will begin from progressive download first [20:34] <slackerr> is it neccesary to use youtube-like x264 codec for progressive download, or easier xvid is fine too? [20:35] <slackerr> is it possible to see standard specs for streaming in youtube style? are they exists? [20:35] <slackerr> in specs i mean screen size, audio codec, video codec, bitrates [20:37] <llogan> no and no [20:38] <llogan> as in use H.264, not "xvid" (MPEG-4 part 2 video) [20:38] <llogan> and there are no standard specs. [20:41] <slackerr> ok. what about containers? youtube places his videos in .flv, .mp4, .webm, containers. and for audio is mp3 with lower freq in smaller formats. is it ok? i will not use webm vp8/vorbis in my tasks [20:42] <JEEB> just use AAC or AAC derivatives if you won't be using the vorbis-specific stuff [20:42] <JEEB> you have no real reason to use MP3 at all [20:42] <llogan> you don't have to try to copy youtube exactly [20:43] <slackerr> i dont want to copy. but i can't imagine better examples in video codec/format/size etc [20:43] <JEEB> ugh, you are completely missing the fact that whatever 'tube does is just what they've decided to do, what you should do is up to YOUR needs and YOUR audiences [20:44] <llogan> why don't you just use youtube then if it is teh brest [20:44] <slackerr> as you said, there are no specs. so i should do it myself with youtobe examples and instructions you gave me. or some other hosting for examples. thank guys very much for useful infos [20:45] <llogan> i just gave you a "generic" example. but explaining more about your requirements and the audience will help [20:51] <slackerr> my global target is to create profiles for encoding video uploaded on server into several qualities , as youtube has. its for progressive download - quality in 144p, 240p, 360p, 480p, 720p, 1080p. To do it, i need to have knowledge in encoding 'standards'. But, if as you said, they're not exists, i will teach it by your docs [20:52] <llogan> just use my example and change the "1280" to each of your desired widths [20:53] <llogan> include the format=yuv420 part [20:54] <llogan> you will have to compile ffmpeg to use libfdk_aac though [20:54] <llogan> http://trac.ffmpeg.org/wiki/CompilationGuide [20:54] <llogan> https://trac.ffmpeg.org/wiki/AACEncodingGuide [20:59] <slackerr> for what it needs, a libfdk_aac ? [20:59] <slackerr> is it better than typical aac? [21:04] <llogan> slackerr: see the AAC link [21:08] <_methods> can anyone point me to a good tutorial for setting up ffserver to use a remote ipcamera as an input? [21:08] <_methods> i'm having some difficulty figuring out the config params [21:09] <llogan> _methods: might help -> http://trac.ffmpeg.org/wiki/Streaming%20media%20with%20ffserver [21:09] <llogan> ffserver is basically unmaintained [21:09] <_methods> llogan: oh [21:10] <_methods> why it seems awesome [21:10] <llogan> because nobody has volunteered to do so [21:10] <_methods> oh hahah [21:11] <_methods> well i don't have the skills reqd for that [21:11] <_methods> but i will say it's an awesome capability i think [21:11] <llogan> that wasn't a joke though. maybe the code is a mess, but i don't know [21:12] <llogan> it might work for you though [21:12] <_methods> yeah i kinda got it to work [21:12] <_methods> but i think i'm giving my cameras configs wrong [21:12] <_methods> i'll try feeding with straight ffmpeg feed and modify from there i guess [21:12] <llogan> maybe you should test the input with ffmpeg or ffplay first [21:13] <_methods> yeah [21:13] <slackerr> how to see list of supported codecs for my binary ffmpeg? [21:14] <_methods> well the ipcam is outputting .asf i think [21:14] <llogan> slackerr: ffmpeg -codecs, ffmpeg -encoders, ffmpeg -decoders [21:14] <_methods> i still need to do some checking [21:14] <_methods> i was just wondering if there was some more documentation somewhere [21:14] <_methods> i don't mind doing the RTFM thing [21:15] <_methods> i'm just trying to find a good manual lol [21:15] <llogan> what is the protocol the camera uses to output to (udp, http, etc)? [21:15] <_methods> well it's http [21:15] <_methods> but i think it will do rtsp [21:15] <llogan> http://ffmpeg.org/ffmpeg-protocols.html [21:15] <_methods> so i'll probably get it working with a simple webcam ffmpeg capture first [21:15] <_methods> then try to use the ipcamera [21:16] <_methods> cause the ipcamera coudl be the problems [21:16] <llogan> http://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 [21:16] <llogan> webcam [21:17] <_methods> yeah [21:17] <_methods> thaank you [21:25] <Samus_Aran> anyone know why ffmpeg sometimes doesn't start encoding, and just eats CPU for several minutes or longer? [21:26] <Samus_Aran> # ffmpeg -i 00010.MTS -ss 00:01:02 -to 00:01:05 -acodec copy -vcodec libx264 -preset fast -crf 12 -vf super2xsai out-2xsai.avi [21:27] <Samus_Aran> that for instance has been eating 106% CPU (dual-core) for 10 minutes so far, without having started encoding any frames [21:27] <relaxed> Samus_Aran: -ss after the input decodes the video untill that point. If you want fast seeking move it before the input. [21:28] <relaxed> until* [21:28] <relaxed> also, you don't want h264 in avi. Use mkv or mp4. [21:30] <Samus_Aran> mp4 doesn't accept pcm, mkv was producing dts errors if clips were cut, but AVI is fine. [21:30] <relaxed> warnings or errors? [21:33] <Samus_Aran> it was mangling timestamps, and causing video freezing, but that's not what I'm trying to get help with. just trying to find out why it can sit there for 10 minutes [21:34] <llogan> you should always include the complete console output [21:35] <Samus_Aran> it doesn't complete... [21:35] <Samus_Aran> that was the point [21:36] <llogan> relaxed already told you why, but also see "-ss" option in http://ffmpeg.org/ffmpeg.html [21:46] <Samus_Aran> relaxed, llogan: thank you. I had read that recently and forgot about the position mattering. sorry. [22:18] <Samus_Aran> when I cut segments with -ss and -t, and then play it, it displays a single frame for around a half second before the video starts [22:18] <Samus_Aran> is there any way to make the audio to match? [22:21] <Samus_Aran> with -t 3 the video is exactly 3 seconds long, but the audio is longer [22:23] <Samus_Aran> these would be the same issues I was having with mkv timestamps [22:24] <Samus_Aran> I assume [22:27] <Samus_Aran> with -t 3 it produces a 3.72 second audio clip, and a 3.72 second video clip, but the first 0.72 seconds of the video are unchanging [22:27] <Samus_Aran> and very low bitrate in the h.264 encoding part [22:40] <Samus_Aran> http://pastie.org/pastes/8490848/text [22:40] <Samus_Aran> llogan: pasted [22:43] <relaxed> Samus_Aran: try again with -bf 0 [22:47] <brontosaurusrex> what would be a "tv to pc" scale filter? [22:47] <Samus_Aran> relaxed: no luck (still longer than 3 seconds, with the gap in video) [22:47] <brontosaurusrex> basically i'd like to clap or compress 0-16 and 230-255 values [22:49] <llogan> give it "the clap" [22:52] <llogan> Samus_Aran: is this from an HMC105? [22:52] <llogan> *150 [22:53] <Samus_Aran> Sony NEX-5 (AVCHD) [22:54] <Samus_Aran> I tested with avi, mkv and mp4 containers, and avi and mp4 both have the .72 second gap before the video starts moving. the mkv starts immediately, due to timestamps [22:55] <Samus_Aran> but the mkv still contains 3.72 seconds of audio and video streams [22:55] <Samus_Aran> it just hides it [22:56] <Samus_Aran> and then breaks once I start combining several mkvs, as long gaps and freezes appear [23:05] <Samus_Aran> this issue isn't specific to the .mts format, I re-encoded a whole .mts file to .mkv and then tried to cut a piece out with -codec copy, same problem [23:05] <Samus_Aran> it produces a 4 second clip instead of 3 seconds [23:21] <bewilled> what is better flv or mp4? [23:21] <bewilled> for a video sharing site [23:28] <Samus_Aran> bewilled: neither is better [23:29] <Samus_Aran> flv and mp4 are container formats, they can both contain h.264 video [23:29] <Samus_Aran> what is your goal? high quality, small size, compatibility, etc.? [23:37] <bewilled> Samus_Aran, compatibility, and look for the perfect ratio between small size and quality [23:43] <brontosaurusrex> bewilled, mp4 is more compatible with different players than flv, quality as allready pointed out can be the same. [23:54] <Samus_Aran> bewilled: mp4 (avc + aac), flv (avc + aac), and webm (vp8 + vorbis) can all be good quality:size ratio [23:55] <Samus_Aran> for encoding h.264/avc, use a slower preset for smaller files with the same quality [00:00] --- Tue Nov 19 2013

1 0

ffmpeg-devel.log.20131117
by burek 18 Nov '13

18 Nov '13

[00:01] <cone-755> ffmpeg.git 03Anton Khirnov 07master:5b9c3b450520: Replace all instances of avcodec_alloc_frame() with av_frame_alloc(). [00:01] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:0ee905e24307: Merge commit '5b9c3b4505206143d85398c1410949319fa1180f' [00:10] <cone-755> ffmpeg.git 03Anton Khirnov 07master:b9fb59d2ab05: lavc: deprecate avcodec_alloc_frame(). [00:11] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:29c83d23e8ed: Merge commit 'b9fb59d2ab05fdfe89d3fb0d7ecbbd91e560f57d' [00:20] <cone-755> ffmpeg.git 03Anton Khirnov 07master:13e9cc9ce064: a64multienc: use the AVFrame API properly. [00:20] <cone-755> ffmpeg.git 03Anton Khirnov 07master:6139f481ac9f: asvenc: use the AVFrame API properly. [00:20] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:cc4a6435638f: Merge commit '6139f481ac9feb1bee4e7d04789fb15d7f24ebbf' [00:36] <cone-755> ffmpeg.git 03Anton Khirnov 07master:33329c6e872f: avs: use the AVFrame API properly. [00:36] <cone-755> ffmpeg.git 03Anton Khirnov 07master:a83fd5010c4e: bethsoftvid: use the AVFrame API properly. [00:36] <cone-755> ffmpeg.git 03Anton Khirnov 07master:670c74518f2d: c93: use the AVFrame API properly. [00:36] <cone-755> ffmpeg.git 03Anton Khirnov 07master:cec5ce49229d: cdxl: remove an unused variable [00:37] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:21c41e76d7c1: Merge commit 'cec5ce49229d61e4eb1f331a6d0dff3aa24f6655' [00:58] <cone-755> ffmpeg.git 03Anton Khirnov 07master:4a8a35bc1ffe: cinepak: use the AVFrame API properly. [00:58] <cone-755> ffmpeg.git 03Anton Khirnov 07master:845020ed89ca: cljr: use the AVFrame API properly. [00:58] <cone-755> ffmpeg.git 03Anton Khirnov 07master:224b6edd8bea: qtrle: use the AVFrame API properly. [00:58] <cone-755> ffmpeg.git 03Anton Khirnov 07master:a639ea7f4bc4: escape124: use the AVFrame API properly. [00:58] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:bfb1f44d246f: Merge commit 'a639ea7f4bc44bf6bfa452675558a342924a66a9' [01:14] <cone-755> ffmpeg.git 03Anton Khirnov 07master:ef2a99c7f4c4: msvideo1: use the AVFrame API properly. [01:14] <cone-755> ffmpeg.git 03Anton Khirnov 07master:01de3c1dd57a: cin video: use the AVFrame API properly. [01:14] <cone-755> ffmpeg.git 03Anton Khirnov 07master:55f954e7678f: qpeg: use the AVFrame API properly. [01:14] <cone-755> ffmpeg.git 03Anton Khirnov 07master:2d2a92f72199: dxa: use the AVFrame API properly. [01:14] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:5219afc09d8e: Merge commit '2d2a92f72199823a92e4e226c32e42a27ec801c0' [01:28] <cone-755> ffmpeg.git 03Anton Khirnov 07master:b7462a3904d7: jvdec: use the AVFrame API properly. [01:28] <cone-755> ffmpeg.git 03Anton Khirnov 07master:952f943d40e9: FATE: add a jv test [01:28] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:ddfdcd2b5ecc: Merge commit 'b7462a3904d71ff799584faf5b875cad59ca2f31' [01:28] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:10ac6f3ce9ae: Merge commit '952f943d40e9dbcd68bc851460cc99268091a294' [01:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:c5dfb9033f52: msrle: use the AVFrame API properly. [01:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:4b8a1941465c: iff: use the AVFrame API properly. [01:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:79d501a860bd: indeo2: use the AVFrame API properly. [01:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:2e09096da912: kgv1: use the AVFrame API properly. [01:43] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:9f890a165666: Merge commit '2e09096da912f563c4dd889a8f25c314529bbaa6' [01:59] <cone-755> ffmpeg.git 03Anton Khirnov 07master:5c96f02901d8: mmvideo: use the AVFrame API properly. [01:59] <cone-755> ffmpeg.git 03Anton Khirnov 07master:84099f51f397: smacker: use the AVFrame API properly. [01:59] <cone-755> ffmpeg.git 03Anton Khirnov 07master:d100f9e7cd6d: flicvideo: use the AVFrame API properly. [01:59] <cone-755> ffmpeg.git 03Anton Khirnov 07master:a837c4f2df96: zmbvenc: use the AVFrame API properly. [01:59] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:fe3808eddee8: Merge commit 'a837c4f2df96a30bf9aa4115b426d608487c7101' [02:18] <cone-755> ffmpeg.git 03Anton Khirnov 07master:6886a85f5ca9: zerocodec: use the AVFrame API properly. [02:18] <cone-755> ffmpeg.git 03Anton Khirnov 07master:f3cd23fbc849: xxan: use the AVFrame API properly. [02:18] <cone-755> ffmpeg.git 03Anton Khirnov 07master:04f30711d8d2: xan: use the AVFrame API properly. [02:18] <cone-755> ffmpeg.git 03Anton Khirnov 07master:3c8ea9d4a74f: vmnc: use the AVFrame API properly. [02:18] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:8af7774c7aca: Merge commit '3c8ea9d4a74fd4d7493d40c818ca64ee492709f3' [02:33] <cone-755> ffmpeg.git 03Anton Khirnov 07master:aca214783af9: vmdvideo: use the AVFrame API properly. [02:33] <cone-755> ffmpeg.git 03Anton Khirnov 07master:e52f38bc2ea6: motionpixels: use the AVFrame API properly. [02:33] <cone-755> ffmpeg.git 03Anton Khirnov 07master:e8ef8a328c81: rpza: use the AVFrame API properly. [02:33] <cone-755> ffmpeg.git 03Anton Khirnov 07master:4a4841d4e0f0: fraps: use the AVFrame API properly. [02:33] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:4362f272c0ae: Merge commit '4a4841d4e0f0dc50998511bf6c48b518012024db' [02:40] <cone-755> ffmpeg.git 03Anton Khirnov 07master:42d40fd28cea: truemotion1: use the AVFrame API properly. [02:40] <cone-755> ffmpeg.git 03Anton Khirnov 07master:32f7cf9bc38a: truemotion2: use the AVFrame API properly. [02:40] <cone-755> ffmpeg.git 03Anton Khirnov 07master:68af7f54a6cd: smc: use the AVFrame API properly. [02:40] <cone-755> ffmpeg.git 03Anton Khirnov 07master:508b37557bf3: tiertexseqv: use the AVFrame API properly. [02:40] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:72df87088c8a: Merge commit '508b37557bf36eae83c18e64d42f27b44a321d81' [02:52] <smarter> BBB: hevs use 7-taps and 8-taps for luma (which is qpel), and 4-taps for chroma (which is eighth-pel) [02:52] <smarter> *hevc [02:54] <smarter> pretty sure there's nothing to share in the loop filter [02:55] <smarter> and I'm not really familiar with vp9 intra but I doubt it's similar enough [02:55] <smarter> maybe with a lot of conditionals [02:55] <smarter> like, doesn't vp9 intra ignore the top-right pixels for some reasons ? [02:56] <smarter> the way hevc does the angular mode is pretty specific, I'd be worried about lawsuits if VP9 did the same :] [02:56] <smarter> *modes [02:56] <cone-755> ffmpeg.git 03Anton Khirnov 07master:acaffdca21f6: mss1: use the AVFrame API properly. [02:56] <cone-755> ffmpeg.git 03Anton Khirnov 07master:e9198f61db90: mss2: use the AVFrame API properly. [02:56] <cone-755> ffmpeg.git 03Anton Khirnov 07master:207909911d31: mss3: use the AVFrame API properly. [02:56] <cone-755> ffmpeg.git 03Anton Khirnov 07master:730bac7bab3c: mss4: use the AVFrame API properly. [02:56] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:8d193a24f2da: Merge commit '730bac7bab3c7dcd9fcb7c70f154e5f4cfaef9a7' [02:58] <smarter> [14:07:35] <BBB> I always tended to split dsp stuff in its own header since arch-specific code depends on that header [02:58] <smarter> [14:07:41] <BBB> and you obviously don't want them to include all of vp9.h [02:58] <smarter> why not? [03:00] <smarter> BBB: if you care about code reuse, the {luma,chroma}_mc functions in hevc.c are very much inspired by vp8_mc_{luma,chroma} [03:01] <smarter> and I expect vp9 to be similar [03:02] <smarter> so it might make sense to share code [03:06] <BBB> smarter: but they're 8tap, not 4/6tap, right? [03:06] <BBB> oh, you mean decoder [03:06] <BBB> those are identical in all decoders, but they're not simd'able, so not easily sharable [03:07] <BBB> smarter: vp9.h includes a lot more than stuff that is relevant for dsp [03:07] <BBB> smarter: dsp stuff is best left alone, even if just as an academic exercise [03:07] <BBB> (alone as in "in it's own files" [03:07] <BBB> ) [03:08] <BBB> smarter: and for intra pred, you've never seen h264pred.c, it's a ifdef jungle [03:08] <BBB> smarter: but it works [03:09] <smarter> looking at it now, I don't see too many ifdef [03:10] <BBB> check the function assignments [03:10] <BBB> if (codec == ...) func = this; else if (codec == ...) func = that; else .. [03:10] <smarter> ah right :) [03:10] <BBB> of course the simd functions themselves are not if'ed, but that'd be silly for performance critical infrastructure [03:11] <BBB> so you could do that for vp9/hevc as well if they share stuff conceptually [03:11] <BBB> and some implementation is shared [03:11] <BBB> is hevc 8tap for luma and bilin for chroma? [03:11] <BBB> or is it similar to the staged qpel in h264? [03:12] <smarter> I wrote about that just before [03:12] <smarter> [02:52:08] <smarter> BBB: hevs use 7-taps and 8-taps for luma (which is qpel), and 4-taps for chroma (which is eighth-pel) [03:12] <smarter> there's no staged thing [03:12] <BBB> ohright sorry [03:12] <BBB> 4tap [03:12] <BBB> that's weird [03:12] <BBB> ohwell [03:12] <smarter> reasoning is that chroma is less important [03:12] <BBB> yes [03:13] <BBB> but 4pel is weird [03:13] <BBB> h264's bilin was sort of logical [03:13] <BBB> 4pel is sort of halfway in between [03:13] <BBB> ohwell I guess it makes sense [03:13] <smarter> have you seen pred_angular in hevcpred_template.c ? [03:14] <BBB> no, I heard there's 40 modes or so [03:14] <smarter> yeah, but they're all in one function with tons of conditionals [03:14] <BBB> ugh [03:14] <BBB> dude [03:14] <BBB> fix that :) [03:15] <smarter> not much to fix in the C code [03:15] <smarter> yasm macros should help [03:16] <smarter> but I doubt that vp9 angular modes are similar enough to that [03:18] <smarter> (there's also the incredible mess that is the intra_pred function in hevcpred_template.c to make the missing border samples available) [03:22] <BBB> yeah that's a mess in libvpx also [03:22] <BBB> ffvp9 did that quite nicely imo [03:24] <cone-755> ffmpeg.git 03Anton Khirnov 07master:6a08d7fcc528: sgienc: use the AVFrame API properly. [03:24] <cone-755> ffmpeg.git 03Anton Khirnov 07master:2a85a192c710: bmpenc: use the AVFrame API properly. [03:24] <cone-755> ffmpeg.git 03Anton Khirnov 07master:4e7e8055a7b6: dpxenc: use the AVFrame API properly. [03:24] <cone-755> ffmpeg.git 03Anton Khirnov 07master:e4155f15b35c: eamad: use the AVFrame API properly. [03:24] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:9ad477d9098b: Merge commit 'e4155f15b35c4272a235f5521d2dc6c2aabdd462' [03:37] <cone-755> ffmpeg.git 03Anton Khirnov 07master:042aec41ae0b: flashsv: use the AVFrame API properly. [03:37] <cone-755> ffmpeg.git 03Anton Khirnov 07master:6792559f8aa8: vc1: use the AVFrame API properly. [03:37] <cone-755> ffmpeg.git 03Anton Khirnov 07master:c8a525197fb5: ulti: use the AVFrame API properly. [03:37] <cone-755> ffmpeg.git 03Anton Khirnov 07master:d48c20630214: qtrleenc: use the AVFrame API properly. [03:37] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:92cbd7756872: Merge commit 'd48c20630214a4effcc920e93a5044bee4e2002e' [09:10] <Zeranoe> Any ideas on this one: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1468 [11:27] <JEEB> hmm, I think I'm relatively close to the demuxing and decoding example, but it seems like I'm getting some errors with some samples. Which either means that I'm missing extradata (although I'm using the lavc context provided by lavf, which I think should have that?), or that I'm set way too strict on the decoding side of things. [11:28] <ubitux> can you reproduce the issue with the example? [11:28] <JEEB> lemme build that one, too [11:29] <JEEB> it's integrated into the makefile, right? [11:29] <ubitux> see doc/examples/README [11:29] <JEEB> k [11:37] <JEEB> argh, should have just opted for in-tree compilation and not having a suffix [11:39] <JEEB> and I didn't build swresample... [11:39] <JEEB> at least I got the .o for the demuxing and decoding example [11:50] <JEEB> great, finally linked it manually [11:54] <cone-904> ffmpeg.git 03Anton Khirnov 07master:0ea430c75b8d: lclenc: use the AVFrame API properly. [11:54] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:85b7b0c519f8: Merge commit '0ea430c75b8d90449d2878ad84669a2da2ad3cbc' [11:55] <JEEB> the example seems to work [11:57] <JEEB> also it seems to output a ffmpeg-like input info screen, funky [11:58] <ubitux> av_dump_ thing? [11:59] <JEEB> yea [11:59] <JEEB> the difference pretty much is that I grab the lavc context from av_find_best_stream, while the example uses open_codec_context [12:01] <ubitux> open_codec_context does a av_find_best_stream [12:01] <ubitux> and then find a decoder and open it [12:01] <JEEB> lol [12:01] <ubitux> (you noticed it's a local function right?) [12:02] <JEEB> yes, I've just woken up [12:02] <JEEB> I did read through it some times last night [12:02] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/cli_test/cli_test.c… [12:02] <JEEB> yeah, rather similar [12:03] <JEEB> (that's basically a sample thing I've been doing to test basic one-frame decoding and swscale [12:06] <ubitux> (you need to unref the frame if you use the ref counting system) [12:06] <JEEB> yes, but I only decode one [12:06] <JEEB> aka until the first can_has_picture [12:07] <JEEB> http://up-cat.net/p/4b250f33 [12:07] <JEEB> I have a single H.264 sample that fails like this, and a H.263 sample [12:07] <JEEB> a HEVC sample works [12:07] <JEEB> (and a VOB with MPEG-2 works) [12:10] <JEEB> with -v debug with that sample I get [h264 @ 04bf51e0] no picture [h264 @ 04c4bb00] no picture [12:10] <JEEB> in ffmpeg [12:10] <JEEB> which might be related? [12:10] <JEEB> or I just fail at extradata somewhere (Ž [12:10] <nevcairiel> that just happens on a few badly cut streams [12:11] <JEEB> well, the question is -- how does the demuxing and decoding sample then brawl through this just fine? [12:11] <JEEB> although I guess it might something as simple as the decoding loop being more OK with certain kind of failures? [12:12] <JEEB> although I didn't notice anything special [12:12] <cone-904> ffmpeg.git 03Anton Khirnov 07master:78c6c9d6c1ac: pngenc: use the AVFrame API properly. [12:12] <JEEB> which thus again leads to it most probably being PEBKAC of my own [12:12] <cone-904> ffmpeg.git 03Anton Khirnov 07master:f26f71139faf: tiffenc: use the AVFrame API properly. [12:13] <cone-904> ffmpeg.git 03Anton Khirnov 07master:fb26d761676f: targaenc: use the AVFrame API properly. [12:13] <cone-904> ffmpeg.git 03Anton Khirnov 07master:45bde93eefa7: sunrastenc: use the AVFrame API properly. [12:13] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:3ea168edeb7a: Merge commit '45bde93eefa78c1bdb0936109fbd2e2fb27fbfe7' [12:14] <nevcairiel> the nal size messages basically mean that it was trying to read some mp4 nals with those sizes, and the sizes are just wrong [12:15] <JEEB> yes [12:16] <nevcairiel> so, is it actually a mp4/mkv? [12:16] <JEEB> but since the demuxing_decoding example doesn't get that I'm going to assume that I'm doing something wrong here [12:16] <JEEB> it is mkv [12:16] <nevcairiel> your file doesnt happen to have audio, does it? [12:16] <JEEB> it has audio, yes [12:17] <nevcairiel> because you blindly decode any packet with the video decoder [12:17] <nevcairiel> give it audio, it stops liking you [12:17] Action: JEEB facepalms [12:18] <JEEB> so I basically have to check what av_read_frame returns [12:18] <nevcairiel> at least its an easy fix, compare packet.stream_index or what its called to avstream.index or something [12:20] <JEEB> I somehow was just going through writing the code last night and didn't even think about what av_read_frame returns [12:32] <cone-904> ffmpeg.git 03Anton Khirnov 07master:219b35f5d169: gif: use the AVFrame API properly. [12:32] <cone-904> ffmpeg.git 03Anton Khirnov 07master:394ef4d18f37: svq1enc: use the AVFrame API properly. [12:32] <cone-904> ffmpeg.git 03Anton Khirnov 07master:d2287740d932: libx264: use the AVFrame API properly. [12:32] <cone-904> ffmpeg.git 03Anton Khirnov 07master:57e7b3a89f5a: dnxhdenc: use the AVFrame API properly. [12:32] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:5b0c70c2499e: Merge commit '57e7b3a89f5a0879ad039e8f04273b48649799a8' [12:36] <JEEB> oh I bet I'm going to be having fun [12:36] <JEEB> http://up-cat.net/p/76a4f768 [12:36] <JEEB> this change causes the output binary to crash at launch [12:36] <JEEB> and I'm not even joking [12:38] <JEEB> (ok, it seems to work in cmd.exe now while it crashed in msys's shell...) [12:40] <JEEB> (also debugging the crashing executable would crash visual studio :D ) [12:41] <cone-904> ffmpeg.git 03Anton Khirnov 07master:d56a114adc54: flashsvenc: use the AVFrame API properly. [12:41] <cone-904> ffmpeg.git 03Anton Khirnov 07master:5290e02a0a49: nuv: use the AVFrame API properly. [12:41] <cone-904> ffmpeg.git 03Anton Khirnov 07master:b18c7c8d3ddf: libxavs: use the AVFrame API properly. [12:41] <cone-904> ffmpeg.git 03Anton Khirnov 07master:97168b204a0b: eatgv: use the AVFrame API properly. [12:41] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:a0c0629dd963: Merge commit '97168b204a0b6b79bb6c5f0d40efdf7fc2262476' [12:56] <{V}> JEEB, because it tried to av_free_packet an AVPacket that's on the stack? [12:56] <JEEB> nope [12:56] Action: {V} might be jumping to conclusions based on the word free [12:57] <JEEB> the actual crashes were happening later [12:57] <JEEB> it's just that the msys shell didn't flush [12:57] <JEEB> + seemed to do something weird with MSVS debugging [13:03] <cone-904> ffmpeg.git 03Anton Khirnov 07master:372262853b31: libschroedingerenc: use the AVFrame API properly. [13:03] <cone-904> ffmpeg.git 03Anton Khirnov 07master:7ca97aa7ee46: roqvideo: remove unused variables [13:03] <cone-904> ffmpeg.git 03Anton Khirnov 07master:863a670e483d: pcxenc: use the AVFrame API properly. [13:03] <cone-904> ffmpeg.git 03Anton Khirnov 07master:ffe04c330335: libxvid: use the AVFrame API properly. [13:03] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:f4f7888bab70: Merge commit 'ffe04c330335add4c6d70ab0bb98e6b3f4f7abfa' [13:58] <cone-904> ffmpeg.git 03Anton Khirnov 07master:14b35bf065a3: huffyuv: use the AVFrame API properly. [13:58] <cone-904> ffmpeg.git 03Anton Khirnov 07master:706a92926cca: jpegls: use the AVFrame API properly. [13:58] <cone-904> ffmpeg.git 03Anton Khirnov 07master:a6064b12b481: ffv1: use the AVFrame API properly. [13:58] <cone-904> ffmpeg.git 03Anton Khirnov 07master:1c01b0253ebf: mpegvideo_enc: use the AVFrame API properly. [13:58] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:be1e6e7503b2: Merge remote-tracking branch 'qatar/master' [14:26] <{V}> https://trac.ffmpeg.org/ticket/3143 looks like the pointers s->intra_ac_vlc_length and s->inter_ac_vlc_length don't get set for h261 [15:14] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:331a90cec42f: avcodec/h261: trellis quantization support [15:14] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:459c7cb25645: fate: add h261 trellis quantization test [16:09] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:74a8fe9483ac: doc/ffmpeg: document qscale and video stream special case [16:54] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:bbe66ef91247: avutil: rename lls to lls2 [16:54] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:c3814ab654a9: rename new lls code to lls2 to avoid conflict with the old which has a different ABI [16:54] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:b382d09d29be: avutil: reintroduce lls1 as the 52 ABI needs it [17:41] <{V}> michaelni, noticed this while compiling, probably a result from the AVFrame related changes: libavcodec/qpeg.c:328:5: warning: passing argument 1 of 'avcodec_get_frame_defaults' from incompatible pointer type [17:41] <{V}> libavcodec/avcodec.h:3379:6: note: expected 'struct AVFrame *' but argument is of type 'struct AVFrame **' [17:43] <nevcairiel> luckily it shouldnt be calling that function at all anymore :) [17:48] <{V}> ah good [17:48] <nevcairiel> there is probably a bunch decoders left that need touching to be updated to the new api [20:06] <cone-904> ffmpeg.git 03Anssi Hannula 07release/2.1:b56e9beeb838: lavf/spdifdec: fix demuxing of AAC in IEC 61937 [20:06] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:5c1e9d3722db: avcodec/jpeglsdec: check err value for ls_get_code_runterm() [20:06] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:807d85400c73: avformat/thp: fix variable types to avoid overflows [20:06] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:51d1e79cc18f: avformat/thp: force moving forward [20:06] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:e40d01f45dfd: avcodec/cabac: support UNCHECKED_BITSTREAM_READER = 0 [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:8c0064798259: avformat/utils: never decrease has_b_frames in compute_pkt_fields() [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:f16751175324: avcodec/ffv1enc: Check high bpp RGB against coder type too [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:1497633924c3: h264: Do not treat the initial frame special in handling of frame gaps [20:07] <cone-904> ffmpeg.git 03Kostya Shishkov 07release/2.1:bc89c2902bdd: mpegvideo: Fix swapping of UV planes for VCR2 [20:07] <cone-904> ffmpeg.git 03Diego Biurrun 07release/2.1:425517eecbb0: mpeg12dec: Remove incomplete and wrong UV swapping code for VCR2 [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:4b846f0ccf80: ffmpeg: Do not fill gap before the first decodable frame on single stream input files unless the user explicitly requests it. [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:d89e14bf54c8: avutil: rename lls to lls2 [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:b276b913a175: rename new lls code to lls2 to avoid conflict with the old which has a different ABI [20:07] <cone-904> ffmpeg.git 03Michael Niedermayer 07release/2.1:e5e048bbf7d3: avutil: reintroduce lls1 as the 52 ABI needs it [20:26] <ubitux> BBB: do we really need to optimize the vert and horizontal intra pred? [20:27] <ubitux> http://pastie.org/8487507 some of them don't look worth the optimization [20:27] <ubitux> unless i'm missing something [20:56] <ubitux> http://pastie.org/8487548 why doesn't gcc warn for this :( [21:00] <ubitux> -Wsequence-point was supposed to warn on this [21:22] <michaelni> {V}, thx, ill fix it in a moment [21:33] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:9f630e834670: avcodec/mpegaudioenc: prevent overflow in fixed point code [21:33] <cone-904> ffmpeg.git 03Michael Niedermayer 07master:c017f15dde57: qpeg: remove faulty avcodec_get_frame_defaults() [22:26] <BBB> ubitux: yes! see h264 [22:26] <BBB> ubitux: simd makes everything faster :) [22:27] <BBB> if you really don't think it can be done faster then it's fine, but if it was done in h264, we can do it too [22:27] <ubitux> well [22:27] <ubitux> how do you make vert_4x4_c faster? oO [22:28] <BBB> check h264pred [22:28] <ubitux> 4x4 in h264 does a lot of other things [22:29] <BBB> hm, h264 doesn't optimize vert_4x4, it seems [22:29] <BBB> well maybe that can't be optimized [22:29] <BBB> dunno [22:29] <BBB> but there's 8x8, so check that [22:44] <ubitux> BBB: http://pastie.org/8487752 [22:44] <ubitux> opinion on this? [22:45] <BBB> I think that's fine... weird that we missed that [22:45] <BBB> good catch [22:45] <BBB> make sure to measure that it's faster ;) (I'd expect it to be, but always make sure) [22:46] <ubitux> will do [22:53] <iive> it might not be faster. the short version modifies mm0 and all instructions after it depend on that modification. so the instruction would be delayed in the pipeline until mm0 is finished. [22:54] <iive> in the long version it could eventually execute 4 instructions at once. [22:54] <iive> the short version could be faster in the psubw mm0,mm7 is moved up in the function body. [22:57] <BBB> iive: that's why you measure it [23:01] <ubitux> it's faster [23:02] <ubitux> i'm moving it up to see if it's even faster [23:04] <ubitux> currently: [23:04] <ubitux> 411 decicycles in ff_pred4x4_tm_vp8_8_ssse3, 8388289 runs, 319 skips [23:04] <ubitux> after my patch: [23:04] <ubitux> 389 decicycles in ff_pred4x4_tm_vp8_8_ssse3, 8388308 runs, 300 skips [23:05] <ubitux> and if moved upper (just before the lea): [23:05] <ubitux> 399 decicycles in ff_pred4x4_tm_vp8_8_ssse3, 8388295 runs, 313 skips [23:05] <ubitux> so i'll keep my version [23:05] <iive> yep. [23:12] <cone-904> ffmpeg.git 03Clément BSsch 07master:e0434cfcfcba: avcodec/x86: remove 3 sub in pred4x4_tm_vp8_8. [00:00] --- Mon Nov 18 2013

1 0

ffmpeg.log.20131117
by burek 18 Nov '13

18 Nov '13

[00:08] <pyBlob> and is it possible for ffplay to display 2 video-streams at the same time that were created from a video filter? [00:09] <Samus_Aran> pyBlob: display two how? you could load two player, I suppose [00:09] <pyBlob> ... for 3d-avis ffplay opens 2 windows, because there are 2 video streams [00:09] <Samus_Aran> didn't know you were doing 3D [00:10] <pyBlob> but I can't make it open two windows when the video filter has 2 outputs [00:10] <pyBlob> (but only 1 input) [00:11] <pyBlob> so currently I'm not using a 3d-video [00:12] <Samus_Aran> not related to 3D, but you can overlay one video on another [00:12] <Samus_Aran> you could put them side-by-side if that's your goal [00:12] <pyBlob> yes ... that would be possible [00:12] <Samus_Aran> for the colour-space conversion, use -pix_fmt [00:13] <Samus_Aran> before the output file, if you're trying to change it [00:13] <pyBlob> I need it in the video-filter [00:15] <Samus_Aran> so try putting it before that [00:16] <Samus_Aran> -pix_fmt rgb24 [00:16] <Samus_Aran> is probably what you want, not sure [00:22] <pyBlob> no, that doesn't work :/ [00:22] <pyBlob> it has to be something inside the filter [00:26] <pyBlob> I've tried "format=pix_fmts=rgb24,split[a][b];..." but it doesn't work [00:27] <Samus_Aran> I'm not sure what to suggest, I've barely touched filters. maybe someone else can help [00:49] <pyBlob> yay, crashed ffmpeg xD [00:51] <pyBlob> because ffmepg mapped a video stream into an audio stream =) [01:30] <Samus_Aran> pyBlob: how did you manage to do that? [01:31] <pyBlob> putting -map 0:a after -lavfi "..." [01:31] <pyBlob> when putting the map before the filter everything is fine ._. [01:36] <Samus_Aran> and that crashes ffmpeg, or just doesn't work as expected? [01:37] <pyBlob> it crashes ffmpeg [02:16] <Samus_Aran> lol @ this error: scale/rate is 1/0 which is invalid. (This file has been generated by broken software.) [02:16] <Samus_Aran> it was generated by ffmpeg [02:17] <Samus_Aran> ffmpeg seems incapable of cutting clips from an AAC/PCM Matroska file without completely ruining the internal time keeping [02:17] <Samus_Aran> er, AVC+PCM [02:18] <Samus_Aran> previously it gives lots of these errors: Non-monotonous DTS in output stream [02:31] <Samus_Aran> the problem has something to do with ffmpeg converting .ts to .mkv, because if I try to cut segments from the original .ts it works without timing errors [02:48] <t4nk218> <-- Running Ubuntu 13.10...can't get ffmpeg to capture video despite the codec. [02:48] <t4nk218> ffmpeg -f x11grab -r 25 -s 1920x1200 -i :0.0 -sameq /home/ken/Desktop/test.mp4 [02:49] <t4nk218> it successfully saves the file, just doesn't have any video. [02:49] <t4nk218> please tell me there is something wrong with the Ubuntu 13.10 ffmpeg default package and that a MAKE or something like that will fix it. [02:52] <JEEB> t4nk218, if you want to use the stuff that comes with ubuntu you should use the 'avconv' command [02:52] <JEEB> since ubuntu uses the libav fork, and not ffmpeg as the project [03:11] <t4nk218> JEEB, thank you. I got the same result with the avconv command. I'm not getting any errors. Could there be an issue with x11grab? [03:12] <JEEB> no idea, also libav problems should generally go to #libav :) [03:13] <t4nk218> will do..thx [04:45] <annath> Hey all. I'm trying to grab a single image from a webcam connected to a beaglebone via USB, but whenever I run the command it just kind of stops and never finishes. Here is the command I am running and the output: http://pastebin.com/nzjGCdqX Does anyone have any ideas what might be causing this? [04:46] <annath> I've left it for a few minutes there waiting for it to complete but it never does. Also, the light on the webcam turns on like it's in use. [05:02] <buu> annath: Uh, stop using avconv and use ffmpeg? [05:03] <buu> And have you verified you can read anything from that device? Are you sure its the correct device? What does strace say? [05:04] <buu> In otherwords what makes you think this is related to ffmpeg? [05:58] <davo> which ffmpeg version contained av_open_input_file function? [05:58] <davo> (if that's even a valid question) [05:59] <davo> i'm trying to build a package that needs an older version, ~0.5 - ~1.10 i think [05:59] <davo> er, 0.10 not sure [11:50] <ArtemMakhutov> Hi, I have a question about PTS/DTS in H264: [11:50] <ArtemMakhutov> I am trying to mux a raw H264 stream to a TS container. This fails with an error that the H264 stream does not contain PTS/DTS. But muxing the same stream to MKV everything works fine. Later this MKV can be reused to MUX from it to TS. [11:50] <ArtemMakhutov> Is the MKV container not using PTS/DTS? Or is this getting calculated in MKV? Why is it not possible to directly mux to TS? [12:13] <tremon> hi all, what's the most straightforward way to determine the framesize in a video file? Right now I'm using awk to parse the output of avconv -i, but I'm hoping there's a better way [12:28] <relaxed> tremon: avconv is from the #libav project. I would use awk with avprobe. [12:28] <tremon> ah, thanks. Didn't know the two projects were separate [12:36] <ubitux> tremon: note that ffprobe has more output formats [12:39] <tremon> thanks, I'll read up on it [12:43] <ubitux> tremon: stream specifier are available in ffprobe [12:44] <ubitux> tremon: http://ffmpeg.org/ffprobe.html#Stream-specifiers-1 [12:44] <ubitux> -select_streams [12:45] <tremon> lol. It doesn't reduce the confusion if questions in the one channel are answered in the other ;) [12:45] <tremon> but thanks anyway [12:45] <ubitux> i can't answer on #libav [12:45] <ubitux> i'm an evil being from the evil project [12:45] <relaxed> would it be considered poaching? [12:46] <ubitux> i'm sorry for helping users [12:47] <ubitux> tremon: [12:47] <ubitux> - ./ffprobe -v error -select_streams v:0 -of flat -show_entries stream=width,height ~/samples/matrixbench_mpeg2.mpg [12:47] <ubitux> streams.stream.0.width=720 [12:47] <ubitux> streams.stream.0.height=576 [12:48] <ubitux> i think this is what you are looking for [12:48] <ubitux> note that avprobe lacks at least 3 of the features i'm showing here [12:48] <ubitux> (stream selection, flat output, and entries filtering) [12:48] <tremon> yes, it is [13:17] <technocf> I'm having an issue with cracking using this script, http://pastebin.com/Dc5Ncdw3, and streaming to twitch with this one, http://pastebin.com/0Vux2WG4, I dont know where the issue is. [13:18] <technocf> Audio crackiling [13:18] <technocf> Also video is flashy [13:30] <technocf> I think my audio problems are to do with ffmpeg as the audio starts out good and progressively gets worse [13:32] <technocf> Is there even anyone active here? [13:33] <relaxed> -qscale 5 does nothing there [13:33] <technocf> I just copied a "perfectly working" script [13:33] <technocf> I dont do much with ffmpeg [13:33] <relaxed> I see that script at least once every two weeks [13:34] <technocf> We need a propper streaming solution, but this is all we have for now.. :/ [13:34] <relaxed> what version of ffmpeg are you using? [13:34] <technocf> ffmpeg -v ? [13:35] <technocf> ffmpeg version 0.8.9-6:0.8.9-0ubuntu0.13.10.1, Copyright (c) 2000-2013 the Libav developers [13:35] <technocf> from apt [13:35] <relaxed> ok, that is from the libav project and it's very old to boot. [13:35] <technocf> apparenly its depricated, yeah [13:36] <relaxed> well, their focus is on avconv [13:36] <technocf> E: Unable to locate package avconv [13:36] <relaxed> it's probably already installed. [13:36] <technocf> It is -derp- [13:37] <relaxed> You need to download the latest ffmpeg source and compile it with the support you need. [13:37] <technocf> Unrecognized option 'vpre' Failed to set value 'fast' for option 'vpre' [13:37] <technocf> Getting that now [13:37] <relaxed> https://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [13:37] <relaxed> follow that ^^ [13:38] <technocf> I tried to install it that way actually, I remember now.... Well I tried to but I could not for the life of me get it to compile compying it word for word so I used apt [13:39] <technocf> copying* [13:39] <relaxed> try again, I'll help if you run into an issue [13:39] <technocf> ok [13:41] <technocf> YASM installed fine [13:43] <relaxed> ubitux: how do you list which indevs an ffmpeg binary was compiled with? [13:44] <ubitux> -formats probably [13:45] <technocf> I did do: "sudo apt-get update; sudo apt-get upgrade" since I last tried [14:21] <technocf> The compile was successgul [16:15] <slorbast> Question about command line piping when using ffmpeg to chop a video up into images: Current command: http://pastebin.com/BDAjxUTU [16:17] <slorbast> My goal is to use livestreamer to get stream data, ffmpeg that stream into images that can be converted and do some image to text recognition on that all in one command instead of doing two separate [16:18] <slorbast> I'd like to just feed the image data into imagemagick, but not sure how to pipe that using those options with ffmpeg. Will I need to use like a python script to look for EOF to separate out images? [17:03] <vl4kn0> Hi, when using buffersink filter in a code, in the doc/examples there is AVBufferSinkParams structure used as a opaque parameter to avfilter_graph_create_filter. The only field that is set on that structure is pixel_fmts set to { AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE }. Is this argument required? What is it used for? Can I skip it and gain therefore support for every every pixel format? [22:21] <sly007> Why can't I join #ffmpeg-devel? [00:00] --- Mon Nov 18 2013

1 0

ffmpeg-devel.log.20131116
by burek 17 Nov '13

17 Nov '13

[00:17] <ramiro> how do I tell ffmpeg I want the input to my muxer to be interlaced? [00:45] <ubitux> BBB: hey, look where the comment above update_prob() ended up ;) [00:58] <cone-876> ffmpeg.git 03Jan Gerber 07master:f4b1ca99ff86: lavf/matroska*: DiscardPadding is a signed integer [01:12] <bernt> Howdy [01:16] <bernt> I'm seeing a discrepancy in a webm movie file relating to presentation time time codes, and the number of audio samples I'm actually pulling out of the audio decoder per second. Seems like the real average samples per second that I'm getting is higher than what the audio header is tells me (44100 samples per sec). When I measure the number of samples I get as they are spaced out between simple audio blocks... (hope that makes sense [01:18] <wm4> bernt: I think I've seen that before... [01:18] <wm4> and there was a hack in ffmpeg which fixed it [01:18] <bernt> oh? [01:19] <bernt> Hmm. [01:19] <wm4> look for trust_default_duration in the source [01:19] <wm4> that's about timestamps though [01:19] <bernt> trust_default_duration -- yeah. I'll take a look. [01:20] <wm4> some broken muxers apparently set an incorrect defaultduration, which leads to incorrect timestamps for "sub" blocks [01:20] <clever> aha, the for loop in get_pixel_format for h264_hwaccel_pixfmt_list_420 does absolutely nothing [01:20] <clever> it just fails out and calls ff_thread_get_format [01:21] <bernt> Just to be clear: What I'm doing (for sanity checking) is I keep track of the previous computed presentation time and subtract it from the currently computed presentation time, and the look at the actual samples I pulled out of the vorbis decoder. The samples over the time difference should be very very close to 44100 samples per second in theory, but it's kind of off.... over time it looks like it trends towards 44100 but I'm gett [01:22] <clever> ahhhh, get_pixel_format sends that hwaccel list to ff_thread_get_format [01:23] <wm4> bernt: your line has been cut off [01:23] <wm4> ... "over time it looks like it trends towards 44100 but I'm gett" [01:24] <bernt> wm4: sorry. Using a new irc client. Guess it sucks. :/ [01:24] <clever> 512 character max [01:24] <bernt> wm4: I wrote: over time it looks like it trends towards 44100 but I'm getting 'sloppy values' [01:25] <wm4> a matroska block contains multiple audio packets, and only the first packet has a timestamp (the timestamp for the block) [01:26] <wm4> the demuxer calculates the timestamps for the other packets from the defaultduration, which specifies how long an audio packet is [01:26] <bernt> wm4: yep. [01:26] <wm4> so if the defaultduration is wrong, you could easily get broken timestamps [01:26] <wm4> like timestamps for a different sample rate [01:26] <wm4> could this be what you're seeing? [01:27] <bernt> wm4: maybe, yeah. Let me check that trust_default_duration thing. [01:27] <wm4> that trust_default_duration was added as a hack for a single broken file [01:28] <bernt> wm4: really?! [01:28] <wm4> (frankly, I'm wondering why that mechanism is even needed... pts should just not be set for these packets) [01:28] <llogan> ramiro: what muxer? [01:28] <wm4> bernt: there was a failing sample on the bug tracker, and someone fixed it; that's what happened [01:28] <bernt> vorbis (webm) [01:31] <bernt> wm4: looks like I'm seeing the trust_default_duration in matroskadec.c (decoder) -- I'm seeing my issue in my own code / decoder (just using ffmpeg for encoding). Likely this is something I'm doing wrong myself then. [01:32] <wm4> bernt: can you share the sample? [01:32] <cone-876> ffmpeg.git 03Jan Gerber 07master:8cc59ec881b8: lavf/matroskadec ReferenceBlock is a signed integer [01:33] <bernt> yeah sure. [01:35] <bernt> wm4: http://dj2n21n35mw4x.cloudfront.net/video/0C021A8E-C006-4078-A8BC-0E83E3433… [01:36] <bernt> wm4: that's actually a wemb file. I never bothered to change it to .webm. I started out using AAC for audio, but gave up on that and went with vorbis. [01:37] <ubitux> BBB: i'm almost done isolating all the changes [01:37] <ubitux> i found something like 3-4 checks which were likely added after a fuzzing party (according to j-b) [01:38] <bernt> wm4: and by the way -- the file plays back just fine (even in my player). It's just that I'd like to do some math where I convert between samples and displayTime (fractional stuff), and I'm getting some things not to add up as expected. [01:38] <ubitux> BBB: see https://github.com/ubitux/FFmpeg/commits/vp9-merge for temporary commit extraction [01:38] <ubitux> i'll flag the relevant commit [01:39] <wm4> bernt: yeah, it doesn't seem to be the problem I suggested at first [01:39] <wm4> it doesn't even use lacing (sub-blocks) [01:40] <wm4> bernt: maybe your problem is that matroska stores timestamps in seconds [01:40] <wm4> well, nanoseconds (I think), as integers [01:40] <bernt> yes -- nanoseconds [01:40] <wm4> so maybe rounding errors? [01:41] <bernt> well... if it was rounding errors, I wouldn't see the rather large discrepencies.... let me dig a bit, and give you an example. [01:50] <bernt> wm4: maybe my debugging code is off. But for example, pts0 = 87986000000, pts1 = 88009000000, and I got 2048 frames out of vorbis over that time for an audio encoding that is supposed to be 44100 samples per sec. [01:51] <bernt> where pts{0,1} are presentation time stamps in nanoseconds. [01:53] <bernt> wm4: Wait ... I think I have a bug in my debugging code (I'm not excluding the current sample count of the current simple audio block). D'oh. Hold on... [01:55] <bernt> wm4: ok much better [01:57] <bernt> Now I'm computing much closer to 44100 samples per sec. I get maybe +/- 1 sample, but that's probably to be expected. [01:57] <bernt> sorry about that -- false alarm. Thanks for your help though ;) [01:58] <wm4> yeah, rounding errors probably [02:34] <cone-876> ffmpeg.git 03wangxingchao 07master:68900bf16bb4: avcodec: Fix duration error after seek operation [02:47] <cone-876> ffmpeg.git 03Byte 07master:d04b7de78678: avformat/rtmphttp: Partial fix for the ticket #3127 (second try) [04:35] <BBB> ubitux: re: 7a02f87... line ~440: if (!s->refs[s->refidx[0]] || !s->refs[s->refidx[1]] || [04:35] <BBB> !s->refs[s->refidx[2]]) { [04:35] <BBB> av_log(ctx, AV_LOG_ERROR, "Not all references are available\n"); [04:35] <BBB> return AVERROR_INVALIDDATA; [04:35] <BBB> } [04:35] <BBB> ubitux: so duplicate, can be removed and makes decoding slower [04:37] <BBB> my god so many cosmetics [11:23] <ubitux> 04:35:40 <@BBB> ubitux: so duplicate, can be removed and makes decoding slower [11:24] <ubitux> sorry, i don't understand [11:24] <ubitux> what do you mean? [11:24] <ubitux> btw, i'm done with all the cosmetics [11:24] <ubitux> now remaining is the file and sym split [11:24] <ubitux> your opinion on this? [11:24] <ubitux> i'm still unsure about weither i'll push the cosmetics or just pick the functionnal commits [11:28] <ubitux> oh i forgot one split [11:28] <nevcairiel> pick those cosmetics that actually make the code look better and are not stupid pedantic rule following? :p [11:29] <ubitux> nevcairiel: i'm re-doing every cosmetic manually [11:29] <ubitux> to make sure i don't miss any functionnal change [11:29] <ubitux> the split of the files is a bit a pain to track changes though, so i'm going to re-do it too [12:00] <Compn> ubitux : sounds like something diego would do. work for hours on a fix instead of working with other team [12:06] <ubitux> Compn: i wonder what you are talking about, but ok [12:08] <Compn> did you ask luca if he had the history ? [12:08] <Compn> maybe he doesnt have the history and i'm being a jerk [12:08] <Compn> some git repo somewhere with all of the cchanges seperated [12:10] Action: Compn afk bbl [12:12] <ubitux> Compn: BBB and i asked publicly for the changes, several times [12:12] <ubitux> and we got ignored [12:36] <BBB> ubitux: the piece of code I pointed at and the patch do the same thing [12:36] <BBB> ubitux: so the patch duplicates already-existing code (and thus can't possibly fix a bug) [12:36] <BBB> ubitux: no criticism of the tree, just maybe worth an annotation [12:37] <BBB> ubitux: I don't have an opinion on the cosmetics, so make a good judgement call there... if you think it's worth tracking libav's decoder in the future, feel free to apply. if not, maybe keep what we have? [15:48] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:d7ebeba80c60: ffmpeg: Do not fill gap before the first decodable frame on single stream input files unless the user explicitly requests it. [15:53] <Compn> ugh [15:53] <Compn> google finally did what they said they werent going to do [15:53] <Compn> made ad results look like real search results [15:54] <nevcairiel> still have a yellowish background for me [15:54] <Compn> oh weird [15:54] <Compn> my monitor color settings arent contrasty to see it [15:55] <Compn> but yes, i see a very very very faint yellow bg [15:55] <nevcairiel> you need a new monitor [15:56] <Compn> i need google to go back in time to 2009 , when i could still use the + operator. [15:57] <j-b> no [15:57] <j-b> I got now the no-background one [15:57] <j-b> but it alterns [15:58] <j-b> sometimes I get the low-contrast, sometimes I get the white-one-with orange "ad" [16:00] <Compn> is it when you switch from javascript to no javascript ? [16:43] <ubitux> ah shit, found some other cosmetics [16:43] <lachs0r> http://p.srsfckn.biz/raw/64/ heres a patch to make configure use pkg-config for more of the external libs and pass --static to it in a static configuration. makes shit work properly" for my mingw-w64 builds, but its untested with other configurations. [16:57] <nevcairiel> i use half of those libs and i dont have pkg-config setup, so it would break shit for me :p [16:58] <lachs0r> well that sucks [16:58] <lachs0r> I recommend setting up pkg-config then [16:58] <lachs0r> :P [16:59] <nevcairiel> nah, its fail [16:59] <lachs0r> can you explain why it is bad? [16:59] <nevcairiel> simply adding the headers and libs into a path where they are found is so much easier [17:00] <ubitux> BBB: ping [17:00] <lachs0r> yeah but it breaks on every configuration that doesnt work like what configure expects. pkg-config is there to solve that problem. [17:01] <nevcairiel> you should propose a patch then to not rely only on pkg config, because today it works fine, if it tomorrow breaks i'm not the only one thats going to complain :) [17:02] <lachs0r> well, its already doing that for a few other libs, and MOST projects are fine with the pkg-config requirement, so I dont see why not [17:05] <lachs0r> doing pkg-config checks with a fallback to the old method when its not available sounds okay, but also looks like unnecessary extra effort to mepretty much nothing else does this, and I didnt see anyone complain about that fact so far [17:06] <nevcairiel> noone complained about the lack of pkg-config for those libs either, so far :P [17:06] <cone-755> ffmpeg.git 03Clément BSsch 07master:d28c79b0035c: avcodec/x86/vp9dsp: use EXTERNAL_* macros. [17:07] <lachs0r> fair point, most people know better than to start arguing with the multimedia folks [17:07] <lachs0r> telling you the necessary compiler flags is pkg-configs job, thats why libs ship .pc files, and hence you should use it [17:14] <cone-755> ffmpeg.git 03Clément BSsch 07master:7cd555dfa54a: avcodec/vp9: make last_invisible local. [17:20] <lachs0r> I dont see how manually putting libs and headers into a path specifically so ffmpeg can find them, then trying to tell it that there are dependencies that do not automatically get resolved with static linking is any easier than just running a command that produces output which tells the compiler where shit is and which dependencies to link in static builds [18:31] <ubitux> BBB: ok i'm mostly done, i need you now :) [18:34] <wm4> oh man these ABI hacks in the ML [18:34] <wm4> it looks like these wouldn't be needed if ffmpeg stopped pretending to be a bunch of independent libraries (libavutil, libavcodec, ...) [18:35] <ubitux> i finished reversing the vp9 bomb [18:35] <ubitux> all the fixes extracted [18:35] <ubitux> need to pick them properly now [18:36] <ubitux> (BBB: "sb" is for "superblock" right?) [18:42] <ubitux> wm4: or if libav didn't break the abi ;) [18:42] <JEEB> where were all the whence flags that an aviocontext's seek function can get listed? [18:44] <wm4> JEEB: it uses the OS', like SEEK_SET [18:45] <wm4> plus AVSEEK_SIZE [18:45] Action: JEEB is "enjoying" trying to map IStream into AVIOContext [19:19] <michaelni> wm4, if you have a suggestion on how to solve the ABI issues, its very welcome. But i suspect the alternative you are thinking of would cause other problems, especially for distros that are libav based [19:43] <BBB> ubitux: yes [19:44] <BBB> ubitux: any opinion on which ones we need and which ones we don't? [19:44] <ubitux> BBB: yeah well that's what i wanted to ask [19:44] <BBB> well you have as much a vote in that as I do [19:44] <ubitux> BBB: so anyway, here is the decomposition: https://github.com/ubitux/FFmpeg/compare/vp9-merge [19:44] <ubitux> (i didn't change what you mentioned) [19:44] <ubitux> also i didn't rename a few things [19:44] <BBB> d28c79b0035c8f699be42bdf9df636edd9a78349 is fine [19:45] <BBB> 7cd555dfa54a9b9b83749977e7eec3f023ff2b36 is fine [19:45] <ubitux> yeah those 2 are pushed already :) [19:46] <ubitux> anyway, after all these commits, the diff is quite small [19:46] <ubitux> i didn't rename decode_sb and the sbits_inv [19:47] <ubitux> i didn't reindent the "tree view" of some arrays either [19:47] <BBB> MAX_PROB isn't a good idea, there's only one occurence of it, isn't there? [19:47] <ubitux> yeah [19:47] <BBB> it's sort of like MAX_UINT8_VAL [19:47] <BBB> or MIN_UINT8_VAL [19:47] <ubitux> it was just to reduce the diff, i doesn't matter i can restore ofc [19:48] <BBB> right [19:48] <BBB> so do you want to keep the cosmetics? [19:48] <ubitux> i don't know& some cosmetics might be relevant [19:48] <BBB> as in, take their patch, or keep what we have right now? or a mix of the two? these changes are incredibly bikesheddish [19:48] <ubitux> but not 7k diff like this [19:48] <BBB> like ctx vs avctx, etc. [19:49] <ubitux> maybe something like 50-100L diff [19:49] <ubitux> though, i'm not motivated to extract which ones are worth [19:49] <ubitux> i already spent too much time on this shit [19:49] <BBB> moving the avassert include up is good; typedef struct is good; ctx/avctx is comlpetely ambivalent [19:49] <BBB> right [19:49] <BBB> so maybe just not do it [19:49] <ubitux> i'd like to focus on the fixes commit [19:50] <ubitux> i re-did all the cosmetics manually [19:50] <ubitux> to see where the functionnal changes were [19:50] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/336c0ff12d7ab98d7c85cfecc48f99d93e6… [19:51] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/2626fd3047e308a91ef7f0ce98ddf79638c… [19:51] <BBB> 336... drop that, bad [19:51] <ubitux> BBB: https://github.com/ubitux/FFmpeg/commit/6da72f8ac436ed5ef1f104120cfec92a83a… [19:51] <ubitux> BBB: might not be bad after https://github.com/ubitux/FFmpeg/commit/aac9f10310f3b59eadf3689320063fecef5… [19:52] <ubitux> https://github.com/ubitux/FFmpeg/commit/e75e10ad03cb5ca4b802688696c266654a8… [19:52] <ubitux> https://github.com/ubitux/FFmpeg/commit/d53191e60c7a8676b3ea6971c57bd36b25d… [19:52] <ubitux> anyway, if you have some time to simply look at the few commits here: https://github.com/ubitux/FFmpeg/compare/vp9-merge [19:52] <BBB> aac. still does a complete check, so I don't see how that new check can ever trigger [19:52] <BBB> I need to see a file for which that is relevant [19:52] <BBB> for now, rather not [19:53] <BBB> 262... is if (boolean == true) { .. } else if (boolean == false) { .. } else { default code added by libav } [19:53] <BBB> so no [19:53] <BBB> the tree they're reading has only 4 values [19:53] <BBB> 6da72f8ac436ed5ef1f104120cfec92a83acc37d is probably ok [19:53] <ubitux> so i can replace with an av_assert0() i guess [19:53] <BBB> yes [19:53] <BBB> that would be fine [19:54] <BBB> aac... has various odd pieces to it [19:54] <ubitux> yeah sorry it's probably not well extracted [19:54] <BBB> first of all, it calls flush in update_size(), which will break scalable [19:54] <BBB> no that's not the problem, their code changes are broken [19:56] <BBB> then secondly around line 3450 (them 3430) they call " s->cur_frame = frame;" - what is frame here? [19:56] <ubitux> out_pic [19:56] <ubitux> iirc [19:56] <ubitux> it was renamed in a previous commit [19:57] <BBB> oh it's the output frame [19:58] <BBB> I see someone removed the commented out last_frame variable assignment there [19:58] <BBB> that's there for a reason [19:59] <BBB> so, the flush addition in update_size() needs to go [19:59] <BBB> we probably need to keep the commented-out last_frame assignment at the top of vp9_decode_frame [19:59] <BBB> for the rest, aac... is probably ok [20:01] <BBB> e75e10ad03cb5ca4b802688696c266654a8a5f0f is a 16bit number + 1, so it can never happen, change to av_assert0() please [20:04] <ubitux> ok [20:07] <BBB> I don't see (d53...) how size can ever go negative [20:07] <BBB> again, I think we probably just need to add an assert that size > 0 or so? [20:09] <BBB> I don't see how size can go negative, I'm looking through the code now and it seem pretty well protected [20:09] <BBB> I'd make it an assert for now [20:09] <BBB> (size >= 0) [20:10] <BBB> is that the only functional commits? [20:10] <BBB> also if you disagree with my assessments let me know, I'm by no means always correct [20:10] <ubitux> https://github.com/ubitux/FFmpeg/commit/1d30676b4acfe40de1b92fb7203edb4a8b7… this one is not really cosmetic but well [20:11] <ubitux> BBB: ok [20:11] <ubitux> i need to look better at each change actually [20:11] <ubitux> i'm a bit tired by the braindead extraction [20:11] <BBB> right, understandable [20:12] <BBB> I'd actually change that and keep the b assignment in the function (the const does some magic to the assembly, it actually always accesses it as an offset in s) [20:12] <BBB> but not give ctx, but instead s, as a function argument [20:12] <BBB> so static void decode_mode(VP9Context *s) [20:12] <BBB> remove VP9Context *s = ctx->priv_data; [20:12] <BBB> keep VP9Block *const b = &s->b; [20:12] <BBB> and then decode_mode(s); [20:13] <ubitux> interesting, ok [20:27] <cone-755> ffmpeg.git 03Martin Storsjö 07master:ab80d7e8c52d: vp9: Ensure that the arithmetic coder values are read in the right order [20:27] Action: ubitux stealing code away [20:30] <Daemon404> cherry picking unreviewed patches? [20:30] <Daemon404> how classy. [20:31] <ubitux> Daemon404: i reviewed it [20:31] <ubitux> iirc i'm somehow a maintainer of that code, because of michael's curse [20:31] <wm4> lol at this chaos [20:32] <Daemon404> first!!!! [20:32] <Daemon404> amidonitrite [20:32] <Daemon404> er [20:32] <Daemon404> amidoinitrite [20:32] <ubitux> Daemon404: it's one of the change already in libav's vp9 [20:32] <Daemon404> oh this is post merge chaos [20:32] <ubitux> i'm just picking changes, this time with correct meta [20:33] <ubitux> Daemon404: no, this change was squashed in libav commit [20:33] <ubitux> i somehow found it in a repo. [20:33] <Daemon404> yes... and i assume michael did not merge it properly [20:33] <ubitux> at least we have an explanation about that change [20:33] <ubitux> Daemon404: no, i asked him not to merge, see the merge commit. [20:33] <nevcairiel> Daemon404: he didnt merge it at all on ubitux request :p [20:33] <Daemon404> o ok [20:33] <Daemon404> lol forks. [20:33] Action: Daemon404 just popcorn.sh [20:34] <ubitux> Daemon404: we're just extracting and reviewing all the changes made [20:38] <BBB> Daemon404: as an example, https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.c;h=9048700fb79b… memcpies a struct of size [4][2][2][6][6][3] (https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.h;h=0a6c6eed4241…) to a struct of size [4][2][2][6][6][11] [20:38] <BBB> (https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/vp9.h;h=0a6c6eed4241…) [20:38] <BBB> Daemon404: these changes need review, test suite coverage of files provided by google is nowhere near 100% [20:39] <BBB> Daemon404: so many changes will silently break the decoder compared to libvpx [20:39] <BBB> Daemon404: but what do I know, after all, I know nothing about video [20:39] <BBB> compare to relevant code that I wrote: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=4978915bc… [20:40] <Daemon404> [19:39] <@BBB> Daemon404: so many changes will silently break the decoder compared to libvpx <-- if only there were some sort of document... which detailed how vp9 works... [20:40] <Daemon404> whats it called... [20:40] <Daemon404> ... a spec? [20:40] <BBB> asking the wrong person, I don't work at google [20:40] <nevcairiel> obvious code bugs dont need a spec :p [20:41] <BBB> #vp8 maybe? [20:41] <BBB> and what nevcariel says [20:41] <BBB> not understanding c is not my problem [20:41] <Daemon404> btw i wasnt saying either is right [20:41] <Daemon404> im just enjoying the chaos [20:41] <Daemon404> the lulz. [20:41] <BBB> glad you are [20:41] <Daemon404> ./popcorn [20:42] <BBB> I just find it sad [20:46] <ubitux> BBB: so, i'm on the fb removal commit; 1) the complete check (you mean the ->buf[0] for the refs right?) can be ermoved? 2) the flushing (unrefing the refs) must not be called? [20:47] <BBB> just 2, I think [20:47] <BBB> 1) is exactly what prevents that other patch you had later from not being needed (the one you're changing into an av_assert0() [20:48] <ubitux> note that in a previous commit the variable resets (which you ok'ed) were removed [20:48] <BBB> the x = null, right? [20:48] <BBB> that's probably ok, yes [20:49] <ubitux> ok [20:49] <ubitux> any idea why this change was made? [20:50] <BBB> it removes a variable, I support that's good [20:50] <BBB> more generally, it's in line with the ref/unref object management model [20:55] <ubitux> fuck that shitty isp, it's again a modem reboot period [21:10] <ubitux> BBB: so you say vp8_rac_get_tree() can never return a value outside [0;N] on a tree[N][2]? [21:22] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:6909a611d205: swscale/swscale_unscaled: fix right column handling in planarCopyWrapper [21:53] <cone-755> ffmpeg.git 03Marton Balint 07master:02b76aa3774c: ffplay: simplify early frame drop code [21:53] <cone-755> ffmpeg.git 03Marton Balint 07master:28031404571b: ffplay: calculate last frame duration from vp->pts instead of frame_last_pts [21:53] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:cee63a148352: Merge remote-tracking branch 'cus/stable' [22:32] <BBB> ubitux: it can never return a value not in the tree, if all tree tails are an enum [22:33] <ubitux> BBB: the tree contains positive and negative values [22:33] <BBB> yes, negatives are vaues, positives are branches [22:33] <ubitux> branches can be ignored then [22:33] <BBB> static const int8_t vp9_partition_tree[3][2] = { [22:33] <BBB> { -PARTITION_NONE, 1 }, // '0' [22:33] <BBB> { -PARTITION_H, 2 }, // '10' [22:33] <BBB> { -PARTITION_V, -PARTITION_SPLIT }, // '110', '111' [22:33] <BBB> }; [22:34] <ubitux> ok so let's push 2 commits for now [22:34] <cone-755> ffmpeg.git 03Clément BSsch 07master:7e704b1e109b: avcodec/vp9: add a never triggerable assert. [22:34] <cone-755> ffmpeg.git 03Clément BSsch 07master:c20a7ce62d02: avcodec/vp9: remove some reset-to-zero from vp9_decode_free(). [22:43] <ubitux> BBB: do you mind picking the fb removal patch, i'm not comfortable changing that code [22:43] <ubitux> ? [22:49] <cone-755> ffmpeg.git 03Clément BSsch 07master:484f8d77c6ec: avcodec/vp9: assert on sane size in update_size(). [22:49] <ubitux> BBB: also, what about the clipping? [22:56] <BBB> sorry, disappeared [22:56] <BBB> so [22:56] <BBB> the reason a tree can never deviate from the values of its terminals (the negatives of the <=0 values) is because those are the possible paths through the tree [22:57] <BBB> so in that tree, the only values that can occur as output are PARTITION_H/V/SPLIT/NONE [22:57] <BBB> any other value is theoretically impossible [22:57] <BBB> it's a basic tree constraint [22:57] <ubitux> ok [22:57] <BBB> I'll do the fb patch then [22:57] <ubitux> thanks :) [22:57] <BBB> not today obviously, but will get to it in a few days or so [22:57] <ubitux> ok [22:58] <ubitux> i'll start with the pred asm then [22:58] <BBB> yay [22:58] <ubitux> 'nuff on this for me [22:58] <BBB> if you want, have a look at the h264 code that jumpyshoes wrote for h264 [22:58] <BBB> it's different because the prototypes are different [22:58] <BBB> but it's comparable [22:58] <ubitux> yeah i was wondering about the factoring [22:58] <ubitux> since it was mentioned on top of vp9dsp [22:59] <BBB> I think what we have is easier [22:59] <ubitux> ok [22:59] <BBB> so I'd like to prove it's not slower and leads to simpler asm and then port h264/vp8 to it also [22:59] <BBB> but that requires asm first ;) [22:59] <ubitux> ok :) [22:59] <ubitux> btw, you're against the parameters order randomization from luca? [22:59] <BBB> yes, it's silly [23:00] <BBB> his reasoning is "kostya liked it better this way" [23:00] <BBB> well, kostya doesn't get to decide everything on this planet [23:00] <BBB> I prefer blue with pink dots [23:01] <ubitux> ok :) [23:09] <ubitux> BBB: should we split the asm just like vp8 or no? [23:10] <ubitux> it seems to lighten the macro preprocessing burden for yasm and make it faster [23:10] <ubitux> according to Diego at least [23:10] <ubitux> well, maybe we can do it when we're done anyway [23:11] <ubitux> i might start working in another asm file for the pred though [23:11] <ubitux> unless you don't think it's a good idea [23:12] <BBB> ubitux: I'm fine with it, I initially split vp9dsp.c in functionality-blocks to be able to do that [23:13] <BBB> ubitux: so we can have 1 for mc, one for intrapred, one for loopfilter, one for itxfm_add [23:13] <ubitux> > I [would] initially split vp9dsp.c [...]? [23:17] <BBB> in terms of code sections [23:17] <ubitux> no i mean, did you actually split at some point, or you're suggesting to do it? [23:17] <BBB> if you look at ff_vp9dsp_init [23:17] <BBB> I was strongly preparing for doing it [23:17] <ubitux> oh ok. [23:17] <BBB> ff_vp9dsp_init just does 4 things [23:18] <BBB> so you could split vp9dsp in 4 files, each having that init function called from ff_vp9dsp_init as entry point [23:18] <BBB> vp9dsp.asm could be split in the same way [23:18] <BBB> in fact, if you share, say, the intra pred with vp8/vp9, you'd have to do this [23:18] <BBB> since you don't want vp8 to depend on, say, vp9 mc or vp9 loopfilter [23:19] <j-b> 'morning [23:19] <BBB> that's why h264 has H264DspContext, H264PredContext, etc. [23:19] <BBB> H264QpelContext was the last one [23:19] <BBB> (couldn't think of it for a second) [23:19] <ubitux> ok [23:20] <BBB> so we could do that for vp9 also, esp. if we wanted to share some subparts of the code between vp8/vp9 or h264/vp9 or hevc/vp9 or complex combinations thereof [23:20] <BBB> e.g. the mc code can likely be shared between hevc and vp9 [23:20] <BBB> the intra pred code can likely be shared between them all [23:20] <BBB> itxfm_add is unsharable, so is loopfilter [23:21] <BBB> bilinear filter can be shared between vp8, vp9 (and h264 has its own copy of it because the function prototype is different, go figure) [23:21] <BBB> I don't know if hevc has bilinear filter [23:21] <ubitux> from someone who doesn't know a thing about loopfilter i would have say it is the most sharable thing [23:22] <BBB> nah [23:22] <BBB> devil is in the details [23:22] <BBB> I haven't seen hevc' lf but I figure it's unsharable [23:23] <BBB> mc is sharable if taps are identical [23:23] <BBB> h264 has qpel, which is weird [23:23] <BBB> hevc/vp9 have 8tap, I believe [23:23] <BBB> vp8 has 4/6tap [23:42] <cone-755> ffmpeg.git 03Anton Khirnov 07master:b068660ffa73: lavc: deprecate CODEC_CAP_NEG_LINESIZES [23:42] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:ec9aef565291: Merge commit 'b068660ffa73f226cc03a67e214b8540fc1e11c4' [23:43] <cone-755> ffmpeg.git 03Anton Khirnov 07master:2ff302cb6ba1: lavc: update coded_frame doxy. [23:44] <cone-755> ffmpeg.git 03Michael Niedermayer 07master:571a99de186e: Merge commit '2ff302cb6ba1f159905888026c8a1d7dd8319acf' [00:00] --- Sun Nov 17 2013

1 0

ffmpeg.log.20131116
by burek 17 Nov '13

17 Nov '13

[01:10] <jure> can I normalize audio with ffmpeg? [01:18] <jure> say "ffmpeg -i input.wav -af normalize=0.0 -o n.wav" to normalize the amplitude to 0db [01:31] <llogan> jure: see tools/normalize.py although ive never tried it [02:13] <ussher_> is it possible to record the pulse monitor and the pulse default (mic) via ffmpeg options? here is what I have now, but its either mic, OR system sounds. http://pastebin.com/MfGUheFn [11:01] <LithosLaptop> How do I get ffmpeg to accept multiple images as input that are not in a sequence? [11:01] <LithosLaptop> a whole folder [11:01] <LithosLaptop> ffmpeg without glob support [11:11] <LithosLaptop> hmm the wiki isn't helping :( [11:12] <LithosLaptop> another problem is I want to the output to be 1920x1080, but the aspect ration still need to be kept [11:12] <LithosLaptop> so I need to add black bars top/bottom or right/left [11:13] <LithosLaptop> I tried this as suggested in the wiki: https://trac.ffmpeg.org/wiki/Scaling%20%28resizing%29%20with%20ffmpeg [11:13] <LithosLaptop> -vf scale="'if(gt(a,16/9),1920,-1)':'if(gt(a,16/9),-1,1080)'" [11:14] <LithosLaptop> but then I get 1613x1080 on one of the images and ffmpeg bombs out with: [libx264 @ 026d74e0] width not divisible by 2 (1613x1080) [11:14] <LithosLaptop> just want it to add blackness so that it reaches 1920x1080 [11:28] <LithosLaptop> ok so I know it will either be 1920xsomething or somethingx1080 after scaling but how do I automatically add borders so that the output is 1920x1080? [11:29] <LithosLaptop> it seems to be easy if I actually know the resolution of the source or what the scaled resolution will be [11:35] <diesel420> nobody like black bars [11:37] <LithosLaptop> umm lol thats not the answer I was expecting [11:38] <LithosLaptop> nobody likes stretching [11:38] <LithosLaptop> :) [11:43] <diesel420> i cant help, sorry. you want create a video slideshow from several images with different resolutions? [11:45] <LithosLaptop> yep [11:46] <LithosLaptop> ok found something that works :) [11:46] <LithosLaptop> scale='gte(iw/ih\,1920/1080)*1920+lt(iw/ih\,1920/1080)*((1080*iw)/ih):lte(iw/ih\,1920/1080)*1080+gt(iw/ih\,1920/1080)*((1920*ih)/iw)',pad='1920:1080:(1920-gte(iw/ih\,1920/1080)*1920-lt(iw/ih\,1920/1080)*((1080*iw)/ih))/2:(1080-lte(iw/ih\,1920/1080)*1080-gt(iw/ih\,1920/1080)*((1920*ih)/iw))/2:black' [11:46] <diesel420> congrats [11:50] <LithosLaptop> lol the encoded file only shows black [11:50] <diesel420> :/ [11:55] <LithosLaptop> I've got an idea :) [11:55] <LithosLaptop> bbl [12:06] <vl4kn0> Hi, I have fps filter successfully setup, but I can't find how to use it in the application. Is the video stream automatically filtered or do I need to do the filtering myself? [12:15] <ac> hello, I would like to make a screencast *with audio*, to record video games, and every time I try, I get distorted audio (like if the track was played slower). I've tried different versions of ffmpeg, different audio recording options, it doesn't change anything. I've seen many people on the forums/mailing-lists with the same problem, but no solution. [12:16] <ac> I'm on debian, btw, and I use pulseaudio because there's no way to record audio with alsa apparently [12:19] <ac> ffmpeg version is 2.1 from deb-multimedia, but I have the same problem with 1.2.4 [12:20] <Ozzapoo> Hi. Can someone please help me? I'm not sure what's wrong... http://pastebin.com/0gvTryFt [12:21] <Ozzapoo> I'm piping raw h264 output from my webcam to ffmpeg in this [12:33] <Ozzapoo> Doh. It's because I didn't create the directory for the segments [12:33] <Ozzapoo> it works now! [12:33] <Ozzapoo> :D [12:52] <ac> aaaaaaaaand it magically works [12:52] <ac> aaaaaaaaaaand it magically doesn't work again [12:55] <davo> i'm trying to build a package from source (opencv-2.2.0) that needs ffmpeg, not sure which version, I've tried 0.5.x to 0.8.10, but they all die at "cap_ffmpeg.cpp:419:52: error: av_open_input_file was not declared in this scope" [12:56] <davo> any idea what version ffmpeg i need to compile this version of opencv [12:56] <davo> (just thought i'd ask here #opencv is a little sleepy atm) [12:57] <davo> thanks in advance [13:02] <ac> ok, speculation 1 : it works on first launch after reboot /o\ [13:03] <ac> great [14:41] <vl4kn0> Is here anyone who could help me get my filtering right (programatically using libavfilter)? [14:43] <Compn> vl4kn0 : ask on mailing list yet ? [14:43] <Compn> vl4kn0 : saste might know :) [14:43] <vl4kn0> Compn: haven't asked on mailing list, might give it a shot [16:03] <Bombo> is it possible to mux foo.mp4 + foo.sub + foo.idx into one foo.mkv? (vobsub subtitles) [16:06] <Compn> you guys and your vobsub subtitles [16:06] <Compn> try mkvmerge ? [16:06] <Compn> ehee [16:06] <Compn> vobsubs may also work [16:08] <sacarasc> Or OCR them. :D [16:09] <Bombo> hm ;) [16:13] <Compn> download the text version from opensubtitles.org [16:32] <ubitux> Bombo: yes it's possible [16:33] <ubitux> ffmpeg -i foo.mp4 -i foo.idx -map 0 -map 1 -c copy out.mp4 [16:33] <ubitux> ffmpeg -i foo.mp4 -i foo.idx -map 0 -map 1 -c copy foo.mkv [16:33] <ubitux> sorry :) [16:33] <ubitux> assuming supported codecs [18:11] <Bombo> ubitux: ah indeed, works ;) [18:12] <ubitux> :) [18:12] <Bombo> needed to add more -map magic [18:12] <ubitux> make sure you use git head though, i fixed some stuff in vobsub recently, which i didn't backport yet [18:12] <Bombo> got two audio streams, two sub streams [18:13] <Bombo> yep, used a recent win build [18:14] <Bombo> on my linux box i guess i have to compile myself a recent git version [18:14] <vl4kn0> How can I get % of frames decoded? [18:15] <Bombo> i'm still missing an ETA: while encoding... why isn't that included yet? [18:15] <Bombo> x264 got a nice ETA ;) [18:16] <Bombo> ffmpeg version N-57996-gdd3d0f4 Copyright (c) 2000-2013 the FFmpeg developers built on Nov 9 2013 18:07:24 with gcc 4.8.2 (GCC) [18:17] <Bombo> ubitux: recent enough? oh you added the vobsub support, thx then ;) [18:18] <ubitux> vobsub demuxing is in ffmpeg since a while, but i fixed some bugs in the demuxer "recently" [18:18] <ubitux> (one month ago or so) [18:19] <Bombo> seems to work [18:20] <Bombo> but switching between subs and or audiostreams in vlc, makes it a little asynched, but its probably vlc's fault [18:24] <ubitux> try mpv ;) [20:13] <Samus_Aran> anyone know of any AAC encoders that can handle 24 or 32bit audio? libfdk_aac can only handle 16bit audio, not DVD or Blu-Ray quality. though it can handle 96KHz sampling rate. [20:17] <LithosLaptop> Samus_Aran: AAC is a lossy codec; sound quality usually is the goal not sampling rate and bit depth [20:18] <LithosLaptop> perceived audio quality [20:25] <LithosLaptop> Samus_Aran: libfdk_aac is the best AAC encoder you can use with ffmpeg; the other encoders give worse sound quality. If you don't need to use ffmpeg then you can also try Apple's AAC encoder [20:34] <JEEB> just fyi [20:34] <JEEB> AAC has no "bit depth" [20:34] <JEEB> no lossy format in general has a concept of "bit depth" [20:35] <JEEB> (this is shown in libavcodec by the fact that most if not all lossy decoders output float by default) [20:53] <Samus_Aran> JEEB: meaning it uses arbitrry precision based on available bitrate? [20:54] <Samus_Aran> I guess I'm trying to figure out why Blu-Ray is advertised as 96KHz 24bit if there's no bits with AAC [20:55] <JEEB> because blu-ray tends to have lossless formats in there? [20:55] <Compn> dont tell him secrets [20:55] <JEEB> and that sounds like the maximums of sort [20:55] <JEEB> lol [20:56] <Compn> Samus_Aran : the answer is marketers are liars [20:56] <Samus_Aran> I thought most Blu-Ray discs used AVC+AAC, I guess I was mistaken [20:56] <JEEB> lol [20:56] <JEEB> I'm not sure if AAC is even in the specification :P [20:56] <JEEB> there are some lossy formats in the spec as far as I can remember [20:57] <JEEB> but generally DTS/AC3 if I recall correctly [20:57] <JEEB> anyways, those are probably raw PCM maximum "specs" :P [20:57] Action: LithosLaptop wonders if there has been somebody yet to hear a difference between 44.1KHz 16 bit and 96KHz 24bit audio [20:57] <LithosLaptop> :) [20:58] <LithosLaptop> they put 96KHz 24bit on Blu-Ray, because 'why not'. not because it is audibly better [20:58] <JEEB> yup [20:59] <JEEB> and since most stuff is created as 48kHz, 16bit, that's what most discs have in one way or another [20:59] <Samus_Aran> if this was for my own usage, I would be using uncompressed PCM, but I'm trying to oversample the audio as much as possible for when YouTube murders it [21:00] <Samus_Aran> uploading greater than 1080p video, or very high bitrate 1080p, seems to help the audio a lot [21:01] <LithosLaptop> yeah because for 1080p Youtube uses a higher bitrate for the audio [21:01] <Samus_Aran> the source is AC3 audio, which I can't use in the .mp4 for YouTube, so it's getting re-encoded multiple times. [21:02] <Samus_Aran> so trying to preserve as much of the quality during this ugliness [21:02] <LithosLaptop> uncompress it to PCM 16bit, 48Khz and mux that in a AVI container [21:03] <LithosLaptop> then upload the AVI [21:03] <Samus_Aran> I didn't think h.264 in AVI was very standard? if YouTube accepts that, sounds like a plan [21:03] <LithosLaptop> when I tried I couldn't get Youtube PCM in MKV container [21:04] <LithosLaptop> only AVI seemed to work [21:04] <LithosLaptop> but you might have better success [21:04] <Samus_Aran> I can't believe how crappy mp4 containers are, they can barely handle any formats. PCM is pretty basic. [21:08] <Samus_Aran> it would be nice if YouTube supported all the open formats like MKV, FLAC, Ogg, Opus, Vorbis, etc. [21:09] <LithosLaptop> I see FLV supports LPCM, so maybe you can try to mux the PCM and H.264 in a FLV and upload that to Youtube [21:10] <LithosLaptop> ,but I am not sure what container formats Youtube will accept [21:11] <LithosLaptop> Youtube does support uploading Vorbis btw [21:12] <LithosLaptop> Iv'e done it before as long as it is in a webm container [21:14] <Samus_Aran> I was noticing VP8 and Vorbis in webm. does webm support h.264 video? [21:15] <Samus_Aran> anyhow, thanks for the tips, lots to try out now. :) [21:15] <Samus_Aran> hopefully I can save one re-encode [21:18] <LithosLaptop> does webm support h.264 video? <--- nope. only VP8 and Vorbis. In the *near* future it will support VP9 and Opus [21:18] <LithosLaptop> no prob [21:26] <ubitux> near? [21:26] <ubitux> you can already [21:43] <AnywhereIs> it seems like a trivial question but i can't cut a section out of my video. like, i need 154 seconds of it beginning from 30 second of input file. it goes well but on the output i get a video half-broken, causing lags and mplayer producing the following errors: http://dpaste.com/1467508/ [21:43] <AnywhereIs> the command i use is ffmpeg -ss 00:00:30 -t 00:02:34 -i DSC_0217.mkv -acodec copy -vcodec copy -y DSC_0217_cutn.mkv [21:44] <sarthor> ffmpeg -i Lecture-4-Day3.avi -acodec libfaac -b:a 128k -vcodec mpeg4 -b:v 1200k -flags +aic+mv4 Lecture-4-Day3.mp4 not working for me. [21:44] <sarthor> Unknown encoder 'libfaac' [21:46] <AnywhereIs> i hope it doesn't mean i have to re-encode the entire file to simply cut a few seconds here and there? [21:49] <LithosLaptop> sarthor: you don't have your ffmpeg configured correctly to use libfaac [21:49] <Samus_Aran> AnywhereIs: it should work with ffmpeg. are there any errors output? another option is to try mkvtoolnix and see if mkvmerge has the same issue [21:50] <Samus_Aran> AnywhereIs: are you using a recently compiled ffmpeg? [21:50] <Samus_Aran> or your distro's version? which distro, which version of ffmpeg? [21:50] <AnywhereIs> Samus_Aran: ffmpeg does not produce any errors while doing it. i'm not sure if it's recent though. gentoo. [21:50] <AnywhereIs> i'll try building a newer one [21:50] <sarthor> LithosLaptop: How to configure ffmpeg for flibfaac? [21:51] <Samus_Aran> I was told there are improvements in the cutting of video segments in the more recent versions, so it would be worth try [21:51] <Samus_Aran> *trying [21:51] <LithosLaptop> sarthor: I am not sure. I always use precompiled ffmpeg win32 binaries :) [21:51] <AnywhereIs> Samus_Aran: it's 1.0.5 built on Mar 28 2013 21:56:28 [21:51] <LithosLaptop> sarthor: but libfaac is a really bad AAC encoder anyway, check if libmp3lame works [21:52] <Samus_Aran> AnywhereIs: definitely worth updating [21:52] <AnywhereIs> Samus_Aran: are CLI options the same? [21:52] <Samus_Aran> AnywhereIs: yes [21:52] <AnywhereIs> i'll give it a shot [21:53] <Samus_Aran> ffmpeg has pretty active development, so 8 months can make a difference. :) [21:53] <LithosLaptop> AnywhereIs: try using .ts output instead of .mkv and see if you also get the same errors. not sure what codecs your source has though; might be incompatible with .ts [21:54] <AnywhereIs> it was x264 dual-pass from h264 huge raw from camera [21:54] <Samus_Aran> the latest version from git is recommended. not sure if that's what Gentoo uses automatically [21:55] <AnywhereIs> costed hell lot of a time to reencode it (so as to shrink) [22:00] <AnywhereIs> m, converting to .ts worked but i lost sound (flac) [22:01] <AnywhereIs> i used ffmpeg -i DSC_0217.mkv -c copy -bsf h264_mp4toannexb 1.ts [22:02] <AnywhereIs> and then cut on 1.ts and then again to mkv. vid was ok but sound was lost [22:02] <Samus_Aran> you could use -codec:a pcm_s16le [22:02] <Samus_Aran> to losslessly dump the flac to pcm [22:02] <AnywhereIs> it will be stored in .ts right? [22:03] <Samus_Aran> yes. I'm not sure what the final goal is, but that wouldn't lose any quality [22:03] <AnywhereIs> heh, now the cutting does not work [22:04] <AnywhereIs> ffmpeg -i DSC_0217.mkv -c copy -bsf h264_mp4toannexb -codec:a pcm_s16le 1.ts [22:04] <AnywhereIs> works okay [22:04] <AnywhereIs> um, but mplayer 1.ts does not play any audio as well [22:05] <AnywhereIs> from 1.ts [22:05] <LithosLaptop> hmmm [22:05] <Samus_Aran> I've only used .ts files to convert to other formats [22:05] <Samus_Aran> don't know much about it [22:05] <AnywhereIs> yeah, i know that, i'm just testing if it's there [22:05] <AnywhereIs> and it appears it isnt [22:05] <Samus_Aran> ffprobe file.ts [22:06] <Samus_Aran> does it list both tracks? audio/video [22:06] <AnywhereIs> writes me loads of errors about ... AAC? [22:06] <AnywhereIs> (the input file DSC_0217.mkv is x264 and flac) [22:07] <Samus_Aran> I'm not sure why it would be using AAC if it was FLAC -> PCM [22:07] <AnywhereIs> ffprobe: something like this http://dpaste.com/1467549/ [22:07] <Samus_Aran> were you able to get a more recent ffmpeg compiled? [22:07] <AnywhereIs> is it something wrong with my command? [22:07] <AnywhereIs> not yet, i was thinking i might work this out with .ts [22:08] <AnywhereIs> > ffmpeg -i DSC_0217.mkv -c copy -bsf h264_mp4toannexb -codec:a pcm_s16le 1.ts # is the one i used and it produced no errors [22:08] <Samus_Aran> AnywhereIs: even the output suggests you update your ffmpeg to the latest git version. :p [22:08] <AnywhereIs> yea [22:08] <AnywhereIs> but output suggests audio is there Stream #0:1 -> #0:1 (flac -> pcm_s16le) [22:09] <AnywhereIs> video:165590kB audio:36318kB subtitle:0 global headers:0kB muxing overhead 8.313068% [22:09] <AnywhereIs> on the other side ffprobe tells me Stream #0:1[0x101](eng): Audio: aac ([6][0][0][0] / 0x0006), 12 channels (FL+FR+FC), s16, 187 kb/s [22:10] <AnywhereIs> i hope it eventually works with newer one but it costed me hours to compress the video [22:10] <Samus_Aran> maybe .ts doesn't take PCM [22:11] <Samus_Aran> you won't lose your video [22:11] <AnywhereIs> yep i just may have to rebuild it [22:11] <Samus_Aran> just update to the latest and you should be able to remux it fine [22:12] <Samus_Aran> if that doesn't work, try mkvmerge [22:15] <AnywhereIs> lol. surprisingly enough it seemd to had work lol [22:15] <AnywhereIs> never would have thought it will. [22:15] <AnywhereIs> usually software updates just fail me [22:18] <AnywhereIs> thanks for advices Samus_Aran LithosLaptop [22:40] <Samus_Aran> AnywhereIs: glad it's working [22:40] <Samus_Aran> I just noticed that my updated ffmpeg is having problems cutting segments from a .ts to an .mkv [22:40] <Samus_Aran> it worked with the static ffmpeg I downloaded, but not with the git I compiled [22:41] <Samus_Aran> [matroska @ 0x35ad260] Can't write packet with unknown timestamp av_interleaved_write_frame(): Invalid argument [22:41] <AnywhereIs> i used non-git version [22:41] <AnywhereIs> it's 1.2.4 [22:41] <AnywhereIs> but i didnt test it with .ts [22:41] <AnywhereIs> it just worked out with mkv to mkv [22:44] <Samus_Aran> I think there is a problem with today's and yesterday's git, as the static builds are incomplete (0 bytes) [22:45] <Samus_Aran> I followed my own advice and now I can't cut mkv. :p [22:48] <AnywhereIs> that's what you get when updating, especially to unstable repos [22:52] <AnywhereIs> Samus_Aran: CC0/WTFPL what i've just been working on (yt recodes it and it's not yet finished in HQ), https://www.youtube.com/watch?v=_KPNYX6kpEY and a channel about nothing in particular lol. [23:02] <Samus_Aran> AnywhereIs: nice shot. I expected Nessie (Loch Ness creature) to surface. :p [23:02] <AnywhereIs> :> [23:03] <Samus_Aran> reminds me of the song "smoke on the water" [23:03] <AnywhereIs> it was just a morning after a night of meteor rain in august, i came down to a lake and saw this awesome fog, couldn't resist shooting it [23:04] <Samus_Aran> it made me miss swimming and playing in a tidal slough as a kid [23:05] <Samus_Aran> high tide you could swim, low tide was huge mud flats. fun as a kid. :) [23:49] <Samus_Aran> muxing mkv is broken in the latest git. the 2.0.x static release works fine [23:50] <Samus_Aran> but my git compile is broken, and the static git compile from 2 days ago is also affected. [23:54] <klaxa> f-file a bugreport? [23:54] <pyBlob> Hello =) [23:55] <pyBlob> I'm trying to specify a video filter on command line, how can I convert a yuv-stream to an rgb-stream, so I can apply a blend-filter on the rgb-stream? [23:56] <Samus_Aran> klaxa: m-maybe l-l-later. too busy atm. [00:00] --- Sun Nov 17 2013

1 0

ffmpeg-devel.log.20131115
by burek 16 Nov '13

16 Nov '13

[07:43] -:#ffmpeg-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp [09:13] <pigoz> [Als [10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:5d8619595b84: lavd/xv: simplify write_packet [10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:57bca5a2b613: lavd/xv: add more supported formats [10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:995f450b44be: lavd/xv: free resources on errors [10:24] <ubitux> oh wow [10:24] <ubitux> BBB: did you look at the diff to the vp9 decoder? [10:24] <ubitux> they are not trivial [10:24] <ubitux> at all [10:26] <ubitux> there are a lot of functionnal changes hidden in the cosmetics ones [10:26] <nevcairiel> they love doing that [10:28] <ubitux> and they split the files, so it makes diffing much harder [10:28] <ubitux> i see some clipping added [10:30] <ubitux> ...and they're going to push it [10:31] <plepere> ok, I'm sorry, but I need some assembly help again. :( [10:31] <ubitux> plepere: this is what this channel is for :p [10:32] <ubitux> BBB: http://lucy.pkh.me/vp9diff.html [10:33] <plepere> http://pastebin.com/0azLQNBZ [10:33] <plepere> bit depth is set to 8 for the asm, so the shift is set to 6. [10:34] <plepere> I think my problem is that dst is a int16* and not int8 [10:34] <nevcairiel> asm doesnt have types [10:34] <ubitux> plepere: you're not doing any simd? [10:35] <plepere> ubitux, I have a SIMD version, but it doesn't work, so i told myself "just stick with loops going 1 by 1" [10:35] <ubitux> [libav-commits] lavc: VP9 decoder [10:35] <ubitux> aaaaand it's pushed [10:37] <plepere> nevcairiel, I can't get movb and movq working [10:38] <nevcairiel> anyhow your plain mov will move native sized values i assume, so you would need to use fixed-size movs that match the value sizes [10:39] <nevcairiel> src is 8-bit and dst is 16? [10:39] <plepere> yes [10:42] <plepere> http://pastebin.com/kiJGSjTu for the full code with the commented SIMD [10:43] <nevcairiel> http://pastebin.com/5EdwQ5De [10:43] <nevcairiel> i made 3 modifications, i think that may be better [10:44] <nevcairiel> it loads only 8-bit using the r9b syntax, writes only 16-bit using r9w, and the dst address calculation was adjusted for 16-bit [10:44] <plepere> I see the r9b and r9w yes [10:46] <plepere> and the 2*r7 for the 16bit [10:46] <nevcairiel> yeah, because it has twice the number of bytes [10:46] <plepere> the image looks better [10:46] <nevcairiel> correct better, or just better? :d [10:47] <plepere> just better [10:47] <plepere> but it's a good thing ! [10:48] <nevcairiel> is that unsigned or signed numbers? [10:48] <nevcairiel> for signed, might need to use sign-extension [10:48] <plepere> uint8 and int16 [10:56] <nevcairiel> i think your simd would work as well, just needs adjustments to the address calculation [10:57] <nevcairiel> so just add the *2 in the dst address like in the normal asm [10:57] <plepere> nope [10:57] <plepere> my intrinsics code is : [10:57] <plepere> x1 = _mm_loadu_si128((__m128i *) &src[x]); [10:57] <plepere> x2 = _mm_unpacklo_epi8(x1, x0); [10:57] <plepere> x2 = _mm_slli_epi16(x2, 6); [10:57] <plepere> _mm_storeu_si128((__m128i *) &dst[x], x2); [10:58] <nevcairiel> well C code handles the addresses automatically because of the variable types, you dont have that in asm [10:58] <plepere> yes. [10:59] <plepere> when using the asm with SSE, I put 2*r7 [10:59] <plepere> but there are still errors [11:01] <plepere> hmmm [11:01] <plepere> could it be because dststride and srcstride are ptrdiff_t types in C ? [11:02] <nevcairiel> thats fine, ptrdiff_t always maps to native register size [11:24] <ubitux> i should have fwd this to ffmpeg-devel: https://lists.libav.org/pipermail/libav-devel/2013-November/053159.html [11:45] <ubitux> oh wow they really skipped a lot of fixes [11:45] <nevcairiel> they didnt pull any fixes since the original patch [11:45] <ubitux> :') [11:49] <nevcairiel> i just hope merging doesnt revert the fixes [11:50] <ubitux> they changed parameter ordering in vp9dsp [11:51] <ubitux> they're gonna have fun backporting optimized code [11:51] <nevcairiel> maybe it should just not be merged at all :p [11:51] <ubitux> yeah but it looks like there are some fixes [11:51] <ubitux> some i'm gonna dig a bit [11:52] <j-b> there are some security fixes in libav commit of VP9, if you are speaking about that. [11:52] <ubitux> j-b: i found one, fixed differently [11:53] <ubitux> j-b: can you point them out? [11:53] <ubitux> or this is a secret? [11:53] <j-b> I don't remember [11:53] <ubitux> great [11:53] <j-b> I saw vectors crashing [11:54] <j-b> through a lot of fuzzing [11:54] <nevcairiel> report them to the authors of the decoder then [11:54] <nevcairiel> :) [11:55] <j-b> This will get even more ugly as time passes [11:55] <ubitux> j-b: no [11:55] <ubitux> we will find those fixes, i'll likely take my week end on this merge [11:56] <ubitux> but i'm not going to backport the cosmetics [11:56] <j-b> no, I mean, as major decoders arrive, it will get more and more ugly [11:56] <j-b> and people will choose the fork depending on VP9 and H265 speed [11:56] <ubitux> ah then that's a good news. [11:57] <ubitux> michaelni: please don't backport anything from the vp9 bomb (just metadata) [11:57] <ubitux> i'll look into it this week end [11:58] <j-b> diff | git apply [11:58] <ubitux> no [11:58] <ubitux> we have a lot of fixes they don't have [11:58] <ubitux> as well as optim actually [12:04] <ubitux> btw, still no answer on the debian thread? [12:08] <cone-827> ffmpeg.git 03Alex Sukhanov 07master:86b3435fc010: af_aresample: Fix timestamp of first padded PCM audio packet [12:09] <michaelni> ubitux, ok about vp9, ill leave it to you [12:10] <ubitux> i hope BBB will be available too though :) [12:17] <JEEB> long thread is long indeed [12:24] <cone-827> ffmpeg.git 03Diego Biurrun 07master:e8fcdebb17fc: build: Allow specifying extra object files when linking HOSTPROGS [12:24] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:3e78ceadf913: Merge commit 'e8fcdebb17fc59375fd9fc6c0a02a1d2e6d9fb23' [12:34] <ubitux> 12:34:30 <+j-b> JEEB: yeah, why can't they merge it? [12:35] <ubitux> j-b: my question exactly: https://trac.ffmpeg.org/ticket/2686#comment:226 [12:35] <JEEB> yup [12:35] <JEEB> noted that :) [12:37] <j-b> you meant encoder? [12:38] <ubitux> j-b: fixed [12:41] <BBB> ubitux: so ... do we want these changes? [12:42] <BBB> it sounds to me like we don't [12:49] <iive> if it is about the aac encoder. there is no reason to keep them away. Who knows maybe in time it could get enough polish. [12:51] <j-b> "also the patch should be split into self contained fixes, 1 issue == 1 patch when its submitted to ffmpeg-devel." lol [12:55] <ubitux> BBB: there are some fixes [12:55] <ubitux> and i want to make sure we don't miss any [12:57] <cone-827> ffmpeg.git 03Diego Biurrun 07master:3cbe11265304: dv: Split DV data table declarations into their own header [12:57] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:e28130bcaf48: Merge commit '3cbe1126530449336e2ce59b194bdb8c4eb4abb4' [13:05] <Compn> j-b : you want to mix cosmetics patch with feature patch ? :P [13:05] <j-b> I want a working encoder for AAC that does not suck bollocks [13:06] <BBB> ubitux: but this is really hard to review if there's 10 fixes with 1000000000 cosmetic changes and file moves, plus no reason for each individual change (like: is there a sample that this applies to?) [13:12] <Compn> j-b : lol you see michaels second comment ? [13:12] <Compn> right under 1 patch 1 issue [13:12] <Compn> We can apply a huge monolithic patch too if thats the only option but it will give everyone working on aac headaches (that is you all) when theres a regression and git bisect then ends up just pointing to a huge all in one change. [13:13] <Compn> if you're for it, just say that [13:13] <durandal_1707> where? what? [13:14] <ubitux> BBB: i will extract every change [13:14] <Compn> epic 228 comment aac encoder trac ticket [13:14] <Compn> durandal_1707 [13:15] <ubitux> BBB: my plan is to re-do the cosmetics patches and extract the functionnal changes in separate patches [13:15] <ubitux> then we will pick the relevant functionnal changes [13:15] <ubitux> and we will not apply the cosmetics ones [13:16] <ubitux> (unless you want them) [13:18] <durandal_1707> merge merge merge [13:18] <Compn> i would think luca would commit with history , but i guess i dont know libav development rules on such things [13:21] <ubitux> Compn: well, don't remember with ffv1? [13:21] <ubitux> they picked dozens of commits, squashed them, cosmetics them and pushed it [13:21] <ubitux> trashing in the process the relevant history [13:22] <BBB> ubitux: well I don't care either way about the cosmetic changes; I'm intruiged by the functional changes, similar to your email - why? [13:22] <BBB> ubitux: without a why, it's hard to apply a functional change [13:22] <ubitux> yes, but i'll start by isolating all of them [13:22] <ubitux> so we can have a better overview [13:22] <JEEB> I remember you asking it on IRC as well, and to be honest I'm surprised you didn't get an answer [13:23] <ubitux> surprised? :)) [13:23] <ubitux> come on, it happens all the time [13:23] <BBB> JEEB: I asked 20 times [13:23] <BBB> JEEB: I get no answer [13:23] <JEEB> yeah [13:23] <JEEB> yes, very unpleasantly surprised. There have been some derps at libav, but that's on pretty bad level [13:23] <BBB> JEEB: figures why I don't want anything to do with the forkifork business anymore [13:24] <BBB> I didn't do this to make things worse [13:25] <BBB> ubitux: moving last_frame_invisible out of VP9Context is ok, I think (I remember why I added it in, but since then I moved that information into s->use_last_frame_mvs, we don't need it anymore) [13:25] <ubitux> ok [13:29] <Compn> ubitux : i try not paying attention :) [13:30] <Compn> but no i didnt know that about ffv1 , thats sad :( [13:31] <iive> libav is in stagnation and decline. but it would take a few more years until it reaches a breaking point. [13:32] <ubitux> Compn: http://git.libav.org/?p=libav.git;a=commit;h=0f13cd3187192ba0cc2b043430de6e… [13:36] <Compn> iive : you reading ohloh stats again ? :P [13:36] <Compn> ubitux : the real question is why do they smush author tag ? [13:36] <iive> i can't recall what ohloh is... sounds familiar... [13:36] <Compn> maybe patch author = author to them [13:37] <ubitux> Compn: "Based on code from Carl Eugen Hoyos, Michael Niedermayer and Paul B Mahol." [13:37] <ubitux> all the code is modified by cosmetics [13:37] <ubitux> so he took authorship i guess [13:37] <iive> ohloh.net ? [13:40] <BBB> 'sb' does not stand for 'subblock' btw [13:40] <BBB> that's funny [13:40] <mateo`> iive: it summarizes your open source contributions (but you have to add the projects you're working on manually) [13:41] <mateo`> iive: so you can compare with others, see who has the biggest one :D [13:42] <ubitux> BBB: http://lucy.pkh.me/vp9diff2.html [13:42] <ubitux> this is the block diff part [13:42] <ubitux> gonna add the dsp one while at it [13:44] <ubitux> BBB: and here is the dsp one: http://lucy.pkh.me/vp9dspdiff.html [13:45] <iive> the problem with each kind of metric, is that diego can fake it :) [13:45] <ubitux> BBB: note how they changed the parameter ordering [13:51] <BBB> I objected to that several times [13:51] <BBB> but their problem, the simd won't always work [13:51] <ubitux> they didn't pick it yet [13:52] <ubitux> at least not all [13:52] <BBB> const removal is bad in decode_coeffs [13:53] <ubitux> any idea why it was done? [13:53] <BBB> can you diff the header also? [13:53] <ubitux> ok [13:53] <BBB> I added it later, when I made these table-tables const [13:53] <BBB> they probably missed that patch [13:53] <BBB> (i.e. some tables don't live in rodata for them) [13:54] <ubitux> ah i see [13:54] <ubitux> the header is "empty" (just a few extern) [13:54] <ubitux> everything is in a .c [13:55] <ubitux> BBB: http://lucy.pkh.me/vp9datadiff.html [13:55] <ubitux> (.h against .c) [13:56] <ubitux> ahaha i was sure they would break the hierchical indent [13:56] <nevcairiel> they probably thought it was just bad indent [13:56] <nevcairiel> they dont think about such things [13:56] <ubitux> i think they know [13:57] <ubitux> but "it's better to be consistent than pragmatic" [13:57] <nevcairiel> diego also has a thing against tables in headers, so thats why it was moved probably [13:58] <ubitux> was it ever duplicated? [13:58] <ubitux> we can prevent duplicated include easily btw [13:58] <ubitux> if that's the problem [13:59] <ubitux> #ifdef AVCODEC_VP9DATA_H #error ... on top of those include-once-header should do [14:00] <ubitux> so far it's only included once so there is no such problem [14:01] <wbs> ubitux: the issue with tables in headers isn't if the header is included multiple times in the same compilation unit, but if you accidentally later start including the same header in multiple files [14:01] <wbs> which depending on compiler and linker might or might not lead to duplicated tables [14:02] <ubitux> right, but that's not supposed to happen in here [14:02] <ubitux> -in [14:02] <wbs> I'm not commenting on the actual case here, just in general [14:02] <wbs> (haven't looked at that) [14:02] <ubitux> yeah sorry, my workaround wouldn't work indeed [14:02] <wbs> and the problem with "not supposed to happen" is that it can easily be overlooked and changed later by someone who doesn't keep this in mind [14:03] <wbs> the downside obviously is that you can't inline individual constants from the table if you have an access like table[42] somewhere [14:03] <BBB> ubitux: where is VP9Context defined? [14:03] <ubitux> libavcodec/vp9.h [14:04] <BBB> can you diff our vp9.c to their vp9.h? [14:04] <ubitux> yes i was going to [14:04] <BBB> the int64_t/unsigned thing you mentioned I agree with, I don't quite see why [14:04] <BBB> it's read as AV_RB32 [14:04] <BBB> so it always fits an unsigned [14:04] <BBB> and then I think it's safely compared? [14:04] <BBB> maybe they think that pkt->size can go negative? [14:05] <ubitux> BBB: http://lucy.pkh.me/vp9hdiff.html [14:05] <ubitux> mmh. [14:05] <BBB> the av_clip in the fw update function seems unnecessary, the table only has so many entries so it can never go outside range [14:05] <ubitux> i should diff against something else [14:06] <BBB> but it's not functionally relevant so they can keep it as a documentation cosmetic I guess [14:06] <BBB> hm yeah [14:06] <BBB> the memcpy is broken [14:06] <BBB> you can't memcpy a table of [11] and [3] to each other and expect things to work [14:06] <BBB> there's a reason that was a loop [14:07] <BBB> I don't see any other functional changes [14:07] <ubitux> huh they removed the vp9dsp.h [14:07] <BBB> yeah that's in vp9.h [14:07] <BBB> oddly [14:07] <BBB> I always tended to split dsp stuff in its own header since arch-specific code depends on that header [14:07] <BBB> and you obviously don't want them to include all of vp9.h [14:07] <BBB> just the dsp parts [14:07] <ubitux> right [14:08] <ubitux> ffmpeg/libavcodec/vp9dsp.h libav/libavcodec/vp9.h raises no relevant diff [14:08] <BBB> so one good change, a few broken ones, a few unnecessary ones [14:08] <ubitux> gonna try vp9.c vs vp9.h [14:08] <BBB> and a shitton of cosmetics [14:08] <BBB> long live the fork :( [14:09] <ubitux> ok well [14:09] <ubitux> fb removed [14:10] <ubitux> BBB: http://ubitux.fr/pub/pics/vp9-h-vs-c-diff.png [14:10] <ubitux> relevant part of vp9.c vs vp9.h [14:10] <BBB> yeah I saw them renaming f to cur_frame [14:10] <BBB> that's fine I guess, but still a cosmetic [14:11] <ubitux> yeah but fb removed [14:11] <BBB> fb[] removal is fine I guess, I haven't looked very closely at it, the loops appeared similar [14:11] <BBB> did they change frame allocation behaviour? [14:11] <ubitux> BBB: yes, a little [14:11] <ubitux> they unref instead of ref [14:12] <BBB> *confused* [14:12] <BBB> well if it works [14:12] <ubitux> BBB: see around L3454 (left) in http://lucy.pkh.me/vp9diff.html [14:13] <BBB> oh that's kind of cute [14:13] <BBB> I like that change [14:13] <BBB> see, small good changes get lost in a sea of cosmetics [14:13] <BBB> so sad [14:14] <ubitux> that's why i wanted to extract the relevant part [14:14] <ubitux> +s [14:14] <ubitux> BBB: what about the switch to while? [14:14] <ubitux> (a bit below) [14:15] <ubitux> (demacrotization) [14:15] <BBB> that's silly [14:15] <BBB> it adds an extra and to each loop iteration [14:15] <BBB> I don't think it's performance critical, so if you dislike macros, that's fine [14:15] <BBB> but I don't think it's better [14:15] <ubitux> no i don't dislike it [14:15] <ubitux> just curious [14:16] <BBB> thye do know 'res' means 'result' right? [14:16] <BBB> is ret 'return_value'? [14:16] <BBB> it's an odd naming change [14:16] <ubitux> ret is often used [14:17] <ubitux> BBB: interested in picking the frame allocation thing? [14:17] <ubitux> (i mean re-doing the patch yourself) [14:32] <BBB> the change suggests res is invalid english or so [14:33] <BBB> i can try to pick it over the weekend [14:33] <BBB> weekdays are bad [14:33] <ubitux> i'm pretty sure it's a consistency/i-like-red-better thing [14:33] <BBB> right [14:34] <ubitux> BBB: don't worry too much about it, i can do the extraction myself [14:34] <ubitux> and will send you some patches for review [14:34] <ubitux> it was just in case you wanted to work on this [14:35] <ubitux> but if you prefer working on MT or SIMD& :) [14:36] <BBB> nah, I'll do mt and simd [14:37] <BBB> but so little time :( [14:37] <BBB> time to go to work, bbl [14:45] <sspiff> ubitux: it seems to me that av_interleaved_write_frame is meant for the kind of stuff that's occuring with the DVB subtitles: queuing packets for being written later on in the container, based on their DTS? [14:46] <sspiff> judging from the fact that it eventually calls ff_interleave_packet_per_dts, adding it to AVFormatContext->packet_buffer [14:47] <ubitux> i would guess it's for anything that require re-ordering [14:47] <ubitux> b-frames stuff [14:47] <sspiff> so the fact that compute_fields2 complains about the fact that the DTS is not monotonically increasing seems like superfluous and maybe even wrong to me? [14:47] <plepere> in ffmpeg, is there something against // comments ? [14:47] <ubitux> plepere: no [14:47] <plepere> ok thanks [14:47] <ubitux> plepere: but better use ; in asm :p [14:48] <plepere> In order to keep myself from loosing too much hair, I'm putting all versions of openHEVC x86 optimisations together. [14:48] <sspiff> ubitux: sure, but since it uses interleave_compare_dts means that the DTS'es can be non-monotonic? [14:48] <plepere> so it's mostly refactoring [14:49] <plepere> but otherwise, my angry stares did not intimidate my asm to fix itself [14:49] <ubitux> sspiff: i don't remember which of pts and dts is ordered :p [14:50] <sspiff> dts is ordered, pts is not generally [14:51] <sspiff> (in case of video GOPs at least) [14:52] <sspiff> I was thinking of adding a queue (AVPacketList) to output streams to buffer packets based on DTS, but it looks like that's already there :P [14:52] <sspiff> (for the stupid DVB subtitle bug) [14:52] <ubitux> i don't think i can help you in that area [14:52] <ubitux> :p [14:53] <sspiff> do you know who would know how this interleaving code works and how I can abuse it? [14:53] <ubitux> yeah, you should harass michaelni about such pts/dts thing, keeping in mind he's busy :p [14:54] <ubitux> or ask on ffmpeg-devel, maybe [15:08] <saste> ubitux, any progress with perlin noise source? [15:08] <ubitux> saste: huh? [15:08] <ubitux> i don't remember working on this [15:09] <saste> you mentioned that, some time in the past [15:09] <saste> nevermind [15:09] <cone-827> ffmpeg.git 03Ronald S. Bultje 07master:458446acfa14: lavc: Edge emulation with dst/src linesize [15:09] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:91e00c4a785d: Merge commit '458446acfa1441d283dacf9e6e545beb083b8bb0' [15:10] <ubitux> ah, maybe [15:10] <ubitux> as a source filter? [15:10] <ubitux> would be nice indeed :)) [15:13] <clever> ubitux: ah looks like i dont want to create a second _hwaccel struct [15:13] <clever> the pix_fmt on that struct should be my custom one [15:13] <clever> so, why is it trying to call ff_find_hwaccel with AV_PIX_FMT_YUV420P10LE instead of AV_PIX_FMT_RPI, hmmm [15:14] <ubitux> i didn't follow what you were trying to do, already did, or currently have some trouble with [15:14] <ubitux> except maybe adding r-pi hwaccel [15:15] <clever> ubitux: http://privatepaste.com/1f842c4dbf [15:15] <clever> i have this 'working' for 8bit h264 [15:15] <clever> it properly gets the bitstream [15:15] <clever> but for 10bit h264, the code just isnt even ran [15:15] <ubitux> what is AV_PIX_FMT_RPI? [15:15] <clever> a custom format that only works with the vo module i made in mplayer [15:15] <ubitux> oh just like VDPAU ok [15:15] <clever> it passes the bitstream data directly to the vo module [15:15] <clever> i based everything off the vdpau code [15:16] <clever> so ff_find_hwaccel must be ran with AV_PIX_FMT_RPI to find that struct [15:16] <ubitux> i thought it required a _<codec> suffix [15:16] <ubitux> but seems not [15:16] <clever> but for 10bit files, it uses AV_PIX_FMT_YUV420P10LE [15:17] <wm4> I think 10 bit stuff directly works bypasses the hw accel layer? it used to just crash [15:17] <wm4> clever: what kind of API does rpi use for hw decoding and display? something EGL related? [15:18] <j-b> OMX, of course [15:18] <clever> wm4: openmax i believe [15:18] <clever> http://privatepaste.com/3206505237 [15:18] <clever> this is the debug output with my extra debugging added [15:18] <wm4> k [15:18] <clever> it starts out with pixel format -1, then 0, then it goes back to -1, and somehow decides to use 110 (AV_PIX_FMT_RPI) right at the end [15:19] <clever> then using AV_PIX_FMT_RPI it does ff_find_hwaccel and everything works [15:19] <clever> thats how 8bit files work [15:20] <clever> and here is the 10bit files, http://privatepaste.com/26726b29a4 [15:20] <clever> it starts out as -1, then jumps to 0 [15:20] <smarter> [14:07:35] <BBB> I always tended to split dsp stuff in its own header since arch-specific code depends on that header [15:20] <smarter> [14:07:41] <BBB> and you obviously don't want them to include all of vp9.h [15:20] <clever> i mean 72 [15:20] <smarter> why not? [15:20] <clever> then goes back -1, then 72, and stays 72 [15:21] <clever> it never switches to AV_PIX_FMT_RPI (110) [15:21] <wm4> clever: well, I doubt rpi can decode 10 bit files...? [15:21] <clever> wm4: i already checked, it can [15:22] <wm4> can it really, or does it just decode it as 8 bit? (which should give funky artifacts) [15:22] <clever> yeah, i do see a bit of artifacting [15:22] <JEEB> real 10bit decoder ASICs after all cost four-five digit sums :P [15:22] <clever> so its just ignoring 2 of the bits? [15:23] <JEEB> it's more than that [15:23] <JEEB> it's broken decoding [15:23] <JEEB> plain and simple [15:23] <clever> still looks useable, far better then trying to software decode it [15:23] <JEEB> you can look into the AVC/H.264 spec for more details [15:23] <nevcairiel> they implemented such evil hackery on the rpi? [15:23] <nevcairiel> another reason never to buy yone [15:24] <JEEB> well, it really depends. It doesn't take much of a stream to just output a picture that is completely borked [15:24] <JEEB> of course if you want that instead of it just telling you the stream can't be played... [15:24] <clever> it looks 95% good [15:24] <clever> just every now and then, it gets a small artifact somewhere [15:24] <JEEB> it just happens to look so right now, with the sample you have [15:24] <clever> yeah [15:24] <clever> it would depend on the encoding [15:25] <clever> id still rather fix it, and print a warning that 10bit isnt fully supported [15:25] <clever> rather then fully ignore the files [15:25] <JEEB> nevcairiel, I don't see anything special, nvidia and ATi/AMD used to let such stuff through as well [15:25] <JEEB> probably intel as well [15:25] <JEEB> nowadays the check is in the drivers or the HW decoding API [15:26] <clever> i just need to know why its trying to do ff_find_hwaccel with AV_PIX_FMT_YUV420P10LE instead of AV_PIX_FMT_RPI [15:26] <nevcairiel> because thats the pixel format for it [15:26] <nevcairiel> its hard-wired to only try hwaccel formats for 420 8-bit [15:26] <clever> ah [15:26] <clever> let me check arround h264_hwaccel_pixfmt_list_420 [15:27] <clever> this looks related [15:27] <clever> let me hack the crap out of get_pixel_format and figure out what its doing [15:29] <wm4> <nevcairiel> its hard-wired to only try hwaccel formats for 420 8-bit <- in theory, the library user should just never try hw decoding with profiles where it doesn't work, but mplayer doesn't check profiles [15:29] <clever> and i'm trying to force something thats already confirmed as broken [15:29] <nevcairiel> since there is no hardware for decoding any other profiles, this hard-wired check isn't wrong [15:30] <nevcairiel> but its not complete either, can still have lossless 420 8-bit which blows up in the decoder [15:30] <clever> its asking for configure to be reran, so this will take a few hours [15:31] <clever> i'll be back later once it compiles and i get some sleep [15:31] <clever> pretty sure the problem is that get_pixel_format isnt picking my custom format [15:31] <nevcairiel> the problem is thats its hard-wired to never use hwaccel for 10-bit [15:32] <clever> yeah, it looks like case 10: is catching things before it reaches case 8: [15:32] <wm4> clever: do you have your mplayer patch somewhere? [15:32] <clever> dang, the names are so obvious now! [15:33] <clever> wm4: let me upload it [15:33] <Compn> clever : lol @ case 10 v case 8 [15:33] <clever> Compn: i was just ignoring them, they usualy have little meaning [15:34] <clever> until i'm forced to tell you what they are, and aha! [15:34] <cone-827> ffmpeg.git 03Ronald S. Bultje 07master:72ca830f511f: lavc: VP9 decoder [15:34] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:97962b278a8a: Merge remote-tracking branch 'qatar/master' [15:36] <clever> wm4: finding the url... [15:36] <clever> wm4: http://ext.earthtools.ca/download/patch.tar [15:36] <wm4> thanks [15:37] <cone-827> ffmpeg.git 03Compn 07master:5592d1b74192: riff: add G264 to mpeg4, only decodes keyframes [15:37] <clever> that also has a fix for a double free i found in ffmpeg [15:37] <Compn> j-b : ^^^ g264 added [15:37] <Compn> ehe [15:37] <wm4> clever: I see, no display yet [15:37] <clever> wm4: yeah, it has everything except the openmax code [15:38] <clever> all it can do is pipe the bitstream down to the vo module, and then save it to /tmp/ [15:38] <clever> http://ext.earthtools.ca/download/git.diff ctrl+f for fail, and read the comments in that region [15:38] <clever> there is a double-free bug in ffmpeg [15:39] <clever> av_freep(&priv) releases some memory, then av_buffer_unref tries to reference it, then use a callback inside that to release it again [15:40] <clever> and its only gone un-noticed, because only broken codecs trigger that code [15:41] <j-b> Compn: wow [15:41] <ubitux> "only decodes keyframes" [15:42] <Compn> who needs all of those other frames ? [15:42] <Compn> also its flipped :) [15:42] <Compn> i guess i could add it to flipped list [15:42] <Compn> but whoever fixes non-keyframes can do that [15:43] <clever> i should get some sleep while this recompiles [15:43] <clever> later all :) [15:43] <Compn> L264 is lead h264 . LEAD always messes with stuff... [15:46] <Compn> so no, its not mpeg4 [15:46] <Compn> :( [15:46] <Compn> luckily no one uses L264 so we can ignore :) [15:49] <Compn> i should find binary codec for l264 [15:49] <Compn> hmm [15:50] <Compn> https://forum.videolan.org/viewtopic.php?f=14&t=50293&start=0 [15:50] <Compn> by Jean-Baptiste Kempf » Fri Sep 19, 2008 8:13 pm [15:50] <Compn> Well, even while forcing L264 codec, it doesn't decode those, because they are not H264 compliant. [15:51] <Compn> j-b : how come you no remember saying this, 5 years ago ? [15:51] <j-b> I do [15:51] <j-b> hence my question [15:51] <Compn> its not like those files became magically compliant :) [15:51] <Compn> but ok , good question :) [15:52] <Compn> lead idiocy, not geovision gpl violating idiocy i guess [16:07] <j-b> Why the hell do you allow FLAC in mov? [16:09] <durandal_1707> I? [16:10] <ubitux> is there some remaining decoders still setting only the number of channels instead of the channel layout? [16:10] <ubitux> or users are still supposed to jungle between codec->nb_channels and codec->channel_layout? [16:10] <durandal_1707> sonic [16:12] <ubitux> mmh ok [16:12] <ubitux> i guess i'll have to jungle then [16:13] Action: ubitux copies/paste guess_input_channel_layout() [16:14] <durandal_1707> ubitux: nobody uses sonic [16:14] <ubitux> is it the only remaining one? [16:15] <durandal_1707> it is useless pile of vapourware [16:36] <sspiff> ubitux: how do I go about submitting this patch for feedback? [16:36] <sspiff> I'd love to get this thing merged, eventually :) [16:37] <ubitux> you send it as a git format-patch to ffmpeg-devel(a)ffmpeg.org [16:51] <sspiff> ah, damn, sent from my wrong email! now the message is awaiting moderator approval -_- [16:54] <sspiff> ubitux: how long does this approval process take, generally? [16:55] <ubitux> depends, 24h? [16:55] <ubitux> i think you can ask Compn [16:55] <ubitux> llogan too but he isn't online it seems [17:00] <sspiff> ubitux: I can wait 24h, that's fine. [17:10] <Compn> sspiff : i can accept it now [17:10] <Compn> what llist [17:10] <Compn> heh [17:10] <Compn> just gotta enter my password [17:10] <Compn> 12345 [17:10] <Compn> there [17:11] <Compn> sspiff : ok your email was approved [17:12] <sspiff> Compn: thanks! [17:12] <nevcairiel> it looks like you copy/pasted the patch file into your mail client, there is wrapping on some lines [17:12] <nevcairiel> it might not work anymore [17:14] <sspiff> nevcairiel: doh! How am I supposed to get it into my mail client (being gmail) without copy pasting? [17:14] <sspiff> ah wait [17:14] <nevcairiel> usually you could use git send-email, but that needs a bit of setup, otherwise just attach the file [17:14] <sspiff> alright, thanks [17:16] <sspiff> sorry for all the trouble! [17:17] <ubitux> sspiff: did you try to play with the AVFMT_NOTIMESTAMPS and AVFMT_TS_NONSTRICT? [17:18] <sspiff> ubitux: AVFMT_TS_NONSTRICT shouldn't help, since they're actually non-monotonic, even in the non-strict sense [17:18] <sspiff> didn't see AVFMT_NOTIMESTAMPS [17:19] <ubitux> not sure if that one really is relevant but well :) [17:20] <sspiff> ubitux: the accompanying comment says that's for formats that don't need timestamps, but MPEG-TS desperately needs them, no? [17:20] <ubitux> i guess so :) [17:22] <sspiff> ubitux: I thought AVFMT_TS_NONSTRICT might help (I think it disables the check that makes the transcoding abort), but the comment seems to say that I shouldn't rely on this working, so I didn't [17:27] <sspiff> nevcairiel: did my second email come through alright? [17:29] <nevcairiel> yes, looks fine [17:29] <sspiff> nevcairiel: thanks for verifying :) [17:51] <durandal11707> Compn: where you type that password? [17:55] <ubitux> is anyone interested in having av_audio_fifo acting as an audio ring? [17:55] <Compn> durandal11707 : you want to help moderate the ffmpeg-devel list ? :) [17:56] <Compn> durandal11707 : lou logan is moderator too, he works hard at it :) [17:56] <Compn> i'm sure he would be happy for some help [17:57] <wm4> ubitux: doesn't it already act as a ring? [17:57] <ubitux> wm4: if you drain manually [18:04] <ubitux> also, probably have the initial buffer completely full with silence at init [18:07] <wm4> doesn't the buffer have a size (which is 0 initially)? [18:07] <wm4> by which I mean av_audio_fifo_size() [18:08] <ubitux> yes [18:08] <ubitux> afaict [18:08] <ubitux> but the idea would be to have av_audio_fifo_size() always at the same size than the init size [18:08] <ubitux> (aka buffer filled with silence, and you push samples at the end) [18:09] <ubitux> (and the older ones go out) [18:09] <ubitux> i can write that in my app but i was wondering if some ppl would be interested in such api [18:11] <wm4> what is the use case? i.e. what exactly does your app need it for? [18:13] <durandal11707> ubitux: iirc something like that is used in couple of filters in request_frame at eof [18:13] <durandal11707> perhaps it can be refactored......? [19:01] <ubitux> wm4: the use case is a bit special, i need the last seen N samples at a given time t [19:01] <ubitux> and i need exactly N samples all the time [19:02] <ubitux> so i want to fill a ring buffer continuously, and read all of it sometimes [19:02] <ubitux> (without draining the data) [19:02] <wm4> hm [20:59] <llogan> i liked carl's answer here http://ffmpeg.org/pipermail/ffmpeg-user/2013-November/018530.html [21:42] <cone-876> ffmpeg.git 03Jan Gerber 07master:d03eea36b2c3: lavf/matroska*: add support for signed integers [21:42] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:cddd15ba5c9c: avformat/matroska: simplify signed int access code [21:47] <Daemon404> 42 [22:10] <ubitux> anyone has part 2 of mpeg4 standard? [22:13] <ubitux> kierank: aren't you hiding it under your jacket? [22:13] <kierank> is it not in the specs folder [22:24] <nevcairiel> ubitux: if a slightly outdated version is ok [22:25] <ubitux> nevcairiel: better than nothing :P [22:27] <nevcairiel> ubitux: http://files.1f0.de/tmp/MPEG4Part2.pdf [22:27] <ubitux> thx! [22:28] <ubitux> nevcairiel: is this sharable or not? [22:28] <nevcairiel> i dont care, i just got it from the interwebs [22:28] <nevcairiel> someone else violated the license [22:28] <nevcairiel> :D [22:28] <ubitux> ok perfect [22:28] <ubitux> :) [22:29] <nevcairiel> even has the license watermark in the footer [22:29] <nevcairiel> but hey [22:29] <nevcairiel> the stnadard has some weird things about 3d mesh coding in it, never heard of that before [22:36] <JEEB> nevcairiel, yeah -- MPEG-4 Visual had a lot of new stuff tried out [22:36] <JEEB> the problem is it wasn't really feasible [22:36] <JEEB> AVC/H.264 was then a coming-back to the old style [22:37] <JEEB> also I think many of the features never got into any profile [23:02] <Compn> someone working on h264 mvc ? [23:02] <Compn> ehe [23:02] <Compn> oh mpeg4 3d nevermind [23:29] <cone-876> ffmpeg.git 03Clément BSsch 07master:150c5543ffee: avcodec/vp9: fix "initialize" typo. [23:37] <llogan> ubitux: might be a good candidate for patcheck [23:38] <ubitux> [~/src/ffmpeg]- git grep -i intia [23:38] <ubitux> [~/src/ffmpeg]- [23:38] <ubitux> seems not [23:38] <llogan> lazy>intellect [00:00] --- Sat Nov 16 2013

1 0

ffmpeg.log.20131115
by burek 16 Nov '13

16 Nov '13

[08:40] <prkhr4u> running "ffmpeg -i rtsp://169.254.75.39:554/live.sdp -f http://localhost:8090/feed1.ffm" getting error: "At least one output file must be specified" [08:43] <sacarasc> prkhr4u: You did -f which means you're about to force an output format, then you put the output. Either remove the -f or put in a format. [08:45] <prkhr4u> I only want to stream and do not want to save the stream..In that case should i remove -f? [09:46] <prkhr4u> "HTTP error 503 Server too busy" using "ffmpeg -i rtsp://169.254.75.39:554/live.sdp http://localhost:8090/feed1.ffm" [10:51] <paulr> wondering if anyone can help as i'm rather confused - if I run apparently the same version of ffmpeg with the same video file and same config options, on two different pc's, and getting 2 different outputs - would that be 'normal'? ;/ [11:03] <zap0> possbily. [11:03] <zap0> how different? [11:26] <paulr> silly webchat ;/ - not sure if anyone saw previous question - 2 pc's - same video/ffmpeg/settings etc - apparently getting different output - is that 'normal'? [11:27] <sacarasc> paulr: As in not bit exact copies? [11:27] <sacarasc> That is normal. [11:29] <paulr> well, 5MB size difference in encoded video [11:29] <paulr> with same input [11:29] <paulr> one output is effectively lipsync'd, the other isn't [11:30] <paulr> [whilst googling, i'm wondering if i might get more reliable results forcing threads=1 [11:31] <paulr> I was kind of assuming that software calculation would be the same ;) [11:36] <zee_> -vf subtitles=subtitles.ass/srt hardburns the subtitle into the video.. [11:36] <zee_> how can I add is as a track instead of hardburning it? [11:37] <viric> with -f, -i and -map I think [11:37] <viric> I never tried [11:37] <zee_> with -map i map tracks from the -i input file.. [11:38] <zee_> my thought is to map it as well.. it makes most sense. [11:38] <JEEB> -i file.ass -c copy and possibly map :P [11:38] <JEEB> if you want to mux the ass subs into a container [11:39] <zee_> I just dont see how I would do it? its -map 0:0 .. So, would I -map subtitle.ass:3 or something? [11:39] <zee_> ok. [11:39] <zee_> So it is possible to use -i two times in the command? [11:40] <zee_> I am using gusarios nightly builds.. It converts srt to ass automatically [11:40] <JEEB> yes, you can use multiple input files [11:40] <JEEB> just like you can have multiple output files [11:40] <zee_> great. Ill experiment then [11:40] <JEEB> by default ffmpeg will select a single a,v,s track [11:40] <zee_> yea [11:40] <JEEB> so if you have more than that, you might need to -map [11:41] <zee_> yes, i use map to define the tracks I want to encode from the mkv's [11:41] <JEEB> and in map 0:0 the first zero is the input file number [11:41] <zee_> or m2ts, or mp4 or what ever source I have. [11:41] <JEEB> for second input it's 1 [11:41] <JEEB> and so forth [11:41] <ubitux> < JEEB> by default ffmpeg will select a single a,v,s track // not sure it will pick a 's' stream by default actually [11:41] <JEEB> yeah, not 100% sure about that either, *shrug* [11:41] <zee_> ill find out and let ya know :) [11:44] <zee_> it has to be converted to ass.. im pretty sure.. [11:44] <zee_> cause you cannot input the srt and run a vf command on it afterwards? [11:44] <zee_> and then map it [11:54] Action: paulr doesn't understand why ffmpeg transcoding results aren't deterministic [11:54] <viric> paulr: timestamps? [11:54] <paulr> i'm getting a 100MB file + 105MB file [11:59] <zee_> JEEB: http://pastebin.com/B9g4U5Gh [11:59] <zee_> can you suggest me how I map it.. Cause that way is not working.. [12:00] <zee_> it just maps from the 1. input file [12:01] <JEEB> first of all, the subtitle file is not an input [12:01] <JEEB> second of all, all your maps are for the first input file [12:01] <JEEB> also if you want only video and audio out of the first file [12:01] <JEEB> you can just do -map 0:v -map 0:a [12:02] <zee_> I tried it without -i for the sub.ass as well... [12:02] <JEEB> also you will not be able to mux ass into mp4 [12:02] <zee_> but it doesnt add is as a tracks. it hardcodes it [12:02] <viric> zee_: to what format? [12:02] <zee_> viric: what? [12:03] <JEEB> if you want subtitles in mp4 the only alternative is 3GPP Timed Text [12:03] <JEEB> I am not sure if ffmpeg can convert srt/ass to 3GPP Timed Text :P [12:03] <zee_> let me try [12:04] <zee_> it wierd... Cause handbrake will do the job, of adding a srt as a track... :/ [12:04] <zee_> and it uses ffmpeg [12:05] <JEEB> it does not use ffmpeg's mp4 muxer, and I think that part will then handle the conversion of srt into 3GPP Timed Text [12:06] <zee_> Probably so. [12:06] <zee_> ffmpeg wont convert srt/ass to 3dpp [12:07] <zee_> 3gpp* [12:10] <zee_> gpac can convert it [12:13] <JEEB> yes [12:37] <ubitux> 12:06:59 < zee_> ffmpeg wont convert srt/ass to 3dpp [12:37] <ubitux> 12:07:04 < zee_> 3gpp* [12:37] <ubitux> you sure about that? [12:37] <ubitux> try encoding with -c:s mov_text [12:38] <zee_> I love you ubitux [13:05] <Compn> everyone loves ubitux [13:29] <vl4kn0> Hi, is there any tutorial for beginners using libavfilter? I can't find any except very complex examples. [13:38] <Compn> vl4kn0 : theres some info on the ffmpeg trac wiki [13:38] <Compn> i think [13:57] <diesel420> hi [13:59] <sacarasc> Are you a Dr Strangelove fan, diesel420? [14:06] <Compn> i am, great movie [14:12] <sacarasc> Compn: I only asked because I know a guy who goes by dsl420 on a different network, dsl standing for Dr Strangelove. I have called him diesel420 a few times. And he is the kind of person to stalk me. :O [14:13] <diesel420> . . . [14:25] <Compn> sacarasc : methinks you enjoy the 420 too much lol [14:26] <sacarasc> I do stay awake until gone 04:20 often... [14:26] <Compn> you irc, but do you ever irc ... on weed? [14:26] <sacarasc> And, if you go by the incorrect, American, notation, Hitler's birthday is 4/20... [14:26] <sacarasc> No, I do not. [14:29] <Compn> ah [14:29] <Compn> 420 is american slang for marijuana [14:29] <Compn> so thats why you see often peoples nicknames with 420 [14:30] <sacarasc> It's slang for Hitler's birthday! [14:31] <Compn> ask your dsl420 guy if he smokes weed [14:31] <Compn> sour diesel is also the name of a strain of marijuana [14:31] <tiksa> hi guys I don't know if this is a relevant question but if I have one video stream and one audio stream, and then I map them, then if I want to pipe them to ffmpeg to create different outputs, what's the best kind of format/container to pass them forward to the pipe? [14:31] <Compn> no its not relevant, we only talk about weed in here :P [14:32] <Compn> whats your input tiksa ? [14:32] <Compn> ffmpeg can already do multiple outputs [14:32] <tiksa> mp4 file [14:32] <Compn> so it can pipe anything [14:32] <Compn> what are you piping to ? [14:33] <Compn> i mean, if you are doing ffmpeg > ffmpeg , you can just use one ffmpeg to do it all [14:33] <Compn> if i'm understanding your question [14:34] <tiksa> well the idea is that 1. I give multiple inputs (mp4, png ...) and then use filter_complex that ends to concat. 2. concat filter returns 2 outputs (video, audio streams) which I map. now I want to output multiple sized outputs with those filter applied [14:35] <tiksa> I didn't find a way to do this with one ffmpeg [14:35] <Compn> ah, yes someone was here the other day saying they couldnt use filter complex with multiple output files or something [14:35] <tiksa> if I just index different sized outputs at the end, the filter_complex is applied only to the first output [14:35] <Compn> then i'd say try mkv for streaming format [14:35] <Compn> it can handle most mp4 codecs [14:35] <Compn> pipe format i mean [14:36] <tiksa> ok, I'll try [14:36] <tiksa> thanks Compn! [14:36] <Compn> np [14:51] <tiksa> -f mkv --> "uknown input format: mkv". am I messing with formats/containers/streams or should I just suppose that my ffmpeg build does not support mkv..? [14:51] <Compn> hmm [14:51] <Compn> its -f matroska ? [14:51] <Compn> er [14:52] <Compn> you put -f mkv in the wrong spot [14:52] <Compn> have to put it after your input files [14:52] <Compn> or something [14:52] <Compn> what ffmpeg ver you running ? [14:53] <vl4kn0> can anyone explain what is avfilter_graph_parse-* for? [14:54] <vl4kn0> I see it used in every example yet I have no idea what it does [14:54] <tiksa> Compn: mkv -> matroska solved all the problems and I'm getting the output I wanted. (didn't change the place of -f). thanks! [14:56] <tiksa> (before that I tried a format named nut (?) that caused some problems in video quality) [14:56] <Compn> hmm, maybe the default nut codecs are wrong [14:56] <Compn> are you sure you're using -vcodec copy -acodec copy ? [14:57] <Compn> vl4kn0 : it parses what filters you want to use ? [14:57] <vl4kn0> Compn: fps [14:57] <tiksa> here is one of my latest versions.. kind of monster. http://pastebin.com/Jh0HSjg2 [14:58] <tiksa> in the pastebin version there is only 1 output though (I'll have 4) [15:01] <tiksa> I think I'm not figured completely how formats/codecs/streams are related to each other. however, I managed to build quite a long ffmpeg that works.. [15:01] <tiksa> *I've not figured [15:05] <Compn> tiksa : all that filter stuff is so complicated to me [15:05] <Compn> glad someone uses it [15:08] <tiksa> thanks.. I have to admit it took some time to learn how to use them. [15:08] <tiksa> actually my system creates those filter commands programmatically [15:09] <tiksa> that's why they might seem even more complicated.. [17:27] <vl4kn0> Hi, I'm trying to use the "fps" filter (programatically, not in command line) but don't have a clue how to use filters. Can you give me some bulletpoints or resources on what I need to do in order to get it working? [20:07] <encanis> hey, i want to record my desktop sound, NOT my microphone. how do i do that? ;) i use alsa (hw:0) [20:53] <llogan> hi. i want to ask a question and then leave in a few minutes. [20:55] <Mavrik> ;) [21:14] <spaam> llogan: its time to leave now. [21:15] <spaam> :) [21:27] <brandonf_> Howdy! Is anyone familiar with the mpeg2video codec parameters within ffmpeg? Specifically how to specify a custom matrix? [21:31] <llogan> brandonf_: you mean a color matrix? [21:35] <brandonf_> I'm not entirely sure. I'm trying to use ffmpeg to encode an mpeg2 file with the same settings as another (as seen from videospec or mediainfo). I've gotten it down to "Custom matrix" vs. "Default matrix" [22:09] <flaxo> hi... this is the REAL ffmpeg channel right? [22:11] <Mavrik> -well. [22:12] <flaxo> i have a file the plays well in vlc and mplayer but totally fucks up in ffplay... anyone care to have a look at a 6MB snippet? [22:22] <flaxo> i am to clueless to decide if it is worth a bug-report... anyone? -> http://online-multiplayer.com/doom9/data.php [22:23] <flaxo> damn.. [22:24] <flaxo> here we go: 6MB -> http://falko.vakat.de/download/fpart2.vob [22:28] <Compn> flarunt : whats up [22:29] Action: Compn checks it out [22:30] <Compn> flaxo : what ffplay ver do you have ? [22:30] <Compn> oh nice loop at the end [22:30] <flaxo> sec.. [22:31] <Compn> ffplay version N-52523-g0fb64da [22:31] <Compn> loops my ffplay [22:31] <Compn> mine is kind of old [22:31] <Compn> built on Apr 28 2013 00:01:23 [22:32] <flaxo> ok... [22:32] <flaxo> i totaly fucked up... sorry.. [22:33] <flaxo> i have a self-built ffmpeg installation... [22:33] <flaxo> but ffplay was still on the debian avplay [22:33] <Compn> ahhhh [22:33] <flaxo> i hate this mash... [22:33] <Compn> that fork ffplay [22:33] <Compn> the one with all of the bugs [22:33] <Compn> and then we get bugreports for the buggy fork :\ [22:33] <flaxo> it plays with my own build... [22:34] <Compn> ok then good :) [22:34] <flaxo> jeah sorry [22:34] <Compn> no worries :) [22:34] <Compn> its not your fault debian lies [22:34] <Compn> and uses ffmpeg trademark [22:34] <flaxo> at least i did not file a report ;) [22:34] <flaxo> jeah i really hate that fuckup they did there... [22:35] <flaxo> it did not help the linux multimedia front [22:35] <flaxo> not at all [22:36] <flaxo> the thing i do not understand is... i uninstalled the debian-ffmpeg package... [22:36] <flaxo> and never checked if everything was gone.. [22:40] <Compn> hmmm [22:41] <flaxo> wasted an hour on this!!! [22:41] <flaxo> the links where still there... [22:45] <Compn> that seems like debian bug [22:45] <flaxo> well thanks anyways [22:48] <Compn> no problem [22:48] <Compn> sorry we cant fix debian problems [22:48] <Compn> they dont listen to us [22:48] <flaxo> -_- i know... [22:48] <flaxo> i have internet! [22:48] <Compn> ehe [23:14] <ac_slater> Hey guys, I cant find much about m4e files. Apparently "Elementary MPEG4 video". I technically need to convert some regular MP4s to this. Any advice is appreciated [23:17] <JEEB> extensions are just extensions [23:17] <JEEB> you might want to see what's inside such files [23:20] <ac_slater> JEEB: right. [23:21] <ac_slater> JEEB: how do you suspect I do that, assume I'm moderately informed [23:22] <JEEB> ffmpeg -i welp.m4e or ffprobe welp.m4e [23:23] <ac_slater> JEEB: http://paste.debian.net/66088/ [23:23] <JEEB> ok [23:24] <JEEB> that is just raw MPEG-4 Visual [23:24] <JEEB> no container [23:24] <ac_slater> JEEB: I see that, so I guess I would like to take some video file and output something equiv to this [23:24] <ac_slater> this being the file in the paste [23:25] <JEEB> it's what you get from libxvid and mpeg4 encoders (the latter was named before MPEG-4 had Part 10 aka AVC/H.264) [23:26] <brimestone> I'm trying to figure out a transport compression where i can bring a 15GB ProRes 422 HQ or similar to something less than 1GB, and the option to rebuilt it back to 15GB ProRes 422 HQ with all its glory... [23:26] <brimestone> the compressed file doesnt have to be playable... [23:26] <ac_slater> I see. Good to know. I've been looking into video formats, containers, encoders, etc for the last month. It's starting to come together. So, is there anything in specific I'd need to do so ffmpeg can "convert" any video file to just raw MPEG4 encoder output? (ie - no container (right?)) [23:27] <ac_slater> JEEB: ^ [23:28] <JEEB> ffmpeg -i welp -map 0:v -c:v libxvid -q:v 2 -f m4v out.m4e [23:29] <JEEB> see if that works [23:29] <brimestone> JEBB: what that for me? [23:29] <ac_slater> brimestone: no me, sorry brimestone [23:29] <brimestone> ohh :) [23:29] <JEEB> the map basically only selects the video from the input, c:v sets the video encoder, q:v sets the video quantizer to 2 (generally should look rather OK) and sets the output format to m4v (raw mpeg-4 video) [23:30] <JEEB> brimestone, use lzma2 at max settings with 7z or something? :D [23:30] <ac_slater> JEEB: I'm really glad I can follow what you just said. I appreciate it [23:31] <brimestone> lzma2... hmm i have not use that before :) [23:31] <brimestone> researching.. [23:31] <llogan> brimestone: ffmpeg -i input -fs 1G -c copy -map 0 output.mov [23:31] <llogan> there you go. no loss. 1G [23:31] <brimestone> llogan, but can i get it back to where it is [23:32] <llogan> it was a joke [23:32] <brimestone> when the file is transported at the destination.. [23:32] <JEEB> brimestone, lzma2 is basically what the newer versions of 7zip handle [23:33] <JEEB> a more multithreadable version of lzma [23:33] <JEEB> if maximum settings of that don't cut it, then most probably nothing else will :P [23:33] <brimestone> JEBB, is there sample documentation on this? [23:36] <brimestone> ohhh... lzma2 is by itself, not connected to FFmpeg [23:37] <flaxo> brimestone: what are you trying to accomplish? [23:37] <JEEB> I mean, anything lossless will end up bigger :P [23:37] <JEEB> if you need to try and make something smaller without visual degradation [23:37] <flaxo> why the size limit? [23:37] <JEEB> then trying out some archiver on maximum settings is all you can try [23:38] <JEEB> and if that doesn't cut it, then unfortunately it's just impossible and you will have to change how you deal with it :P [23:38] <brimestone> create a transport file where i have ProRes422HQ -- > (Magic size) -->> (WAN transport)--> ProRes422HQ [23:39] <flaxo> so you are actually looking for compression only not conversion... [23:39] <brimestone> i have a need to tranport 45Min high res 1080 video internationally [23:39] <llogan> get a router that supports N [23:40] <flaxo> ask the NSA they can handle that size! [23:40] <JEEB> anyways, given the the file size you gave and unless that has a lot of well compressible data, I would have to say that you most probably ain't gonna hit your 1GB requirement :P [23:40] <JEEB> prores is basically jpeg [23:40] <brimestone> i have 100Mbps up and down at my end, but the client downloadingt them dont have that much bandwidth [23:40] <JEEB> that's not gonna compress well by itself [23:41] <JEEB> USB stick and snail mail might be the answer depending on how slow the other side is :P [23:41] <brimestone> Jebb: I can also use H.264 [23:43] <brimestone> JEEB: how about H.264? [23:44] <brimestone> Plus some VBR magic [23:44] <JEEB> anyways, it all depends on what exactly you are wishing to do. Because unless your source is very well compressable you ain't gonna fit it in a lossless or close-to-lossless quality into 1GB :P [23:44] <brimestone> ok, how source should i start with? H.264/AVC-I? [23:45] <JEEB> what [23:45] <flaxo> if that codec would exist... wouldn't we all use it on every video? [23:45] <brimestone> thats suppose to be "Or" like || [23:45] <brimestone> :) [23:45] <JEEB> I still don't understand what you are trying to imply [23:46] <brimestone> you said, unless my source is compressable.. So what filetype/codec is? [23:46] <JEEB> ... [23:46] <JEEB> I meant the source. The clip. What it contains [23:46] <flaxo> it depends on what is in your videos [23:46] <JEEB> for example, static screens generally compress very well [23:46] <JEEB> or mostly static [23:46] <JEEB> also I still have no idea what exactly you're trying to do and what is more important to you. Video quality or fitting it all into a random file size you have come up with. [23:47] <brimestone> oh.. no, its Dynamic, but very slow in deltas [23:47] <JEEB> ok [23:47] <JEEB> so you can try multiple things [23:47] <JEEB> 1) output lossless uncompressed copy from your editor [23:47] <brimestone> ok [23:47] <JEEB> 2) compress that with lzma2 [23:47] <JEEB> 3) see the size [23:48] <JEEB> (don't forget to set it all up to eleven in the archiver) [23:48] <brimestone> then decompress it on the other size? [23:48] <JEEB> yes [23:48] <JEEB> if that's too big then most probably a lossless compressed copy will be too, but it's worth a try [23:49] <JEEB> ffmpeg -i lossless.input.derp -c:v libx264 -crf 0 -preset placebo -g <whatever is the equivalent of --keyint infinite in x264> out.mov [23:49] <JEEB> this would encode lossless H.264 as long as your libx264 encodes 8bit and not 10bit video (it's a compile-time setting) [23:51] <JEEB> (of course you should compress audio with something as well, with an archiver or some lossless format like flac, wavpack or ALAC) [23:52] <JEEB> and in case all that fails you either start dropping your wishes in quality, or you start grabbing a 16GB USB stick or whatever, and send the thing via snail mail :P [23:54] <brimestone> :) thanks.. ill ping you back [00:00] --- Sat Nov 16 2013

1 0