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

[burek]

[00:01:17 CEST] <atomnuker> rcombs: got kinda working PCE support for the aac encoder, though the decoder's not happy about paired channels for some reason
[00:01:27 CEST] <rcombs> \o/
[00:01:37 CEST] <atomnuker> do you have any files I can test to see what I'm doing wrong
[00:02:17 CEST] <atomnuker> preferably with some common standard layout not in the AAC spec so I can see what the correct order should be
[00:06:04 CEST] <rcombs> try https://www2.iis.fraunhofer.de/AAC/7.1auditionOutLeader_v2_rtb.mp4
[00:06:16 CEST] <rcombs> uses PCE to signal BD 7.1
[00:06:45 CEST] Action: wm4 adds to fucked up samples collection
[00:06:49 CEST] <JEEB> :D
[00:10:15 CEST] <rcombs> in theory that configuration should be valid, and you'd think the fraunhofer guys would know how to encode AAC properly
[00:13:48 CEST] <rcombs> allegedly, ISO/IEC 14496-3 2009 PDAM 4 will specify channel configuration 12 as BD 7.1, but I don't have a sample for that
[00:19:40 CEST] <cone-795> ffmpeg 03Carl Eugen Hoyos 07master:db7d0d6e7c43: lavc/fic: Cosmetics, fix a typo.
[01:00:56 CEST] <cone-795> ffmpeg 03Michael Niedermayer 07master:76d0209db482: avcodec/intrax8: Remove duplicated chunk from ba5bcf96124a4933eef170dfe7955809d8d54a64
[02:56:30 CEST] <cone-795> ffmpeg 03Michael Niedermayer 07master:81064795034e: avcodec/bitstream_filter: Fix initializing options from the argument string
[02:56:31 CEST] <cone-795> ffmpeg 03Michael Niedermayer 07master:57fc93ecb2ce: avcodec/remove_extradata_bsf: Add back 'k' and 'e' options
[02:56:32 CEST] <cone-795> ffmpeg 03Michael Niedermayer 07master:ce18e48aec5d: avcodec/dump_extradata_bsf: Add back 'k' and 'e' options
[10:19:25 CEST] <j-b> 'morning
[10:37:58 CEST] <wm4> how to make anyone hate (L)GPL
[13:35:28 CEST] <petrurares> hi there! I have a doubt, I want to create a test for mss1 codec. I have a sample video, I update microsoft.mak and when I do " make -k -j6 fate-mss2 SAMPLES=../samples" the program don't cover any line of libavcodec/mss2.c
[13:35:33 CEST] <petrurares> Any idea?
[13:36:26 CEST] <petrurares> * change mss2 to mss1 in all the words
[13:37:25 CEST] <Compn> did you add fate-mss1 to the fate makefile ?
[13:37:43 CEST] <Compn> petrurares
[13:37:57 CEST] <petrurares> yes
[13:38:56 CEST] <petrurares> I add the following lines:
[13:39:02 CEST] <petrurares> FATE_MSS1 += fate-mss1-pal
[13:39:11 CEST] <petrurares> fate-mss1-pal: CMD = framecrc -i $(TARGET_SAMPLES)/mss1/screen_codec.wmv
[13:39:16 CEST] <petrurares> FATE_SAMPLES_AVCONV-$(call DEMDEC, ASF, MSS1) += $(FATE_MSS1)
[13:39:21 CEST] <petrurares> fate-mss1: $(FATE_MSS1)
[13:41:28 CEST] <petrurares> when I want to view the cover of fate-mss2 test I get the same resoults more or less 
[13:41:42 CEST] <Compn> you're saying the fate test runs , but the code coverage is bad ?
[13:41:53 CEST] <petrurares> yes
[13:43:59 CEST] <petrurares> I don't know if I am running the tests wrong or lcov doesn't work as expected
[13:44:38 CEST] <Compn> i'm not sure about lcov either , wait for someone who knows things :)
[13:45:01 CEST] <petrurares> ok, thanks :)
[13:47:21 CEST] <wm4> did anyone try to use libressl with ffmpeg yet?
[13:47:27 CEST] <wm4> via openssl API compat?
[13:57:33 CEST] <fritsch> wm4: openelec
[13:57:36 CEST] <fritsch> wm4: and libreelec
[13:57:41 CEST] <fritsch> the patch needed is minimal
[13:58:27 CEST] <fritsch> https://github.com/OpenELEC/OpenELEC.tv/blob/master/packages/multimedia/ffmpeg/patches/ffmpeg-050-libressl-is-free.patch <- seems, even more trivial
[13:58:56 CEST] <fritsch> so if libressl is in place all fine
[13:58:57 CEST] <wm4> haha
[13:59:01 CEST] <wm4> thanks
[13:59:42 CEST] <fritsch> https://github.com/OpenELEC/OpenELEC.tv/blob/openelec-6.0/packages/multimedia/ffmpeg/patches/ffmpeg-2.3-libressl-is-free.patch <- it was more work in older versions it seems
[14:00:13 CEST] <wm4> that patch just introduces a different define and consequently requires changing all the code
[14:00:19 CEST] <fritsch> jep
[14:01:08 CEST] <nevcairiel> someone enlighten me, how can you fork openssl and then put the fork under a more liberal license
[14:01:20 CEST] <wm4> nevcairiel: sure seems strange
[14:01:30 CEST] <fritsch> i have no idea to be honest how that worked
[14:03:59 CEST] <nevcairiel> i find it interesting that its not really obvious which license its actually under, the website didnt tell me, nor does the source have a license or copying file or something that seems obvious
[14:06:30 CEST] <nevcairiel> sounds to me like its still apache 1.0
[14:06:37 CEST] <nevcairiel> ie. not actually more "libre"
[14:08:36 CEST] <nevcairiel> ie. the openelec patch would seem to be problematic
[14:10:25 CEST] <Daemon404> fritsch, that patch is uh...
[14:10:25 CEST] <Daemon404> uh.
[14:39:35 CEST] <fritsch> Daemon404: ultra hot? :-)
[14:40:04 CEST] <JEEB> isn't it just superhot now? ;)
[14:40:38 CEST] <fritsch> uber hot
[16:00:56 CEST] <cone-042> ffmpeg 03Diego Biurrun 07master:d3044cf37fcd: opt-test: Move some variable declarations to avoid block braces
[16:00:57 CEST] <cone-042> ffmpeg 03Diego Biurrun 07master:0d2fcdb1c5c9: opt-test: Merge struct declaration and initialization
[16:00:58 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:1be5509fbbc6: Merge commit '0d2fcdb1c5c9e844c232e5429130727121990d0e'
[16:01:08 CEST] <Daemon404> wm4, ping
[16:01:14 CEST] <wm4> yes?
[16:01:17 CEST] <Daemon404> lavf: use new decode API
[16:01:24 CEST] <Daemon404> these 4 commits
[16:01:27 CEST] <Daemon404> what do, re: merge
[16:01:55 CEST] <wm4> the ones which make ffmpeg use it will break fate
[16:02:06 CEST] <wm4> at least the decoding one, anyway
[16:02:29 CEST] <wm4> for the others I have rebased patches on the ML, but let me check first
[16:02:32 CEST] <Daemon404> so whay do i do? do i skip all 4? do you have ffmpeg versions?
[16:06:12 CEST] <wm4> Daemon404: the first is "lavc: introduce a new decoding/encoding API with decoupled input/output" right?
[16:06:17 CEST] <Daemon404> yes
[16:06:40 CEST] <wm4> "[PATCH v2 3/8] lavc: introduce a new decoding/encoding API with decoupled input/output" should be the ffmpeg version of this
[16:07:00 CEST] <wm4> then  skip the ffmpeg ones
[16:07:02 CEST] <Daemon404> as it been ok'd
[16:07:06 CEST] <Daemon404> has*
[16:07:30 CEST] <wm4> not explicitly, but there hasn't been rejections either
[16:07:38 CEST] <wm4> the main problem was with the ffmpeg.c patches
[16:08:14 CEST] <wm4> and "lavf: use new decode API" apparently has problems, so just skip it for now
[16:09:47 CEST] <Daemon404> so apply that single patch and skip the other 3?
[16:09:52 CEST] <Daemon404> or rather, all 4.
[16:10:35 CEST] <wm4> I'm fine with applying the first patch
[16:10:40 CEST] <wm4> the rest will cause fate failures
[16:10:59 CEST] <Daemon404> right
[16:11:01 CEST] <Daemon404> so apply "[PATCH v2 3/8] lavc: introduce a new decoding/encoding API with decoupled input/output"
[16:11:04 CEST] <Daemon404> and skip all 4 merges
[16:11:07 CEST] <wm4> michaelni_: any immediate opinion?
[16:11:23 CEST] <wm4> well maybe I should just resent them
[16:11:25 CEST] <wm4> so skip all 4
[16:11:34 CEST] <wm4> it's getting too messy
[16:11:48 CEST] <wm4> (Libav might have applied additional changes to the first patch)
[16:12:03 CEST] <Daemon404> lol.. ok
[16:12:18 CEST] <Daemon404> ill just skip all four and leave getting them in ffmpeg to you
[16:12:23 CEST] <Daemon404> although teh thread seems kind of dead
[16:12:36 CEST] <wm4> I gave up on trying to fix the ffmpeg.c failures
[16:12:50 CEST] <wm4> they're only because of how ffmpeg tries to set dts on drain packets
[16:13:01 CEST] <Daemon404> what about the lavf patch
[16:13:15 CEST] <wm4> it's said to cause hangs in fate
[16:13:20 CEST] <Daemon404> O_o
[16:13:33 CEST] <wm4> apparently I missed this reply and so didn't investigate this at all
[16:14:13 CEST] <cone-042> ffmpeg 03wm4 07master:05f66706d182: lavc: introduce a new decoding/encoding API with decoupled input/output
[16:14:14 CEST] <cone-042> ffmpeg 03wm4 07master:84aea95e31e5: avconv: use new decode API
[16:14:15 CEST] <cone-042> ffmpeg 03wm4 07master:35846d93e023: avconv: use new encode API
[16:14:16 CEST] <cone-042> ffmpeg 03wm4 07master:8bc4accc37ab: lavf: use new decode API
[16:14:17 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:528af33b6f45: Merge commit '8bc4accc37ab047d2fd85d672c577b39dfc918e1'
[16:14:29 CEST] <Daemon404> wm4, it would be good to push the new api at least
[16:14:35 CEST] <Daemon404> sooner rather than later
[16:14:47 CEST] <wm4> I guess so
[16:15:19 CEST] <Daemon404> jkqxz, https://git.libav.org/?p=libav.git;a=commit;h=98114d70e48caf871b0fe9b8e5bf8ebd989b845d
[16:15:23 CEST] <Daemon404> do you expect any issue merging this
[16:15:29 CEST] <Daemon404> or the nvidia filter from anton after it
[16:15:35 CEST] <nevcairiel> .. its a new file? :)
[16:15:43 CEST] <Daemon404> it is but lavfi scares me
[16:15:51 CEST] <Daemon404> and i cant test vaapi
[16:23:21 CEST] <Daemon404> nevcairiel, is there anything special to merging lavfi filters?
[16:23:24 CEST] <Daemon404> or is it safe
[16:23:41 CEST] <nevcairiel> just make sure to update the license of new files, otherwise there should be nothing special
[16:23:51 CEST] <Daemon404> i did
[16:23:53 CEST] <Daemon404> k
[16:24:02 CEST] <cone-042> ffmpeg 03Mark Thompson 07master:98114d70e48c: lavf: VAAPI scale filter
[16:24:03 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:34245eccaf99: Merge commit '98114d70e48caf871b0fe9b8e5bf8ebd989b845d'
[16:24:19 CEST] <Daemon404> lavfi: add an NVIDIA NPP-based scaling filter
[16:24:22 CEST] <Daemon404> wat about this
[16:24:29 CEST] <Daemon404> i know our nvidia stuff is different
[16:25:20 CEST] <nevcairiel> dunno
[16:25:29 CEST] <Daemon404> is it BtbN i ask?
[16:25:34 CEST] <nevcairiel> dont remember which part of the cuda configure changes we took and which we didnt
[16:25:41 CEST] <Daemon404> right.
[16:26:07 CEST] <BtbN> Only the nvenc encoder is different iirc. The rest should be like in libav, as it was merged
[16:26:23 CEST] <Daemon404> so that filter is ok to merge?
[16:26:46 CEST] <nevcairiel> i think we already have the other cuda hwupload filter which uses linked cuda, so its probably not any different to that
[16:27:08 CEST] <BtbN> It should be, the cuda infrastructure is identical.
[16:27:16 CEST] <Daemon404> ok.
[16:34:33 CEST] <cone-042> ffmpeg 03Anton Khirnov 07master:8a02a8031ef4: lavfi: add an NVIDIA NPP-based scaling filter
[16:34:34 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:94e5f0922b72: Merge commit '8a02a8031ef4f98faf5647f0e01a8922247bf748'
[16:36:26 CEST] <cone-042> ffmpeg 03Martin Storsjö 07master:d44f3e405950: avio: Apply avoptions on the URLContext itself as well
[16:36:27 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:4eef36a4f6db: Merge commit 'd44f3e4059506a182f59218b1e967d42b01e097c'
[16:48:41 CEST] <cone-042> ffmpeg 03Andrey Utkin 07master:ccea588f8319: avio: Add an option 'rw_timeout'
[16:48:42 CEST] <cone-042> ffmpeg 03Derek Buitenhuis 07master:299d4f9428c2: Merge commit 'ccea588f831906084b8c8235222920e6984beb72'
[16:48:58 CEST] <wm4> jesus christ that Libav discussion about using assert
[16:49:10 CEST] <nevcairiel> luca just doesnt get what they are good for
[16:49:11 CEST] <nevcairiel> never has
[16:49:13 CEST] <nevcairiel> never will
[16:49:30 CEST] <Daemon404> ... im pretty sure i had a huge argument with him about assert abotu 2 years ago
[16:53:23 CEST] <Daemon404> Timothy_Gu, is it normal for fatebeta to not have the ability to sort by a column
[16:54:48 CEST] <nevcairiel> Daemon404: works for me, except the comment column which wouldnt make all that much sense either way
[16:56:36 CEST] <Angus> If I want to use the AVHWAccel ff_h264_vdpau_hwaccel found in...
[16:56:37 CEST] <Angus> https://ffmpeg.org/doxygen/2.8/vdpau__h264_8c_source.html
[16:56:39 CEST] <Daemon404> it isnt even clickable for me nevcairiel 
[16:56:44 CEST] <Daemon404> on fatebeta.f.o
[16:56:56 CEST] <Angus> is the only thing I need to do av_register_hwaccel?
[16:57:43 CEST] <Angus> as it seems decode_nal_units calls into setup_hwaccel -> find_hwaccel
[16:58:59 CEST] <michaelni_> ubitux, is there any magic for lcov and the src/ directory ? i remember there was some issue with it on coverage.ffmpeg.com and petru seems to have some problem too with some files not showing up that shuld, but maybe its unrelated
[16:59:02 CEST] <BtbN> no, you have to setup vdpau yourself and handle the vdpau output frames
[17:00:32 CEST] <Angus> is there any examples of the vdpau setup process?
[17:01:15 CEST] <ubitux> michaelni_: yes but Andreas fixed it afaik
[17:01:36 CEST] <ubitux> e740c3fb90c02802bc121e9f5a3cf58615b4cea1 i suppose
[17:02:05 CEST] <ubitux> it was a few months ago, ask him if he didn't rebased since then (not likely but well..)
[17:02:18 CEST] <ubitux> it fixed fate for me
[17:04:08 CEST] <ubitux> wm4: yeah every single time there is a patch containing an assert luca tries to push his rejection of it
[17:04:22 CEST] <ubitux> it's always the same endless debate :p
[17:12:43 CEST] <nevcairiel> does anyone know if avcodec just doesnt support mono aac or something? I have a sample from a user thats supposedly mono, but avcodec decodes it as stereo. some other stream probers seem to say its mono, but i dont know  their accuracy
[17:13:06 CEST] <Daemon404> are you sure it isnt dual mono
[17:13:09 CEST] <Daemon404> is it from japan?
[17:13:25 CEST] <Daemon404> or is it SBR?
[17:13:36 CEST] <nevcairiel> is SBR yes, but why would that force stereo
[17:16:29 CEST] <Daemon404> i assume it's HE then
[17:16:40 CEST] <Daemon404> and thus uses parametric stereo
[17:16:49 CEST] <nevcairiel> no, its only HE, not HEv2
[17:16:52 CEST] <nevcairiel> HEv2 is PS
[17:17:43 CEST] <Daemon404> ok
[17:17:49 CEST] <atomnuker> nevcairiel: PCEs can cause some funny behaviour as I've learned, might be that
[17:18:16 CEST] <nevcairiel> debugging in the aac code is apparently impossible due to the f'ing template dealy
[17:19:04 CEST] <nevcairiel> well lets see if it uses PCE
[17:19:07 CEST] <durandal_1707> anyone want to backport something for me?
[17:21:49 CEST] <nevcairiel> the extradata has no PCE and says channel config 1, which is mono
[17:23:19 CEST] <nevcairiel> wait, there is some crazy ass code that fro some reason assumes there is PS when SBR is used
[17:23:34 CEST] <nevcairiel> why would it assume that
[17:25:32 CEST] <jkqxz> Daemon404:  Nothing funny in those.  It's the next one with (avconv|ffmpeg)_vaapi.c that might do something nasty (and also makes it possible to actually test stuff).
[17:28:06 CEST] <nevcairiel> atomnuker: do you know how this line makes sense? http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/mpeg4audio.c;h=188d843eee67b64d065bf469e1fd47b2a7424ed9;hb=HEAD#l151 .. why is AAC_LC considered HE-AACv2?
[17:33:25 CEST] <atomnuker> nevcairiel: c->object_type != AOT_AAC_LC makes no sense
[17:36:18 CEST] <cone-042> ffmpeg 03Petru Rares Sincraian 07master:849e55e58ecc: fate: Add test for mss1 codec
[17:40:10 CEST] <nevcairiel> all those profiles are build upon the LC profile, no clue what the check is really supposed to say
[17:40:19 CEST] <nevcairiel> its been like that since PS support was implemented
[17:41:12 CEST] <atomnuker> might be a typo since the comment says HEv2
[17:45:53 CEST] <nevcairiel> the real problem starts in decode_ga_specific_config, where an implicit PS (-1) gest turned into PS=1 on mono streams with SBR
[17:46:41 CEST] <atomnuker> ah, yeah, forgot the sample was AAC HE
[17:48:39 CEST] <nevcairiel> this whole functionality seems to have gone mostly unchanged, everything ends up at the original HEv2 commit :)
[17:48:47 CEST] <Daemon404> nice
[17:48:53 CEST] <Daemon404> who even encodes he v1 btw
[17:48:56 CEST] <nevcairiel> guess HE mono is rare
[17:49:03 CEST] <Daemon404> ive never seen it in the wild
[17:49:19 CEST] <nevcairiel> for when your signal is mono and you dont need PS?
[17:49:53 CEST] <Daemon404> sounds rare
[17:50:01 CEST] <atomnuker> few do, but those who do know PS can reduce quality vs just SBR for a given bitrate
[17:50:09 CEST] <nevcairiel> well sure mono audio isnt encountered that often
[17:50:29 CEST] <atomnuker> will take a look at the specs tonight to see the correct way to signal v2
[17:50:41 CEST] <nevcairiel> but ffmpeg even sets the profile to aac-he, not v2, so at some point it figures out there is no PS
[17:50:53 CEST] <nevcairiel> but it doesnt undo the stereo-fication
[17:51:11 CEST] <Daemon404> nevcairiel, ... does it happen pre-codecpar?
[17:51:14 CEST] <Daemon404> <_<;
[17:51:41 CEST] <nevcairiel> yes
[17:51:47 CEST] <nevcairiel> the code i'm testing is pre
[17:51:51 CEST] <Daemon404> ok
[17:51:56 CEST] <Daemon404> phew.
[17:52:27 CEST] <wm4> is it legitimate to use AVOption to communicate information from a decoder to the API user?
[17:52:29 CEST] <nevcairiel> even outputs stereo audio for some reason, yet claims its aac-he only =p
[17:53:23 CEST] <Daemon404> wm4, shouldnt that be sidedata
[17:53:24 CEST] <Daemon404> or metadata
[17:53:55 CEST] <nevcairiel> using avoption as information export seems fishy
[17:54:07 CEST] <nevcairiel> although i'm sure we have it somewhere already
[17:54:29 CEST] <wm4> Daemon404: it's not per-frame data, it's only set on init
[17:54:41 CEST] <wm4> anyway, doesn't matter too much
[17:54:54 CEST] <nevcairiel> what kind of info is it
[17:55:50 CEST] <Daemon404> wm4, wouldnt it be stream-level sidedata then
[17:55:58 CEST] <wm4> no
[17:56:14 CEST] <wm4> nevcairiel: from a system decoder wrapper, whether it actually uses hwaccel
[17:56:54 CEST] <nevcairiel> i suppose avoption is fine in that case
[17:57:01 CEST] <nevcairiel> even if a bit iffy
[17:57:05 CEST] <Daemon404> still seems like something the api user shouldnt need to know
[17:57:11 CEST] <Daemon404> except for ricing
[17:57:15 CEST] <nevcairiel> need maybe not, but maybe want
[18:26:56 CEST] <nevcairiel> atomnuker: looks like the behavior of our decoder is "correct" to some degree, the specification considers this type of behavior appropriate
[18:30:02 CEST] <nevcairiel> 1.6.6.3 in the spec
[19:21:45 CEST] <wm4> lol
[19:22:39 CEST] <wm4> heh chromium is accessing private fields (though that's no the cause)
[19:44:13 CEST] <nevcairiel> even included internal.h =p
[19:49:23 CEST] <kurosu> Is there something better to use that pastebin for posting chunks of code? I think I saw people using something else, don't know why ?
[19:49:45 CEST] <nevcairiel> usually personal preference, some like github's gist, some use any other paste site
[19:52:26 CEST] <kurosu> jamrial, before: http://pastebin.com/UQdq5xsT
[19:53:38 CEST] <kurosu> after: http://pastebin.com/qGKBi1eQ
[19:55:50 CEST] <atomnuker> I have aliases for sprunge.us for diffs and 0x0.st for everything else
[21:59:21 CEST] <pfelt> afternoon all. i'm playing with writing my own filter and am struggling just a little bit.   are there any docs on how to create a new filter?  http://wiki.multimedia.cx/?title=FFmpeg_filter_HOWTO is the best i've found, and it seems to be dated?
[22:01:31 CEST] <jkqxz> Take an existing filter with the same input/output properties as the one you want to create and modify it.
[22:02:56 CEST] <pfelt> heh.  that's what i thought the answer would be
[22:03:24 CEST] <pfelt> i'm missing something somewhere.  i segfault on options initialization.  i'll keep digging
[22:04:55 CEST] <pfelt> i think it has to do with zero'ing my private context right
[22:05:44 CEST] <atomnuker> make sure your AVClass is the first field in your private context
[22:05:47 CEST] <jkqxz> The private context it makes for you is zero initialised (to be priv_size).
[22:07:40 CEST] <pfelt> hmm.  then i'm not sure why set_string() is segfaulting on the free
[22:08:36 CEST] <ubitux> pfelt: doc/writing_filters.txt
[23:09:23 CEST] <Daemon404> https://trac.ffmpeg.org/ticket/5451
[23:09:35 CEST] <Daemon404> reported by "misc' and cc'd to me?
[23:10:10 CEST] <Daemon404> i guess cause im the merge commit gut
[23:10:12 CEST] <Daemon404> guy
[23:10:16 CEST] <Daemon404> ill check tomorrow i suppose
[23:14:47 CEST] <kurosu> trying to create a wmaudio sample from matroska to wma, aframes seem to generate several warnings about DTS - wma muxer issue or PEBKAC ? in the later case, does anyone have a better suggestion ?
[23:18:17 CEST] <cone-316> ffmpeg 03Petru Rares Sincraian 07master:f25367f4b41c: fate: Add test for 012v codec
[23:23:49 CEST] <pfelt> not sure if this is the right place to ask, but what's the difference between using -i and a filter that's a source?
[23:24:30 CEST] <wm4> you mena moviesrc or whatever that was?
[23:24:36 CEST] <wm4> *mean
[23:24:59 CEST] <pfelt> the filter i'm playing with create will be a video source filter
[23:25:16 CEST] <pfelt> just wondering why we can do filters that are sources and the -i (which seems to me to also be a source)
[23:25:27 CEST] <pfelt> and yeah, it's kinda based on movie/amovie
[23:25:32 CEST] <nevcairiel> -i is for plain files
[23:25:47 CEST] <nevcairiel> sources are more generic, they could also open a file if they want to
[23:25:53 CEST] <nevcairiel> but they can also entirely generate the signal
[23:25:55 CEST] <nevcairiel> like testsrc
[23:26:14 CEST] <wm4> and yes ffmpeg.c can use them
[23:31:07 CEST] <durandal_1707> michaelni_: why is there 2 factor in tak parser ?
[23:31:59 CEST] <durandal_1707> it breaks demuxing of very small frames at end of stream
[23:42:25 CEST] <pfelt> this may be a filtering question, but is there any good way to swap input streams while the command is running?  kinda like streamselect but with actually opening a new input file?
[23:43:03 CEST] <nevcairiel> well your filter can do whatever, although changing stream parameters like frame size etc can be problematic
[23:43:32 CEST] <pfelt> yeah.  that's what my filter was intending to do, i just wanted to make sure that it didn't already exist somewhere
[23:43:44 CEST] <pfelt> the folks in the user channel didn't seem to think it did
[23:44:53 CEST] <ubitux> lavfi has pre-opened stream
[23:45:11 CEST] <ubitux> i hope you're not trying to make a streamselect that actually opens files :p
[23:45:30 CEST] <pfelt> either that or a movie source that allows for changin the source to a new file
[23:45:51 CEST] <ubitux> :/
[23:46:06 CEST] <pfelt> here's my use case:
[23:46:23 CEST] <nevcairiel> cant you just open multiple files at once and switch through them as needed, instead of opening them on demand
[23:46:28 CEST] <pfelt> i've got a grid (built with *stack) and i want to change what one of the grid items is displaying without killing the whole thing
[23:46:34 CEST] <ubitux> the closest sane option is see for you is to add command input to movie filter
[23:46:44 CEST] <ubitux> to live switch the source
[23:47:21 CEST] <pfelt> ubitux: yeah.  i started there actually
[23:47:39 CEST] <pfelt> i segfault when i try to switch, i think because of how movie builds it's pads, but i could be wrong there
[23:48:15 CEST] <pfelt> this leads to another question path.  process_command().  the command stops at the first filter that has that name right?
[23:48:37 CEST] <pfelt> so if i have multiple movie filters installed, how could i send a command to the second instance of the filter?
[23:48:55 CEST] <ubitux> mmh i don't remember the details
[23:48:59 CEST] <nevcairiel> i think you can name them
[23:49:11 CEST] <ubitux> try the command mode in ffmpeg ('c')
[23:49:27 CEST] <ubitux> and send a ping or something
[23:49:37 CEST] <ubitux> there might be an help to help you target a specific one
[23:50:36 CEST] <pfelt> i'm trying to grok this code along with writing a new filter too.  in my test filter i've set an instance name which i could use to determine if "this instance" should process the command or let it move on to another instanc
[23:56:17 CEST] <michaelni_> durandal_1707, i have no idea
[23:58:11 CEST] <cone-316> ffmpeg 03Paul B Mahol 07master:13406b6124a5: avcodec/tak_parser: fix parsing of streams with bunch of small frames at end
[00:00:00 CEST] --- Tue Apr 19 2016