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

[burek]

[01:35:14 CEST] <kierank> ubitux: thank you i guess
[02:52:12 CEST] <_marco> I have a 24MB .ts file recorded from a tv set which I don't know the format but would like to know if anyone is able to reverse engineer it. Where do you suggest me to ask about?
[02:59:29 CEST] <kierank> a ts is an mpeg-transport stream
[02:59:33 CEST] <kierank> it's a standard format
[02:59:39 CEST] <kierank> if it doesn't open in ffmpeg then it's encrypted
[03:15:56 CEST] <_marco> kierank: is there any simple way to decrypt it?
[03:16:02 CEST] <kierank> no
[03:16:17 CEST] <kierank> read the specs, understand what's going on etc
[03:16:52 CEST] <_marco> the footer of the file has some unencrypted streams
[03:17:02 CEST] <_marco> I mean strings, not streams
[03:17:15 CEST] <kierank> then maybe it's not a ts
[03:18:21 CEST] <_marco> the beginning of the file has some repeated patterns of 47 1f ff 10
[03:18:38 CEST] <_marco> for about 188k, the some data starts
[03:19:16 CEST] <kierank> that's a transport stream header
[03:19:30 CEST] <_marco> a null header, AFAIK
[03:19:42 CEST] <kierank> what does ffmpeg -i file.ts say?
[03:19:47 CEST] <kierank> or ffprobe file.ts
[03:20:42 CEST] <_marco> ffmpeg -i gives "could not find codec parameters"; stderr is filled with "[mpegts @ 0x749980] Continuity check failed for pid 301 expected 9 got 8"
[03:21:07 CEST] <kierank> probably encrypted then
[03:22:57 CEST] <_marco> kierank: is there any program able to find a header a frame header in the middle of the stream and try to extract some video?
[03:23:06 CEST] <kierank> that's what ffmpeg tries to do
[04:16:17 CEST] <LRUB> Hello!
[04:16:46 CEST] <LRUB> Problem in compilation with enable shared.
[04:19:28 CEST] <LRUB> Error 1:
[04:19:28 CEST] <LRUB> http://pastebin.com/8uQb1EPE
[04:20:00 CEST] <LRUB> Error 2:
[04:20:00 CEST] <LRUB> Test api-flac failed. Look at tests/data/fate/api-flac.err for details.
[04:20:00 CEST] <LRUB> tests/Makefile:202: recipe for target 'fate-api-flac' failed
[04:20:00 CEST] <LRUB> make: *** [fate-api-flac] Error 127
[04:20:00 CEST] <LRUB> root at pangas:/home/pangas/Programas-e
[04:20:41 CEST] <LRUB> Error 1:
[04:20:41 CEST] <LRUB> make && make check
[04:20:41 CEST] <LRUB> Error 2:
[04:20:41 CEST] <LRUB> make -j4 && make check
[04:23:11 CEST] <cone-463> ffmpeg 03Michael Niedermayer 07master:8623aba04368: doc/codecs: Document color_range for the input side
[04:26:46 CEST] <LRUB> ??
[04:32:26 CEST] <LRUB> Hello?
[04:48:37 CEST] <LRUB> Hello
[04:48:39 CEST] <LRUB> ?!
[04:49:21 CEST] <jamrial> LRUB: are you using the latest git version of ffmpeg? the first error shouldn't happen anymore
[04:49:28 CEST] <jamrial> no idea about the second error
[04:51:31 CEST] <LRUB> Yes. The latesd version.
[04:51:40 CEST] <LRUB> *latest
[04:52:51 CEST] <jamrial> no idea why it happens then. linking problems with shared builds were supposedly fixed a few weeks ago
[05:22:58 CEST] <LRUB> Once typed make install after the error in "make check". It worked. but one dependency (which I had installed) showed error. Function not found in the library. And I could not even do stream.
[05:23:54 CEST] <LRUB> I'am pruducer and video editor.
[05:24:24 CEST] <LRUB> *producer
[05:28:39 CEST] <LRUB> FFMPEG is extremelly necessary.
[05:55:45 CEST] <LRUB> Forget it.I was doing it because of the "Open Broadcast", which fails to compile. But I will have to look for one that has the functions to select, resize and move each separate window during the stream.
[05:55:45 CEST] <LRUB>  Who know a good, tell me. =)
[06:03:16 CEST] <cone-463> ffmpeg 03Rostislav Pehlivanov 07master:ef8e5a61c85d: aacenc: Move small misc. functions to a separate file
[08:22:23 CEST] <ubitux> kierank: does it work?
[10:38:09 CEST] <wm4> I'm confused, does annexb have extradata or not?
[10:38:16 CEST] <wm4> I thought the whole point was that it doesn't
[10:39:06 CEST] <nevcairiel> it doesnt need to, but for easier codec init etc avformat will extract a param set into extradata anyway
[10:39:24 CEST] <nevcairiel> some containers (cough avi, cough) will store extradata with annexb as well
[10:40:01 CEST] <wm4> are the latter just with redundant extradata, or do they corrupt the bitstream?
[10:40:19 CEST] <wm4> are there sample files?
[10:40:37 CEST] <nevcairiel> i actually have no idea if these avis also include the extradata inside the stream
[10:40:43 CEST] <nevcairiel> i suppose you should expect both
[10:41:59 CEST] <wm4> well, the h264toannexb bsf has a "private_spspps_buf" option, which avoids corrupting the codec context's extradata field, but you also can't get the "processed" extradata normally output by it (whatever that is)
[10:42:47 CEST] <nevcairiel> well most containers that want annexb shouldnt want extradata
[10:42:49 CEST] <nevcairiel> ie. ts
[10:42:57 CEST] <nevcairiel> so its probably not a big problem
[10:43:31 CEST] <nevcairiel> this magicsauce option is for these dumb hardware decoders that dont accept mp4-style, and the devs were too lazy to implement their own quick bitstream fixing
[10:44:17 CEST] <wm4> that's probably what I'm dealing with
[10:51:52 CEST] <wm4> shouldn't there be at least 1 person in the planet who has code using AV_PIX_FMT_QSV?
[10:52:35 CEST] <nevcairiel> probably not
[10:53:50 CEST] <rcombs> was there ever a verdict about making libdcadec the default DCA decoder when it's built?
[10:54:07 CEST] <nevcairiel> send a patch and I'll support it
[10:54:39 CEST] <rcombs> should just be a matter of moving the REGISTER_ line in allcodecs.c to before the regular dca one, yeah?
[10:56:27 CEST] <nevcairiel> yes, but it should probably look somewhat clean and not just shoved in the middle of something there
[10:57:15 CEST] <wm4> also convincing "them" is the hardest part
[11:05:40 CEST] <__gb__> wm4, nevcairiel: well, it could indeed be interesting to have at least one user of any new codec prior to integrating it, just to make sure e.g. it can be demonstrated how to use it
[11:06:27 CEST] <nevcairiel> it can be used with "normal" pixfmts like NV12 in any case
[11:12:38 CEST] Action: __gb__ just returned from vacation and learned about the Changes -- will postpone hwaccel changes/discussions then for next VDD :)
[11:17:07 CEST] <__gb__> hey, VDD happens during the French "journées du patrimoine" -- interested parties might want to visit élysée palace, or some other undergrounds officially opened during that time
[11:24:06 CEST] <ubitux> i'm trying to use an avio dyn buf as custom avio for a format
[11:24:37 CEST] <ubitux> but it stalls on the avformat_open_input
[11:26:14 CEST] <ubitux> steps i'm doing are: avformat_alloc_context(), then avio_open_dyn_buf(), the avio_printf() a few things in the dyn buf, avio_flush() it, set the fmt->pb to that avio, enable custom io fmt flag, and then avformat_open_input the fmt with the input format forced/hinted
[11:26:20 CEST] <ubitux> am i missing something in the process?
[11:29:01 CEST] <ubitux> setting the flag is actually useless since it's done automatically
[11:29:59 CEST] <nevcairiel> i think you need to provide a custom read function
[11:30:26 CEST] <ubitux> the avio obtained with avio_open_dyn_buf() doesn't take care of this?
[11:30:37 CEST] <wm4> (lol)
[11:30:38 CEST] <nevcairiel> no idea
[11:30:44 CEST] <nevcairiel> but i dont think its designed for that use
[11:31:01 CEST] <wm4> yeah, I guess an avio thing is either for reading or writing
[11:31:03 CEST] <wm4> never both
[11:31:11 CEST] <wm4> maybe.
[11:31:20 CEST] <ubitux> mmh
[11:31:44 CEST] <nevcairiel> yeah those dynbufs dont have any read function
[11:31:46 CEST] <nevcairiel> its a writing concept
[11:31:56 CEST] <ubitux> i see
[11:32:01 CEST] <cone-597> ffmpeg 03Marton Balint 07master:086001652982: concatdec: fix broken file_inpoint calculation
[11:32:10 CEST] <ubitux> that's too bad
[11:32:29 CEST] <nevcairiel> a read function for a memory buffer isnt that complex though
[11:32:44 CEST] <nevcairiel> i guess its not common enough of a usecase to have content in memory
[11:32:50 CEST] <nevcairiel> otherwise we may have a function for that
[11:33:09 CEST] <ubitux> i'm using it for concat; and i guess i could use it for stuff like subtitles
[11:35:13 CEST] <wm4> custom aviobufs are really awkward
[11:35:26 CEST] <wm4> they could probably be improved significantly
[11:35:48 CEST] <nevcairiel> i dont know, seems straight forward, provide read/write/seek function (as applicable), done
[11:35:55 CEST] <nevcairiel> the only odd thing is the buffer you need to provide, i guess
[11:36:09 CEST] <wm4> yes, small odd things like this
[11:37:14 CEST] <wm4> ok, maybe that's all what's odd
[11:37:28 CEST] <nevcairiel> i have no idea why it doesnt allocate that internally
[11:37:33 CEST] <nevcairiel> some old micro-opt i guess
[11:37:36 CEST] <wm4> (hysteric: the aviobuf code might reallocate your buffer, and you still have to free that buffer at the end)
[11:37:43 CEST] <wm4> and read_seek is also odd
[11:38:01 CEST] <nevcairiel> read_seek?
[11:38:11 CEST] <wm4> it's a callback
[11:38:21 CEST] <wm4> for network protocols which include seeking by timestamp
[11:38:26 CEST] <nevcairiel> oh that
[11:38:30 CEST] <nevcairiel> but thats not part of avio
[11:38:44 CEST] <nevcairiel> not the normal avio contexts anyway
[11:38:50 CEST] <nevcairiel> thats URLProtocol
[11:39:10 CEST] <wm4> AVIOContext.read_seek exists
[11:39:31 CEST] <nevcairiel> avio_alloc_context knows nothing of that sort
[11:39:40 CEST] <nevcairiel> in any case, if you dont know what to make of it, just dont use it :D
[11:40:11 CEST] <nevcairiel> i believe the demuxer in question needs to explicitly call read_seek as well
[11:40:19 CEST] <nevcairiel> which makes it unsupported at best
[11:40:33 CEST] <wm4> ok, you can ignore it for most use-cases
[11:41:06 CEST] <nevcairiel> for any common use, you dont need to even look into AVIOContext, just set the t hings avio_alloc_context offers you to set and it works
[12:13:08 CEST] <wm4> what was the ffmpeg push url again?
[12:13:43 CEST] <ubitux> git at source.ffmpeg.org:ffmpeg
[12:13:56 CEST] <wm4> thanks
[12:14:22 CEST] <cone-597> ffmpeg 03wm4 07master:750f72d77587: mmaldec: hack against buffering problems on broken input
[12:14:23 CEST] <cone-597> ffmpeg 03wm4 07master:7f116973d59b: mmaldec: do not mutate user's AVCodecContext extradata field
[12:14:24 CEST] <cone-597> ffmpeg 03wm4 07master:67db57ea12bf: mmaldec: fix problems with flush logic
[12:24:24 CEST] <ubitux> nevcairiel: seems it's not enough; it tries to read 1024, i return 211, it tries to read again 1024, i return EOF, and then it's stalled again
[12:24:30 CEST] <ubitux> i guess it's not enough
[12:24:43 CEST] <ubitux> but anyway, i'm going to check further
[12:25:34 CEST] <jameshowe> Unsure whether this is off-topic, but has anyone tried an ffmpeg build with Xcode 7, -fenable-bitcode for armv7?
[12:26:17 CEST] <jameshowe> Adding that flag gives a segfault at runtime; I'm about to start investigating
[12:29:55 CEST] <wm4> what does the flag do?
[12:30:10 CEST] <wm4> oh let me guess, LTO?
[12:31:41 CEST] <nevcairiel> from a quick google, bitcode is an intermediate representation that apples compilers can output, which allows the app-store to "re-compile" it for all relevant target platforms
[12:31:50 CEST] <nevcairiel> doesnt sound like something ffmpeg would ever work in
[12:31:50 CEST] <jameshowe> includes the llvm intermediate in the objects, so that Apple can re-compile it to target different devices at install time
[12:32:29 CEST] <jameshowe> assembly and intrinsics are excluded, so there's no reason it shouldn't work
[12:32:49 CEST] <jameshowe> and you have to have all your libraries including bitcode in order to enable it in the app
[12:33:31 CEST] <jameshowe> however, that only applies when you upload to the store, yet it crashes from a local install even if the app has bitcode disabled
[12:34:38 CEST] <jameshowe> there's no reason I can see for the adding of a bitcode section should change the code in the armv7 section, so first thought is a clang bug
[12:38:21 CEST] <jameshowe> and arm64 seems to be fine - at least it doesn't crash from the testing I've done
[12:50:25 CEST] <jameshowe> any point in a stack trace, or shall I come back when I've got a better idea what's happening?
[12:56:03 CEST] <wm4> jameshowe: I'd blame apple
[12:56:21 CEST] <jameshowe> quite
[13:35:59 CEST] <jameshowe> the register allocations in the function that crashes are different, but I can't tell whether that would make it crash
[14:02:05 CEST] <jameshowe> ah here we go - it's changed from NOVFP to VFP in the .S files
[14:06:40 CEST] <jameshowe> that's the -mfpu flag?
[14:16:39 CEST] <jameshowe> --disable-vfp didn't put it back to NOVFP
[14:26:57 CEST] <jameshowe> "Compiler does not indicate floating-point ABI, guessing vfp."
[14:27:04 CEST] <jameshowe> any clues to override that?
[14:37:41 CEST] <cone-597> ffmpeg 03Ivan Uskov 07master:44857e7a3696: libavcodec/qsvdec.c: Extended error messages for MFXVideoDECODE_Init() result
[14:45:18 CEST] <ubitux> do we have avio with both read & write?
[14:50:04 CEST] <ubitux> it seems avio_read() doesn't like it much when you can both read & write (even though it has specific path for writable avio)
[14:55:10 CEST] <jameshowe> I think there's at least one bug in your configure script, as --disable-vfp should prevent it from guessing vfp
[14:57:02 CEST] <Compn> jameshowe : could be, whats your configure line ?
[15:03:25 CEST] <jameshowe> ./src/2.5.2/configure --target-os=darwin --arch=armv7 --cc='xcrun -sdk iphoneos clang' --disable-debug --disable-programs --disable-doc --enable-cross-compile --enable-pic --enable-static --enable-small --disable-encoders --disable-muxers --disable-filters --disable-bsfs --disable-zlib --disable-bzlib --disable-iconv --disable-vfp --logfile=config.log --extra-cflags='-arch armv7 -mios-version-min=7.0 -mno-thumb -fembed-bitcode'
[15:03:25 CEST] <jameshowe>  --extra-cxxflags='-arch armv7 -mios-version-min=7.0 -mno-thumb -fembed-bitcode' --extra-ldflags='-arch armv7 -mios-version-min=7.0 -mno-thumb -fembed-bitcode' --prefix=thin/armv7
[15:04:15 CEST] <jameshowe> admittedly, not the latest release
[15:22:50 CEST] <cone-597> ffmpeg 03Ganesh Ajjanagadde 07master:92a4bda95b84: doc/ffmpeg: correct minor typo
[15:45:01 CEST] <jameshowe> can't work out why its guess changes with bitcode, but have resolved the issue by removing that section of the configure script
[15:47:32 CEST] <jameshowe> might have a patch to fix --disable-vfp soon
[16:27:23 CEST] <cone-597> ffmpeg 03Paul B Mahol 07master:f0708b751f4f: avfilter/vsrc_testsrc: correct colors for smptebars
[17:02:15 CEST] <kierank> haha at that ticket
[17:05:59 CEST] <wm4> urgh what
[17:06:49 CEST] <wm4> I really hate rounded timestamps
[17:11:54 CEST] <JEEB> kierank: that person just derp'd over at #ffmpeg as well
[17:18:39 CEST] <nevcairiel> is his primary concern really a few bytes for the timestamp table
[17:33:09 CEST] <BBB> JEEB: poke
[18:15:24 CEST] <kierank> this thread is going to be popcorntastic
[18:16:27 CEST] Action: wm4 jumps in
[18:56:32 CEST] <nevcairiel> i'm sure we have one like that already
[18:56:36 CEST] <nevcairiel> find it and close as dupe
[20:21:38 CEST] <llogan> durandal_1707: attachment is a .swp
[20:21:45 CEST] <llogan> aphasemeter
[20:22:55 CEST] <BBB> michaelni: has that swscale gsoc student committed any code so far?
[20:23:25 CEST] <BBB> michaelni: its very risky to have a student do a single patch submission at the end of gsoc, that has (in the past) usually resulted in no patch ever being merged at all...
[20:23:37 CEST] <BBB> continuous streams of patches tend to work better...
[20:28:50 CEST] <michaelni> BBB, dont hesitate to push him into doing more & quicker, his patch 2 weeks ago was already working fine but it had a speed regression which is why he wanted to work more on it before it is commited
[20:29:00 CEST] <michaelni> didnt look at the new one from today yet
[20:29:59 CEST] <durandal_1707> llogan: because I'm on windows....
[20:37:43 CEST] <llogan> my condolences
[21:30:19 CEST] <BBB> so & thor
[21:30:27 CEST] <BBB> this will be fun
[22:28:57 CEST] <LRUB1> Hello. I came here yesterday to solve the problem FFmpeg after "make check: error" after setting the prefix "--enable-shared" in "./configure". Already arranged a solution? On the internet're hard to find one.
[22:29:59 CEST] <LRUB1> Linux Debian 8 Jessie.
[22:31:03 CEST] <LRUB1> ?
[22:31:39 CEST] <LRUB1> Still mistake in scoring ...
[22:31:51 CEST] <LRUB1> :|
[22:49:40 CEST] <BBB> LRUB1: that doesnt sound like a developer issue& did you try asking on #ffmpeg?
[22:50:56 CEST] <LRUB1> This problem is in ccompitation.
[22:51:52 CEST] <nevcairiel> we have test systems running such a compilation every day, so if there was a fundamental issue, one of them would've found it
[22:52:18 CEST] <cone-597> ffmpeg 03Carl Eugen Hoyos 07master:daf2c35f52e0: lavc: Remove newline from avpriv_request_sample() calls.
[22:54:58 CEST] <llogan> all instances of Libav have apparently been removed from Arch User Repository.
[22:59:13 CEST] <klaxa> wow, why's that?
[22:59:32 CEST] <llogan> i don't know. maybe they realized nobody used it.
[22:59:50 CEST] <nevcairiel> probably had no maintainer interested anymore
[22:59:56 CEST] <nevcairiel> stuff gets canned then
[23:00:08 CEST] <llogan> usually gets orphaned first
[23:07:07 CEST] <llogan> durandal_1707: now i need to make a new filter example for wiki/Encode/YouTube
[23:07:20 CEST] <llogan> must use all A->V
[23:09:13 CEST] <wm4> AUR is a joke
[23:09:20 CEST] <wm4> whether there is something or not means nothing
[23:10:28 CEST] <llogan> emo
[23:10:43 CEST] <wm4> do you know how AUR is used?
[23:10:51 CEST] <wm4> it's not even a package repository
[23:11:10 CEST] <wm4> you download stuff manually, build it manually, and then you get a arch package which you install manually
[23:11:11 CEST] <llogan> yes. and it was just an aside. nobody claimed it meant shit.
[23:13:53 CEST] <kierank> 10:10 PM <"llogan> emo
[23:13:53 CEST] <kierank> lol
[23:24:28 CEST] <LRUB1>  Traduzir do: inglês  Weird. Already tested with "make check"?
[23:25:19 CEST] <cone-597> ffmpeg 03Ganesh Ajjanagadde 07master:0581ab2caccc: avcodec/g729: add g729_parser
[23:25:20 CEST] <cone-597> ffmpeg 03Michael Niedermayer 07master:8992029fc0a4: avcodec/g729_parser: Replace codec_id check by assert
[23:27:10 CEST] <LRUB1> I blew it. My English is bad and I'm using Google Translator. = P
[23:30:09 CEST] <BBB> who here loves mplayer?
[23:30:15 CEST] <kierank> Compn: ^
[23:30:21 CEST] <BBB> but he cant code
[23:30:30 CEST] <BBB> is there anyone here that loves mplayer and can code, too?
[23:31:22 CEST] <BBB> (and there was a deafening silence)
[23:32:58 CEST] <kierank> wm4
[23:34:22 CEST] <wm4> sorry I don't miss mplayer
[23:37:39 CEST] <BBB> andreas is asking if some mplayer dev can assist in porting mplayer away from old ffmpeg apis, insofar that current head uses any
[23:37:50 CEST] <BBB> (I dont know if it does)
[23:38:23 CEST] <BBB> Im helping him port other packages, so Im hoping some poor sucker here will volunteer and do the devils work
[23:38:32 CEST] <BBB> given that mplayer has so many fans
[23:38:32 CEST] <BBB> right?
[23:38:51 CEST] <wm4> mplayer2 put a lot of work into cleaning up API usage
[23:39:01 CEST] <wm4> if they want to duplicate that, whatever
[23:39:09 CEST] <BBB> Im not a zealot
[23:39:13 CEST] <BBB> I dont care about either mplayer
[23:39:23 CEST] <BBB> Im trying to help debian deal with our api removals
[23:39:31 CEST] <BBB> Im on a mac, give me some cred here
[23:39:36 CEST] <wm4> (they could just look at the damn mplayer2 repo)
[23:39:55 CEST] <BBB> can you point to individual patches?
[23:39:59 CEST] <BBB> or individual pieces of code?
[23:40:12 CEST] <BBB> like, places where they use av_audio_convert_* or AVResampleContext
[23:40:13 CEST] <BBB> or so
[23:40:15 CEST] <wm4> well there was e.g. a commit to port it to libavresample instead of the lavc resampler
[23:40:31 CEST] <BBB> do you have a websvn/git link to that commit?
[23:40:31 CEST] <wm4> but I've seen a patch on mplayer-dev which duplicates this work fully
[23:40:33 CEST] <BBB> thatd help a ton
[23:40:41 CEST] <wm4> not sure where to look
[23:40:41 CEST] <BBB> ignore mplayer-dev
[23:40:47 CEST] <wm4> the mplayer2 site went offline
[23:40:50 CEST] <BBB> ...
[23:41:07 CEST] <BBB> reminds me of that south park episode
[23:41:10 CEST] <BBB> & and its gone!"
[23:41:14 CEST] <BBB> & but
[23:41:30 CEST] <BBB> Im sorry sir you have no money in an active account here, please move aside for actual customers
[23:42:43 CEST] <wm4> maybe the amount of API usage mplayer2 cleans up isn't that high
[23:42:49 CEST] <wm4> because mplayer2 is also stale and old by now
[23:45:25 CEST] <wm4> BBB: what deprecations do they want to take care off?
[23:46:56 CEST] <BBB> audio convert, audio resample, get_buffer usage, filterpad usage
[23:48:06 CEST] <jamrial> the audio convert stuff is a header that's just a wrapper for channel_layout.h, another header
[23:48:24 CEST] <BBB> not that
[23:48:28 CEST] <BBB> the lavc audio convert stuff
[23:48:38 CEST] <BBB> the stuff that converts between sample formats
[23:49:07 CEST] <BBB> my understanding (not checked) is that mplayer uses that
[23:49:36 CEST] <baptiste> I love mplayer
[23:50:00 CEST] <BBB> ah good, can you patch it?
[23:50:13 CEST] <jamrial> odd, libav supposedly removed that long ago. does mplayer try to work with both libav and ffmpeg or just the latter?
[23:50:23 CEST] <JEEB> they have their internal ffmpeg
[23:50:32 CEST] <jamrial> i see
[23:50:45 CEST] <philipl> Can't we just bless mpv as the official replacement for mplayer and call it a day?
[23:51:40 CEST] Action: philipl waits for wm4 to object
[23:51:48 CEST] <wm4> mpv is very different from mplayer by now, so it's not a drop-in replacement
[23:52:06 CEST] <philipl> Not a drop in, but it provides the useful functionality in a maintainable form.
[23:52:19 CEST] <rcombs> "stop using mplayer, start using mpv"
[23:52:46 CEST] <JEEB> (insert compn comments regarding the fabulousness and irreplace'ability of mplayer here)
[23:52:56 CEST] <philipl> It's certainly unique.
[23:53:19 CEST] <rcombs> does it matter if mplayer uses a lavc API, seeing as it has its own internal ffmpeg copy anyway?
[23:53:35 CEST] <wm4> rcombs: distros don't want the internal copy
[23:53:40 CEST] <philipl> The 'internal' copy is a git checkout of ffmpeg master.
[23:53:44 CEST] <philipl> So not really internal.
[23:53:45 CEST] <rcombs> wm4: I don't want it either
[23:54:02 CEST] <ubitux> so, thor is the new hype thing or i missed something?
[23:54:05 CEST] <BBB> JEEB: #libav logs please please please?
[23:54:10 CEST] <BBB> ubitux: yeah I just saw it too
[23:54:21 CEST] <BBB> ubitux: maybe theyll want a decoder
[23:54:28 CEST] <philipl> What's thor?
[23:54:33 CEST] <BBB> daala2
[23:54:37 CEST] <philipl> hah.
[23:54:37 CEST] <BBB> from cisco
[23:54:47 CEST] <ubitux> https://github.com/cisco/thor
[23:54:50 CEST] <ubitux> https://tools.ietf.org/html/draft-fuldseth-netvc-thor-00
[23:54:55 CEST] <ubitux> http://blogs.cisco.com/collaboration/world-meet-thor-a-project-to-hammer-out-a-royalty-free-video-codec
[23:54:56 CEST] <ubitux> etc.
[23:55:21 CEST] <philipl> Ok. Fun times.
[23:55:26 CEST] <ubitux> oh, and the usual https://news.ycombinator.com/item?id=10042469
[23:55:37 CEST] <JEEB> philipl: the main point was that it was commonly using internal APIs which it could do more easily due to having the ffmpeg source tree there
[23:56:03 CEST] <philipl> JEEB: for sure - but I mean that it's not in any way isolated from ffmpeg api changes.
[23:56:11 CEST] <JEEB> sure
[23:57:31 CEST] <philipl> Anyway - the serious point here, I think, is what does mplayer do that mpv doesn't that actually matters to anyone.
[23:57:46 CEST] <BBB> I dont think thats the point
[23:57:49 CEST] <BBB> debian wants mplayer
[23:57:52 CEST] <BBB> I dont know why
[23:57:56 CEST] <BBB> I dont even care why
[23:57:57 CEST] <BBB> but they want it
[23:58:06 CEST] <BBB> so we want to help them get it to compile after we remove old/deprecated apis
[23:58:13 CEST] <BBB> pointing them to a mplayer2 patch is fine
[23:58:18 CEST] <BBB> but that patch needs to exist
[23:58:19 CEST] <philipl> They don't know why they want it. It's not unreasonable to point out that that it's a pointless undertaking.
[23:58:20 CEST] <BBB> (same for mpv)
[23:58:33 CEST] <BBB> not my battle to fight, sorry
[23:59:06 CEST] <philipl> BBB: Sure.
[00:00:00 CEST] --- Wed Aug 12 2015