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

[burek]

[02:02] <cone-149> ffmpeg.git 03Christian Suloway 07master:00d4013d9f84: avformat/crypto: added encryption
[02:02] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:24e7e0237b6e: avformat/crypto: Use av_memdup()
[02:19] <rcombs> "crypto: added encryption"
[02:19] <rcombs> \o/
[03:39] <pross> rcombs: helps to have that
[03:39] <rcombs> I definitely like my crypto with encryption
[03:46] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:ed49b142bb8b: tests: Rename vsynth2 to vsynth_lena
[03:47] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:42801505cd82: tests: Add vsynth2 which uses the new reference.pnm
[03:48] <michaelni> yes, it was with only decryption before
[03:50] <pross> impressive: https://www.youtube.com/watch?v=_SkfJgMuERo
[03:53] <rcombs> michaelni: it's more fun to take it out of context, though
[10:08] <j-b> 'morning
[10:17] <Compn> so early
[11:04] <rcombs> anyone know how the native AAC encoder with The Mythical Patch" performs in listening tests as compared to the AC3 encoder?
[11:04] <rcombs> (or to FAAC and FDK, for that matter?)
[11:07] <Compn> are we talking double blind hydrogenaudio tests or just developer test s? :P
[11:07] <Compn> placebo controlled etc etc
[11:08] <rcombs> well, are there any tests at all?
[11:09] <rcombs> obviously the super placebo double-blind whatevers are preferable, but if somebody's listened to the output and said "that sounds better than the AC3 encoder" then that's at least some sort of a data point
[11:10] <nevcairiel> with the patch it beats ac3 at equal bitrates, but fdk is still far superior
[11:11] <rcombs> (now I want to make something called "heliumaudio" that does blind audio codec comparisons, but increases the pitch of everything)
[11:11] <rcombs> nevcairiel: how about FAAC? Or does nobody care enough to test against that anymore
[11:12] <nevcairiel> faac is pretty terrible
[11:12] <nevcairiel> as is vo-aacenc
[11:12] <nevcairiel> evne the unpatched encoder can beat those
[11:13] <Compn> just build in a static and white noise remover and you will win every test :P
[11:13] <rcombs> I knew vo-aacenc was awful :3
[11:13] <rcombs> didn't know faac was
[11:14] <Compn> people just hate on faac because of the license :P
[11:14] Action: Compn troolllls
[11:16] <nevcairiel> i have been pondering on just applying the latest magic patch in my binary, it can only be better than unpatched
[11:16] <rcombs> Compn: same applies to FDK :/
[11:16] <rcombs> nevcairiel: except \o/ assertion failures!
[11:16] <nevcairiel> comment out assertions!
[11:16] <nevcairiel> :D
[11:17] <rcombs> "what's the worst that could happen?"
[11:17] <rcombs> "let's find out"
[11:18] <rcombs> can that patch being finalized and merged be a christmas present for me
[11:18] <rcombs> I want to stop hedging when telling people that AAC is better than AC3
[11:18] <nevcairiel> i would also take opus in ts muxing support, i heard latest android can play that, which is my personal use-case :p
[11:19] <rcombs> where's the spec on that? I might be just bored enough to do it
[11:19] <nevcairiel> ask kierank
[11:19] <rcombs> (I like opus as much as the next guy)
[11:19] <kierank> nevcairiel: afaik android can't play opus in ts
[11:20] <rcombs> I should check if Chromecast can play Opus in Matroska
[11:22] <nevcairiel> chromecast at least claims opus support, not idea in what packages it like its opus
[11:23] <rcombs> probably MP4, at least
[11:23] <rcombs> and then I'd guess it probably handles it in MKV if whatever ffmpeg they're on does
[11:24] <Compn> what? you cant put any xiph in mp4
[11:24] <Compn> mp4 is lockdown! 
[11:24] <Compn> (we have one sample of vorbis and theora in mp4 and i know of nothing that can play it)
[11:25] <rcombs> there are a lot of things you shouldn't put in MP4 that people do anyway
[11:25] <rcombs> (there are a lot of things you shouldn't put in other things that people do anyway)
[11:26] <Compn> what is put in mp4 that shouldnt be ?
[11:26] <rcombs> apparently you have a vorbis and theora sample :P
[11:26] Action: Compn slaps forehead
[11:27] <rcombs> at least it's not MPEG-2
[11:27] <rcombs> MPEG-2 TS, how doth people mux AC3 in you, shall I count the ways
[11:27] <rcombs> (no, I shan't)
[11:28] <kierank> 2
[11:31] <rcombs> but yeah, I guess it's probably Matroska that Chromecast allegedly supports Opus in
[11:32] Last message repeated 1 time(s).
[11:32] <kierank> webm probably
[11:32] <rcombs> well, they advertise WebM, but they use ffmpeg's demuxer and aren't strict about codec contents or anything
[11:35] <rcombs> it's perfectly happy to play an MKV with H.264 and AAC (as is desktop Chrome)
[11:53] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.4:ce99ef48ea02: Treat all '*.pnm' files as non-text file
[11:53] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.4:575dc3a1b2ee: Merge commit 'ce99ef48ea025e90351079964d63be815374f089' into release/2.4
[12:39] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.4:b31a3c6f2670: Replace lena.pnm
[12:39] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.4:6607057d0e03: Merge commit 'b31a3c6f2670d4def5aa8bd3479da9c771ab09e2' into release/2.4
[12:57] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.4:60ccc1a748bf: Update changelog for v11.1
[12:57] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.4:1cc6fef0671c: Prepare for 11.1 Release
[12:57] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.4:309609ce4d75: Merge commit '60ccc1a748bf3d26201411479146d0798e1ecff9' into release/2.4
[12:57] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.4:db61d34e8309: Merge commit '1cc6fef0671c5522c952671ee06bf973135a22c4' into release/2.4
[13:03] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.4:93df243a59e4: avcodec/motion_est: use 2x8x8 for interlaced qpel
[13:03] <cone-903> ffmpeg.git 03Brad Smith 07release/2.4:89dbef732966: v4l2: Make use of the VIDIOC_ENUM_FRAMESIZES ioctl on OpenBSD
[13:46] <cone-903> ffmpeg.git 03Anton Khirnov 07release/2.2:871d99ef7733: mp3enc: fix a triggerable assert
[13:46] <cone-903> ffmpeg.git 03Anton Khirnov 07release/2.2:7fe5d0a78df5: lavu: add wrappers for the pthreads mutex API
[13:46] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:9181faab68a6: Merge commit '871d99ef77336069e5a8ece947c8160d9bc4d5ea' into release/2.2
[13:46] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:9bbed55b106f: Merge commit '7fe5d0a78df537542732aa7bd45962f7505255d0' into release/2.2
[13:46] <cone-903> ffmpeg.git 03Dave Yeo 07release/2.2:7394e53f30ca: libavutil/thread.h: Support OS/2 threads
[13:46] <cone-903> ffmpeg.git 03Dave Yeo 07release/2.2:1579f1463222: libavutil/threads.h: correct an include to be local
[14:14] <cone-903> ffmpeg.git 03wm4 07release/2.2:c790e31ae46d: lavu: fix memory leaks by using a mutex instead of atomics
[14:14] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:4ed83378bf85: Merge commit 'c790e31ae46d4304af893d04806ec9e3bff5ae28' into release/2.2
[14:14] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:93360af0d7bf: avutil/buffer: use the old atomics based code for the release branch
[14:14] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:dad7beaceb65: avutil/buffer_internal: leave the buffer pool entries volatile
[14:38] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.2:2bcd8f22f2fa: Treat all '*.pnm' files as non-text file
[14:38] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:afcd152b973e: Merge commit '2bcd8f22f2fae253d87b11a5c9f8805d79253180' into release/2.2
[14:38] <cone-903> ffmpeg.git 03Andreas Cadhalpun 07release/2.2:394d3c937a76: Remove non-free tests/lena.pnm and adapt FATE tests to depend on lena.pnm in the SAMPLES directory
[15:04] <cone-903> ffmpeg.git 03Reinhard Tartler 07release/2.2:d1c2f86b21b9: Replace lena.pnm
[15:04] <cone-903> ffmpeg.git 03Michael Niedermayer 07release/2.2:5111c78eab4d: Merge commit 'd1c2f86b21b96c27fac200209f52c98dcb2b3194' into release/2.2
[15:33] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:ea5423a01716: lavc/dirac_arith: Only compile x86 asm if ARCH_X86 is set.
[15:33] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:7f6515e49100: Also print GUIDs as shown in the Windows registry to ease debugging.
[15:33] <cone-903> ffmpeg.git 03Carl Eugen Hoyos 07master:f151f5415a19: lavf/qcp: Print unknown GUID on error.
[16:01] <cone-903> ffmpeg.git 03Benoit Fouet 07master:543fceba9ca9: apng: move shared header from avformat to avcodec.
[16:07] <kierank> oh that's a shame
[16:08] <kierank> i can't send a patch to remove tinterlace because kerndeint depends on it in fate
[16:08] <kierank> koda: can we  deprecate tinterlace instream
[16:08] <kierank> instead*
[16:08] <cone-903> ffmpeg.git 03Benoit Fouet 07master:d7716961a856: avformat/apngdec: exit probing when skipping is not possible.
[16:10] Action: ubitux discovers --msvc-syntax in pkg-config
[16:10] <kierank> nobody has explained to me wtf the others are for
[16:11] <koda> kierank: sorry?
[16:11] <kierank> can we deprecate tinterlace
[16:12] <koda> WFM
[16:12] <kierank> how do you do that
[16:14] <koda> add proper ifdefs? or what do you mean?
[16:14] <kierank> I want to deprecate the entire filter
[16:14] <kierank> how do I do that
[16:15] <koda> you just add FF_API to allfilters to deprecate the whole filter
[16:15] <koda> allfilters.c
[16:16] <ubitux> and you document it in doc/filters.texi and Changelog
[16:16] <ubitux> you also print a warning at the usage
[16:16] <koda> and bump version.h ofc
[16:17] <ubitux> av_log(ctx, AV_LOG_WARNING, "This filter is deprecated, use interlace instead\n"); in init()
[16:17] <ubitux> @emph{This filter is deprecated. Use @ref{interlace} instead.} in doc/filters.texi
[16:19] <ubitux> tinterlace was originally in mplayer an opposite of tfields
[16:19] <ubitux> that's why some modes might be "weird"
[16:21] <ubitux> then this: https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-April/041786.html
[16:22] <ubitux> for more info on the original tinterlace: https://github.com/mpv-player/mpv/commit/1e87b4bbaa5dbc2ab0e8c8084ecece30ada91ddc
[16:22] <ubitux> these 2 needs to be taken into consideration i suppose
[16:23] <ubitux> i don't know the details, but someone willing to drop it should check if anything isn't relevant there
[16:30] <kierank> mode 4 is what most people would expect the filter to do
[16:30] <kierank> and is the same as vf_interlace
[16:30] <kierank> the others are just random crap
[16:41] Action: Daemon404 just shakes his head at this lena licensing stuff
[16:50] Action: kierank shakes his head at tinterlace
[16:50] Action: koda just shakes his head
[17:03] <TimNich> kierank: mode 0 reverses the il filter, and mode 5 is useful for NTSCy stuff
[17:04] <ubitux> kierank: well then you could alias interlace on "tinterlace=4"
[17:08] <kierank> ok
[17:12] <ubitux> tinterlace are useful post separatefields i suppose
[17:12] <ubitux> like, you want to process each fields independently
[17:12] <ubitux> then remerge then
[17:13] <koda> ubitux: kierank or vice versa ;)
[17:13] <kierank> ok
[17:13] <ubitux> mode 1 and 2 could be replaced with a select filter though
[17:15] <ubitux> i don't know the usage of mode 3 (pad); debugging?
[17:16] <ubitux> mode 6 describes a use case
[17:16] <ubitux> so mode 1 and 2 looks just redundant with select, and only mode 3 might need a use case
[17:17] <ubitux> so it doesn't look all that crap
[17:17] <ubitux> i guess interlace could be merged into tinterlace
[17:17] <ubitux> and aliased
[17:19] <koda> the opposite would be more correct
[17:20] <ubitux> maybe mode 3 can be use to test interpolation
[17:20] <ubitux> koda?
[17:20] <kierank> the fundamental problem is you need to spend ages figuring out which one you need and 99% of people want 4
[17:20] <kierank> i.e vf_interlace
[17:20] <ubitux> sure, well then again, just an alias
[17:20] <ubitux> you add a special interlace_init in tinterlace
[17:21] <ubitux> to map "interlace" to "tinterlace" with mode 4
[17:21] <koda> ubitux: tinterlace has a misleading name, so it would be more correct deprecated it and either rename it appropriately
[17:21] <koda> and if there is any more interlace-related thing in it, move it to interlace instead
[17:22] <ubitux> so rename tinterlace to interlace, and alias tinterlace on interlace with mode 0 ("merge")?
[17:23] <koda> youre back to square 1, then interlace would do stuff that its not related to interlacing
[17:25] <ubitux> then i missed your point
[17:25] <ubitux> didn't you suggest to rename tinterlace?
[17:25] <kierank> he wants to get rid of all junk in tinterlace
[17:26] <koda> yes but to something completely different
[17:26] <kierank> iltools or something
[17:26] <koda> like vf_linepad or something
[17:26] <kierank> but at the moment it's just random stuff
[17:26] <ubitux> linepad?
[17:26] <ubitux> wtf.
[17:29] <cone-903> ffmpeg.git 03Rong Yan 07master:b4d41beebe86: avcodec/ppc/lossless_audiodsp_altivec: POWER LE support for scalarproduct_and_madd_int16_altivec()
[17:35] <ubitux> anyway, it's just all about interfaces, so i'd just refactor both code in the same file to start with
[17:36] <ubitux> then we can explicit the doc, just like latest patch from michaelni 
[17:55] <kierank> lol "critical"
[18:02] <ubitux> anyway, going to merge the two code (no interface change)
[18:08] <kierank> michaelni: you're missing the point still
[18:09] <kierank> the point is that most of the tinterlace filters have little/nothing to do with interlacing
[18:11] <koda> s/most/all/
[18:13] <kierank> mode=4 is actual interlacing
[18:18] <koda> kierank: does not handle pts correctly
[18:18] <koda> or it didnt when it was spin off
[18:18] <koda> now both are broken anyway
[18:26] <Mista_D> kierank: upgraded to critical to highlight that a broken TS file is generated without any warnings.
[18:32] <ubitux> http://b.pkh.me/0001-avfilter-tinterlace-merge-code-with-interlace.patch
[18:32] <ubitux> i guess that should do it
[18:33] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:59f1f764d6cd: avfilter/vf_tinterlace: Favor using standard timebases for the output
[18:37] <ubitux> can be simplified even further and prettified
[18:38] <koda> ubitux: nice
[18:41] <michaelni> koda / ubitux: yes looks nice (from a quick look)
[18:42] <ubitux> there is one thing remaining: the fact that interlace doesn't do the interlacing if the frame are marked as interlaced
[18:45] <ubitux> also, i suppose we need to figure out the thing about timestamps?
[18:45] <ubitux> or you guys came to an agreement?
[18:46] <koda> ubitux: michaelni applied the list of framerates on tiniterlace and (hopefully) will just revert the one on interlace
[18:47] <koda> maybe that codepath can be shared when the filters are merged
[18:47] <ubitux> that's what my patch does
[18:47] <ubitux> the kept behaviour is the one of tinterlace
[18:55] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:46b64e309895: Revert "avfilter/vf_interlace: more accurate pts calculation"
[19:17] <ubitux> so is tinterlace=interleave_{top,bottom} behaving as people expect it to now?
[19:18] <ubitux> or it's needed to pass the exact_tb flag?
[19:47] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:68b8e21b8bac: avcodec/aacdec: Use avpriv_float_dsp_alloc()
[19:56] <cone-903> ffmpeg.git 03Nicolas George 07master:cfcaf6b38e39: configure: add optional pkg-config helper and use it.
[19:56] <cone-903> ffmpeg.git 03Nicolas George 07master:6c96aa06066d: configure: add a note about pkg-config --static.
[19:56] <cone-903> ffmpeg.git 03Michael Niedermayer 07master:9adc999d2a92: Merge remote-tracking branch 'cigaes/master'
[21:37] <cone-640> ffmpeg.git 03Luca Barbato 07master:7464e98f74c0: aac: Simplify decode_mid_side_stereo
[21:37] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:61d0a6dd9554: Merge commit '7464e98f74c03d3efa0cdc8d7abad06e4c3c277a'
[21:45] <cone-640> ffmpeg.git 03Vittorio Giovara 07master:604c9b1196c7: rtsp: move the CONFIG_ macros to the beginning of the check
[21:45] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:1537d0b432d8: Merge commit '604c9b1196c70d79bbbc1f23e75f6a8253a74da3'
[21:54] <cone-640> ffmpeg.git 03Vittorio Giovara 07master:5639ed9abb58: mov: do not truncate the language-prefixed tag
[21:54] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:d0b0fe6691fc: Merge commit '5639ed9abb58311f82cf3499b682d228290adb09'
[22:12] <cone-640> ffmpeg.git 03Lukasz Marek 07master:8b0226f2a6d7: ffserver: use avcodec_copy_context to copy context
[22:12] <cone-640> ffmpeg.git 03Lukasz Marek 07master:c8ac46e92475: ffserver_config: remove useless defaults
[22:12] <cone-640> ffmpeg.git 03Lukasz Marek 07master:2f4233614a7f: ffserver_config: set defaults basing on absence of set value
[22:12] <cone-640> ffmpeg.git 03Lukasz Marek 07master:302ed9c43f2d: ffserver_config: print warning when using default value
[22:19] <cone-640> ffmpeg.git 03Vittorio Giovara 07master:e352b293712f: mov: Add an option for exporting all metadata
[22:19] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:781a5a392c4d: Merge commit 'e352b293712ff7cbde67eba3ce3f8510b037de09'
[22:33] <cone-640> ffmpeg.git 03Thilo Borgmann 07master:3cec81f4d4f2: mov: allocate the tag value dynamically
[22:33] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:02444f02f17d: Merge commit '3cec81f4d4f26b62bc2d22bb450bbf51ec3a7f09'
[22:34] <lukaszmluki> Hi someone may close tickets #1461 #1275. I co do it myself if allowed
[22:38] <llogan> lukaszmluki: i can. as fixed? could you provide me the commit hashes that fix them?
[22:38] <llogan> actually i'll just give you the permissions
[22:39] <ubitux> lukaszmluki: don't forget to mention the hash of the commit when closing
[22:39] <llogan> lukaszmluki: mastered?
[22:39] <lukaszmluki> yes
[22:40] <lukaszmluki> ok, i will close later, I have to find this hashes
[22:40] <lukaszmluki> thanks
[22:41] <llogan> it shows that you are already in developer group which should be able to modify tickets
[22:42] <lukaszmluki> OK
[22:45] <lukaszmluki> Seems to work, thx
[22:49] <cone-640> ffmpeg.git 03Jon Morley 07master:26e20dfd06ac: options_table: fix colorspace minimum option value
[22:49] <cone-640> ffmpeg.git 03Fredrik Axelsson 07master:8f8caca2242e: Add support for BDAV/m2ts-mode muxing
[22:49] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:fc469e5c7f4a: Merge commit '26e20dfd06ac62da596a9549867f990f1200a04e'
[22:49] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:d76adfae9cbc: Merge commit '8f8caca2242e1fe05f37493cfabcd3f4de198550'
[22:55] <ubitux> FYI (to be confirmed): adding slice threading to [t]interlace makes absolutely no positive difference
[22:59] <kierank> ubitux: even on /dev/zero
[22:59] <kierank> ?
[22:59] <ubitux> i'm using testsrc with 720p
[22:59] <ubitux> i get less fps everytime i add a thread
[22:59] <ubitux> :p
[22:59] <kierank> ok
[23:00] <ubitux> (even without the asm)
[23:00] <kierank> v210 could be threaded :)
[23:01] <ubitux> damn i wasted some time on this :p
[23:02] <cone-640> ffmpeg.git 03Jean-Baptiste Mardelle 07master:7319a47c7e79: mpegtsenc: recognize .mts as MPEG Transport Stream
[23:02] <cone-640> ffmpeg.git 03Florent Le Coz 07master:2e0935965b82: Drop the unofficial extension prefix for MPEG and MPEG-TS formats
[23:02] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:b329460c5186: Merge commit '7319a47c7e7931ebf8f475cc2cffc7bcd333acee'
[23:02] <cone-640> ffmpeg.git 03Michael Niedermayer 07master:ebc29e8625b0: Merge commit '2e0935965b824bc641b7e0bafafcbb1e36027f79'
[23:02] <ubitux> anyway
[23:02] <ubitux> still no comment on the edit list support?
[23:02] <ubitux> i thought people would have been interested in that
[23:02] <ubitux> i guess i'll have to add the support in ffmpeg to make a difference
[23:02] Action: Daemon404 looks at ML
[23:03] <rcombs> ubitux: I don't actually understand what those are!
[23:03] <Daemon404> theyre fun
[23:03] <Daemon404> thats what they are
[23:04] <rcombs> is it that "ordered chapters for MP4" thing Final Cut uses?
[23:04] <rcombs> fun, fun
[23:04] <JEEB> yeah, you can even link single samples
[23:04] <JEEB> :D
[23:05] <rcombs> ubitux: well I'd like to see it if it'd lay infrastructure that'd make MKV ordered chapters in ffmpeg.c easier
[23:05] <rcombs> assuming you mean for decoding
[23:05] <ubitux> rcombs: you basically have a video or audio track, and you can say "the presentation must read from 10 seconds to 40 seconds and then from 45 seconds to end, but just the video. for the audio you will pick from 25 seconds to ..." etc etc
[23:05] <ubitux> that's actually very simple editing
[23:05] <JEEB> but yeah, it's much more complex and capable than the segment linking and virtual timelines of matroska
[23:05] <JEEB> at least in its full feature set
[23:05] <rcombs> so even _more_ complicated than MKV ordered chapters!
[23:06] <ubitux> there is also an idea of "start playing the audio track only after 10 seconds the main presentation started"
[23:06] <JEEB> uh, where do you think that stuff got its idea most probably :D
[23:06] <Daemon404> ubitux, so the idea is to run avformat_frame_honor_timeline on all the avframes output
[23:06] <ubitux> Daemon404: yeah
[23:06] <Daemon404> and it can possibly modify them if it returns 1
[23:06] <Daemon404> for e.g. audio
[23:06] <ubitux> yeah
[23:06] <ubitux> it actually also adjust the pts
[23:06] <JEEB> rcombs, you can go read qtff.pdf I guess and laugh maniacally at the complexity it'd let you use
[23:06] <Daemon404> i see
[23:06] <ubitux> (because the editing creates gaps and you have to stick them back together)
[23:07] <Daemon404> yeah i kniow
[23:07] <ubitux> that is, how i understood it
[23:07] <Daemon404> i implented edit list support before ubitux ;)
[23:07] <ubitux> and it seems to work somehow
[23:07] <ubitux> Daemon404: ah? okay
[23:07] <Daemon404> yeah in the layer above avformat
[23:07] <Daemon404> using info from lsmash
[23:07] <Daemon404> i think the design is pretty sane
[23:08] <Daemon404> the only derp i think is
[23:08] <Daemon404> The function will return 0 if
[23:08] <Daemon404> the frame should not be part of the presentation. Otherwise, it will
[23:08] <Daemon404> return 1, with adjusted timestamps if necessary.
[23:08] <Daemon404> this is the opposite of most av funcs
[23:08] <Daemon404> usually 0 = success
[23:08] <ubitux> dropping is actually a success as well
[23:08] <ubitux> initially i returned the frame
[23:08] <ubitux> (or NULL)
[23:09] <rcombs> does it have MKV-like "codecs and parameters must match between segments" requirements, too?
[23:09] <ubitux> but i realized i could just use the return value as a got_frame override
[23:09] <ubitux> and it simplified the workflow
[23:09] <Daemon404> well, it's a nit
[23:09] <Daemon404> rcombs, i dont think so
[23:10] <ubitux> rcombs: no but it says it must be able to cut audio frames in the middle typically
[23:10] <Daemon404> but dont quote me
[23:10] <Daemon404> mp4 edit lists are applied during presentation
[23:10] <rcombs> fun, fun
[23:10] <Daemon404> so codec is irrelevant
[23:10] <ubitux> rcombs: ...just to prevent people from implementinf this in the demuxer...
[23:10] <JEEB> :D
[23:10] <ubitux> (which we did anyway partially)
[23:10] <Daemon404> well exporting data isnt really "in the demuxer"
[23:11] <rcombs> so, what, ffmpeg.c would have to handle it via extensive auto-additions of concat and trim filters based on exported extradata?
[23:11] <Daemon404> so ubitux i havent looked at the code, but the idea seems pretty reasonable.
[23:11] <Daemon404> rcombs, no filters should be needed
[23:11] <ubitux> i mean, if the segment were defined on a packet segmentation we could have done it in the demuxer transparently
[23:11] <Daemon404> nah, i think it is correct to do it this wya
[23:11] <Daemon404> even if that was the case
[23:11] <ubitux> maybe
[23:11] <ubitux> i see 2 main problems personally
[23:12] <ubitux> first one is basically the user might end up with large gaps
[23:12] <Daemon404> ? what do you mean
[23:13] <ubitux> mmh wait
[23:13] <ubitux> well, it needs to be checked
[23:13] <Daemon404> as in for sanity?
[23:13] <ubitux> but like, how is our demuxer raising the packets?
[23:13] <Daemon404> raising?
[23:13] <ubitux> typically if you have a stream with a gap of 1 hour in the middle
[23:14] <ubitux> are you going to get about 1 hour of audio packets before you get the next valid video packets?
[23:14] <ubitux> it looks like so to me
[23:14] <ubitux> so the demuxer should be adjusted to somehow read the edit list to send as soon as possible approximately all the "NULL" packets
[23:15] <Daemon404> you mean if you have a 2 hr file with an hour edited out in the middle?
[23:15] <Daemon404> via edts
[23:15] <ubitux> let's say V: 1 minute video + 1 hour video dropped with the edit list + 1 minute video, and A: 2 minute audio
[23:15] <rcombs> what does movenc use edts for?
[23:16] <Daemon404> ubitux, so youre mostly thinking its a problem for perf?
[23:16] <ubitux> actually, let's say V: 1 minute video + 1 hour video dropped with the edit list + 30 minute video, and A: 32 minutes audio
[23:16] <ubitux> aren't you going to get 32 minutes of audio packets
[23:17] <ubitux> before you get minute 1+ of audio?
[23:17] <Daemon404> i.e. fill up all of my ram?
[23:17] <ubitux> yeah kinda
[23:17] <Daemon404> i get what youre saying
[23:17] <Daemon404> but we already have this problem on normal streams
[23:17] <Daemon404> it's nto specific to timelines
[23:18] <Daemon404> streams where audio and video are interlaved veyr poorly
[23:18] <ubitux> ok
[23:18] <ubitux> well anyway that's the first problem
[23:19] <ubitux> and the second one is about mkv features: it probably doesn't cover them at all
[23:19] <Daemon404> it doesnt
[23:19] <ubitux> and it won't be enough to deal with external resources
[23:19] <Daemon404> mkv has a bunch of crap nothing btu haali supports still
[23:19] <Daemon404> mayeb wm4 too
[23:19] <Daemon404> like the concept of editions
[23:19] <Daemon404> multiple timeliens in one file, can use any video or audio stream
[23:19] <ubitux> so what are the features of editions?
[23:19] <JEEB> LAV supports editions
[23:19] <Daemon404> and you can select which timeline to view
[23:19] <JEEB> ubitux, multiple timelines
[23:20] <JEEB> Daemon404, the stream selection was a haali-specific thing
[23:20] <Daemon404> i see
[23:20] <Daemon404> it was pretty ugly
[23:20] <nevcairiel> its a kinda neat feature honestly, but the spec for it is just never defined anywhere
[23:20] <ubitux> can you switch timeline at runtime? :P
[23:20] <JEEB> yes
[23:20] <JEEB> nevcairiel, aye
[23:20] <Daemon404> nevcairiel, so par for the course for mkv?
[23:20] <rcombs> did someone say "Haali a shit"?
[23:20] <ubitux> it might be possible with that api i'm proposing
[23:20] <JEEB> unfortunately the whole matroska more or less is like that :|
[23:20] <rcombs> no?
[23:20] <ubitux> i'm more afraid of repeating stuff
[23:20] <rcombs> well I'm saying it
[23:21] <ubitux> typically
[23:21] <ubitux> because currently the api i'm proposing just optionnaly drop
[23:21] <JEEB> rcombs, if nothing else he was good at maintaining revision control
[23:21] <ubitux> it doesn't make possible dup or similar
[23:21] <JEEB> I have his revision log since 2003 or 2004
[23:21] <Daemon404> ubitux, but how do you differentiate between timelines?
[23:21] <ubitux> so we will probably need a totally different approach for mkv
[23:21] <rcombs> ubitux: oh btw I'm working on implementing charenc guessing at the FFDemuxSubtitlesQueue level
[23:21] <Daemon404> right
[23:22] <ubitux> rcombs: i really don't want to have anything to do with character encoding anymore; i let you deal with that with wm4 and his best friend
[23:22] <Daemon404> guessing hoes in the player IMO
[23:22] <Daemon404> thats all i have to say on the subject
[23:22] <rcombs> ubitux: I wish I could not have anything to do with character encoding :/
[23:22] <nevcairiel> gotta like people that flame every attempt at changing things but never finish their grand promised plans :p
[23:22] Action: Daemon404 is more interested in timelines
[23:23] <ubitux> well, anyway, if someone sees a better design for the api
[23:23] <ubitux> so it could be adjusted more easily for mkv
[23:23] <ubitux> these comments are very welcome
[23:23] <Daemon404> i dont have an idea how to do mkv well
[23:23] <Daemon404> it's pretty derpy
[23:23] <Daemon404> mkv has the usual problem of trying to do everything
[23:23] <rcombs> ff_subtitles_queue_finalize seems a good place to do the actual guessing
[23:24] <ubitux> rcombs :)
[23:24] <Daemon404> ubitux, btw +1 for opaque pointer
[23:24] <Daemon404> public sturcts ftl
[23:24] <nevcairiel> mkv gets messy when you combine the concept of external segments into the mix
[23:25] <rcombs> nevcairiel: does MP4 edts use paths instead of UUIDs?
[23:25] <nevcairiel> i have no clue how mp4 works
[23:25] <ubitux> rcombs: edts really is just what my patch supports
[23:25] <ubitux> it's different from fragments
[23:26] <rcombs> oh joy
[23:26] <Daemon404> what
[23:26] <Daemon404> fragments are unrelated to that
[23:26] <Daemon404> youre thinking of dref.
[23:26] <rcombs> well, whatever the thing MP4 does is, does it use paths instead of UUIDs, then?
[23:27] <Daemon404> dref uses paths to files yes
[23:27] <ubitux> rcombs: edts are just: 1) start time of the stream in the presentation 2) time segment to be played at a given rate in these stream
[23:27] <Daemon404> or urls
[23:27] <ubitux> rcombs: that's all the information there is
[23:27] <Daemon404> (yeah urls. really.)
[23:28] <Daemon404> and if you mean DASH, then DASH segments, subsegments, and fragments are all something enirely differenty
[23:28] <Daemon404> LONG LIVE MP4
[23:28] <JEEB> edts is basically the virtual timelines, and drefs is the segment linking part, I guess?
[23:28] <Daemon404> external tracks
[23:29] <JEEB> but I remember being able to take in even single samples from an external reference?
[23:29] <nevcairiel> due to the terrible support for either feature, luckily no crazy anime people picked up on using those :p
[23:29] <JEEB> I remember listening to a lecture by VMani
[23:29] <Daemon404> anime people dont use mp4 really
[23:29] <Daemon404> so.
[23:29] <JEEB> about this stuff
[23:29] <rcombs> Daemon404: except for toaster re-encodes
[23:29] <nevcairiel> they might if it offered some crazy ass features they like
[23:29] <JEEB> anime people almost used mp4 as is shown by that one early sample in cccp's archives
[23:29] Action: Daemon404 beats rcombs with YIFY too
[23:29] <ubitux> Daemon404: yeah, because mp4 is shitty in regards to at least subtitles :p
[23:30] <JEEB> but the implementations then showed the way
[23:30] <Daemon404> ubitux, i inherited the subtitles/captions project and support at work btw
[23:30] <JEEB> and mp4 was not it
[23:30] <rcombs> is YIFY anime too now?
[23:30] <Daemon404> rcombs, no
[23:30] <Daemon404> same idea tho
[23:30] <ubitux> Daemon404: nice
[23:30] <ubitux> Daemon404: so when are you subtitles patches landing in FFmpeg?
[23:30] <Daemon404> never
[23:30] <ubitux> your*
[23:30] <ubitux> :(((
[23:30] <Daemon404> ffmpeg is not used
[23:30] <Daemon404> only actual subtitle files are needed
[23:30] <Daemon404> not embedded
[23:30] <ubitux> we have support for those!
[23:31] <ubitux> some of them/
[23:31] <Daemon404> perhaps i do not enjoy smashing my testicles with a hammer
[23:31] <rcombs> what do said patches do
[23:31] <Daemon404> rcombs, they dont exist
[23:31] <Daemon404> so theyre do that.
[23:31] <rcombs> \o/
[23:31] <wm4> rcombs: I maintain that the character encoding guessing shouldn't be hardcoded in the demuxer
[23:31] <rcombs> wm4: where would you put it?
[23:31] Action: Daemon404 would do it after demuxing in player
[23:32] <wm4> rcombs: somewhere separate, but I don't know which libavbullshit
[23:32] <wm4> maybe libavutil... but no packets there
[23:32] <Daemon404> why do it in libav* at all
[23:32] <Daemon404> i dont get it
[23:32] <wm4> or maybe libavformat is fine, my point is it shouldn't be forcibly bound to AVFormatContext
[23:32] <kierank> Daemon404: gotta do everything in libav*
[23:32] <ubitux> damn i need to get done with the subtitles thing too...
[23:33] <rcombs> wm4: in what use-case is having it done in AVFormatContext problematic?
[23:33] <Daemon404> kierank, k ill send my patch to boot directly into ffmpeg
[23:33] <Daemon404> it will, of course, be in libavdevice
[23:36] <wm4> rcombs: what if the user changes the encoding? what if interactive selection is needed (suppose the detector has multiple guesses)?
[23:36] <ubitux> so anyway, i can make the function to honor the timeline take an extra timeline id for mkv support
[23:36] <ubitux> but what else would i need?
[23:36] <wm4> rcombs: please don't implement stuff that makes sense for ffmpeg.c only
[23:37] <wm4> ubitux: where is that timeline patch?
[23:37] <ubitux> wm4: https://ffmpeg.org/pipermail/ffmpeg-devel/2014-December/166163.html
[23:37] <rcombs> wm4: hmm, could still have it in the demuxer but have functions to get a list of guesses and to pick one
[23:38] <wm4> rcombs: and also, there are many charset detector, and possibly many ways to select a preferred charset based on file source and user settings
[23:39] <rcombs> wm4: right, so I need to expose the relevant configuration settings for each available detector
[23:39] <wm4> ubitux: needing the format context in the decoder is fucked up
[23:39] <wm4> ubitux: e.g., what if they're not in the same thread?
[23:39] <rcombs> e.g. for libguess, the language type/region; for enca, the whole struct of various settings
[23:40] Action: Daemon404 uses ICU, the moster
[23:40] <rcombs> might be easiest to just have the consumer set all of those things
[23:40] <rcombs> Daemon404: does ICU have a charenc detector too?
[23:40] <Daemon404> yes
[23:40] <ubitux> wm4: it's read only, i should add a const
[23:40] <rcombs> &maybe this should be modular
[23:40] <Daemon404> as does chardet
[23:40] <Daemon404> that mozilla thing
[23:40] <rcombs> universalchardet?
[23:40] <Daemon404> yest hat
[23:40] <wm4> ubitux: it's still terrible... it would be cleaner to export the timeline thing as a separate struct
[23:41] <ubitux> i guess i could just ask to pass the timeline directly
[23:41] <rcombs> C++ fuckers
[23:41] <Daemon404> C api = dont care if its c++
[23:41] <rcombs> does it have a C API?
[23:41] <rcombs> I was under the impression it didn't
[23:42] <wm4> rcombs: currently I'm trying to get a C++ thing to work that spams 3 pages of errors because 1 line is wrong
[23:42] <rcombs> if it does, then OK, that's cool
[23:42] <rcombs> wm4: \o/
[23:42] <nevcairiel> ubitux: does this thing necessarily have to operate on decoded frames? that seriously limits its capabilities in apps that decouple demuxing and decoding cleanly
[23:42] <ubitux> nevcairiel: yes
[23:42] <nevcairiel> wm4: templates are fun?
[23:42] <Daemon404> nevcairiel, you have to apply edts at presentation time
[23:42] <ubitux> nevcairiel: otherwise i would have implemented it transparently in the demuxer
[23:42] <Daemon404> full stop
[23:43] <wm4> templates + preprocessor garbage (hello Qt)
[23:43] <nevcairiel> guess i'll just tell people to bugger off then
[23:43] <wm4> so, what if the codec or the demuxer changes?
[23:44] <Daemon404> wm4, close
[23:44] <wm4> how will this api work then? (my guess: not at all)
[23:44] <Daemon404> templates + preprocessor garbage + extensions to c++
[23:44] <Daemon404> fuck yeah moc
[23:44] <nevcairiel> isnt moc just another preprocessor
[23:44] <Daemon404> yes
[23:44] <Daemon404> but it's not *the* preprocessor
[23:45] <ubitux> wm4: consider the prototype is now int avformat_frame_honor_timeline(const void *timeline, AVFrame *f, int sid);
[23:45] <wm4> what's sid?
[23:45] <ubitux> but you will still have to fetch the timeline from the format
[23:45] <ubitux> stream id
[23:46] <ubitux> (because i can't get it from the frame)
[23:47] <wm4> anyway, I don't get how you seek or switch source demuxers/decoders with this...
[23:48] <ubitux> not sure what you mean
[23:52] <wm4> suppose you have multiple segments, segment 1 and 2
[23:52] <wm4> where do you start decoding?
[23:52] <wm4> it's not really clear to me how avformat_frame_honor_timeline() is used at all
[23:54] <ubitux> you decode everything
[23:54] <ubitux> and you filter out with the honor timeline thing
[23:54] <ubitux> (which will also transparently drops the gaps by adjusting the timestamps)
[23:54] <wm4> does it involve quantum mechanics?
[23:54] <Daemon404> i see what wm4 means
[23:54] <Daemon404> like
[23:54] <nevcairiel> for playback this seems really super inefficient, wouldnt most players just hang when you try to skip a longer part?
[23:54] <Daemon404> e.g. you want to draw a seekbar
[23:54] <wm4> decode everything at the same time or something
[23:55] <Daemon404> how do you do it
[23:55] <Daemon404> without decoding teh entire file
[23:55] <ubitux> the seek bar is defined by the duration of the presentation?
[23:55] <wm4> maybe my initial bad idea wasn't so bad
[23:56] <Daemon404> ubitux, and how do you e.g. seek to 4mins in
[23:56] <Daemon404> what if its really 1min+1hrskip+5min
[23:56] <Daemon404> or something
[23:56] <ubitux> you're not supposed to rely on the duration of the streams
[23:56] <wm4> which was: make the demuxer output the packets that are going to be needed for presentation, and for audio, mark start/end in the packets themselves
[23:56] <ubitux> just the duration of the presentation
[23:56] <Daemon404> yes but how do yo useek to a point in the presentation
[23:56] <ubitux> what you will see in the total duration is probably 6 minutes in this case
[23:56] <Daemon404> you cant.
[23:56] <Daemon404> not without knowledge of the timeline
[23:57] <wm4> even without seeking
[23:57] <nevcairiel> Even simpler, what happens when you watched through the first minute, do you have to wait until it decoded an hour worth of content until it continues? PCs aren't that fast yet :p
[23:57] <ubitux> the duration for the presentation is probably well set by the demuxer
[23:57] <wm4> how do you switch segments?
[23:58] <ubitux> you don't?
[23:58] Action: ubitux probably doesn't get it
[23:58] <wm4> neither do I
[23:58] <ubitux> nevcairiel: yes that's the interleaving problem i was talking about with Daemon404 
[23:58] <Daemon404> you cannot seek to e.g. 4 mins in, because av_seek_* is nto timeline aware
[23:58] <Daemon404> and you dont know how the timeline maps to the original file
[23:58] <Daemon404> because the timeline is opaque
[23:58] <ubitux> yeah, it will end up decoding a bunch of frame until you get a valid one
[23:59] <ubitux> but again you would have the same problem with just playback
[23:59] <Daemon404> yeah but where do you even seek to?
[23:59] <Daemon404> timelines dotn necessarily have to be in cronolical order iirc
[23:59] <ubitux> it will probably happen in the gap
[23:59] <ubitux> so you will have to decode a bunch of frames
[23:59] <ubitux> until you get a displayable one
[00:00] --- Wed Dec  3 2014