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

Sun Nov 5 03:05:03 EET 2017

[00:48:13 CET] <cone-265> ffmpeg 03Carl Eugen Hoyos 07master:9d0b42bce52c: fate: Fix fitsdec-gbrap16 test on big-endian hardware.
[05:05:57 CET] <cone-706> ffmpeg 03Sasi Inguva 07master:c2a8f0fcbe57: lavf/mov.c: Refine edit list start seek, based on PTS computed from CTTS.
[05:05:57 CET] <cone-706> ffmpeg 03Kaustubh Raste 07master:5cb261301c1d: avcodec/mips: Improve avc avg mc 20, 21 and 23 msa functions
[05:05:57 CET] <cone-706> ffmpeg 03Kaustubh Raste 07master:e1555eb76cd2: avcodec/mips: Improve hevc bi 4 tap hz and vt mc msa functions
[05:05:57 CET] <cone-706> ffmpeg 03Kaustubh Raste 07master:8f6c398d44b5: avcodec/mips: Improve hevc bi wgt 4 tap hz and vt mc msa functions
[15:26:17 CET] <fx159159> Hey, I'm trying to compile ffmpeg for android x86 and it gives me this: "src/libavcodec/x86/mpegvideoenc_template.c:152:9: error: 'asm' operand has impossible constraints", any idea what could be wrong?
[15:32:10 CET] <jkqxz> Your compiler sucks?  Or there is some additional global register constraint (like a frame pointer?) which the code isn't expecting?
[15:33:31 CET] <JEEB> oh right, they force PIC
[15:33:34 CET] <JEEB> I think?
[15:33:42 CET] <JEEB> which isn't working with asm on x86
[15:33:45 CET] <JEEB> on x86_64 it does
[15:33:49 CET] <JEEB> it's an old known issue
[15:36:56 CET] <jkqxz> That would do it.
[15:37:38 CET] <JEEB> this is about loading the binaries, but since I wouldn't be surprised if the NDK was updated https://trac.ffmpeg.org/ticket/4928
[15:38:08 CET] <fx159159> jkqxz: Tried -fomit-frame-pointer but not difference
[15:39:22 CET] <jkqxz> Try -fno-pic.
[15:40:30 CET] <fx159159> That will probably lead to non functioning binaries if I understand JEEB's link?
[15:41:15 CET] <jkqxz> Maybe.  You did only say you were trying to compile it, not to run the result!
[15:42:07 CET] <fx159159> Well yeah, eventually I want to run them hehe
[15:43:24 CET] <jkqxz> On a 32-bit x86 Android device?  I wouldn't be so sure.
[15:43:59 CET] <JEEB> if you want to run it on x86 android and are OK with all the hand-written SIMD to be disabled, then `--disable-asm --enable-pic` is what's needed
[15:44:16 CET] <JEEB> x86_64 can have the SIMD enabled because of added registers and PIC being the defaeult there
[15:44:22 CET] <fx159159> Emulator, yeah does not really make sense but currently I have no device and wanted to tinker a bit...
[15:46:19 CET] <fx159159> Found something, works as a temporary fix, only remove the offending functions, leave the other asm stuff untouched... https://raw.githubusercontent.com/MoboPlayer/FFMpegBuildScript/master/README.md
[15:47:21 CET] <JEEB> uhh what
[15:47:30 CET] <JEEB> that sounds like a very bad idea to not have testing with
[15:47:42 CET] <JEEB> also esp. that LOG2&LOG10 stuff
[15:49:22 CET] <fx159159> Only applied the first diff, at least it compiles... let's see, actually I do not want to use anything mpeg related (or so I guess)
[15:49:56 CET] <JEEB> that's used in the mpeg1/2/4 decoders and encoders I guess
[15:50:05 CET] <JEEB> since those are still stuck to mpegvideo
[15:50:24 CET] <JEEB> so if you are not planning on poking those video formats it might just be simpler to disable those and hope for the best :P
[15:50:37 CET] <JEEB> at least that would be more supported than random patching
[15:51:16 CET] <fx159159> Ok, which decoders/encoders depend on mpegvideo?
[15:52:26 CET] <fx159159> --disable-encoder=mpegvideoenc should be enough I guess?
[15:52:30 CET] <JEEB> no
[15:52:31 CET] <fx159159> Will try..
[15:52:43 CET] <JEEB> you will probably have to disable the decoders and encoders for mpeg1/2/4
[15:52:56 CET] <JEEB> which are MPEG-1 Video, MPEG-2 Video and MPEG-4 Visual (Part 2)
[15:58:21 CET] <JEEB> fx159159: btw the even simpler thing would be to just to use a x86_64 android image and build for 64bit :P
[15:58:27 CET] <JEEB> since no tweaks are needed there
[15:58:38 CET] <JEEB> android on 32bit intel is even more dead than 64bit
[16:04:48 CET] <fx159159> JEEB: I thought the x86 emulator runs faster? At least it sounded so
[16:05:15 CET] <JEEB> compared to ARM
[16:05:16 CET] <JEEB> yes
[16:05:24 CET] <JEEB> x86_64 is 64bit x86
[16:05:29 CET] <JEEB> while x86 is 32bit x86
[16:05:42 CET] <JEEB> most x86 CPUs are 64bit and your OS is most likely 64bit as well
[16:05:49 CET] <JEEB> so if there's a 64bit x86 image you should use that
[16:06:01 CET] <JEEB> unless you intend on supporting 32bit intel devices
[16:14:10 CET] <fx159159> Not really, guess I'll just use x86_64
[17:09:21 CET] <cone-945> ffmpeg 03Carl Eugen Hoyos 07master:3357b68bc02d: lavc/alac: Avoid allocating huge memory blocks for malicious alac input.
[18:05:11 CET] <JEEB> was there any field in AVFrames that field-separate decoders set?
[18:05:26 CET] <JEEB> that interleaved decoders don't set
[18:05:45 CET] <JEEB> as in, how can an API user know if the fields have to be interleaved before sending them further into filtering?
[18:20:47 CET] <atomnuker> there are no field separate encoders afaik
[18:21:05 CET] <JEEB> atomnuker: this is more regarding how an API user could handle interlaced j2k or HEVC
[18:21:10 CET] <JEEB> you get the fields separate from those
[18:21:20 CET] <atomnuker> as in, decoders?
[18:21:29 CET] <JEEB> yes
[18:21:34 CET] <JEEB> and what happens afterwards
[18:21:42 CET] <atomnuker> that sounds like a bug
[18:21:50 CET] <atomnuker> all decoders must output interleaved fields
[18:21:53 CET] <JEEB> !
[18:21:56 CET] <kierank> yeah right
[18:21:58 CET] <kierank> they don't all do that
[18:22:07 CET] <JEEB> yea, HEVC and J2K don't output interleaved
[18:22:13 CET] <JEEB> see https://trac.ffmpeg.org/ticket/5514
[18:22:23 CET] <nevcairiel> for HEVC at least thats not by design, its just lack of implementation
[18:22:30 CET] <kierank> hevc SD, wtf
[18:22:45 CET] <kierank> is that tv channel on crack
[18:23:01 CET] <JEEB> yea, together with Germany
[18:23:05 CET] <atomnuker> I'd rather have all decoders output separate fields though
[18:23:13 CET] <JEEB> well yea, that's the sane way
[18:23:15 CET] <nevcairiel> no thanks
[18:23:20 CET] <JEEB> but so far nothing in the framework supports that
[18:23:34 CET] <JEEB> basically if you have [input]yadif[out]
[18:23:34 CET] <nevcairiel> and no other framework  i know has that
[18:23:38 CET] <JEEB> with HEVc
[18:23:46 CET] <JEEB> that just fails flat on its face
[18:24:12 CET] <nevcairiel> just call interlaced hevc unsupported
[18:24:21 CET] <atomnuker> I'd really rather not have field-separate and interleaved outputs, so yeah, better call it unsupported
[18:25:02 CET] <BtbN> nvenc does field seperate interlaced encoding
[18:25:08 CET] <BtbN> Which breaks it in ffmpeg
[18:26:16 CET] <kierank> nevcairiel: interleave fields are entirely a construct of software
[18:26:26 CET] <kierank> if you want them interleaved there should be a wrapper to do that
[18:26:34 CET] <kierank> double the stride etc
[18:27:03 CET] <BtbN> Wouldn't that mean manually seperating them in most decoders?
[18:27:07 CET] <JEEB> well yea, in this case it's software and because of the whole "everything outputs and expects interleaved fields"
[18:27:22 CET] <JEEB> BtbN: in theory PAFF images should be separate
[18:27:29 CET] <JEEB> MBAFF would be a single one I think?
[18:27:34 CET] <JEEB> in which case there would be separation
[18:27:36 CET] <BtbN> I know you cannot possibly get non-interleaved frames out of cuvid
[18:27:43 CET] <nevcairiel> kierank: perhaps, but its still s omething that every software does, and decoders can just use doubled stride to decode into one buffer, so doing that afterwards would be inefficient
[18:27:43 CET] <BtbN> no matter how it's encoded
[18:28:13 CET] <kierank> nevcairiel: well for example for low latency, it's useful to start sending and receiving fields at a time
[18:28:15 CET] <BtbN> JEEB, yes, nvenc does PAFF interlacing. So it outputs two seperate frames per interleaved input picture. Which the ffmpeg API just cannot support it seems
[18:28:41 CET] <JEEB> BtbN: yea a lot of stuff expects both fields in one picture in both AVFrame and AVPacket I think
[18:29:03 CET] <nevcairiel> for avpacket its actually fine to split it, at least in decoding
[18:29:07 CET] <nevcairiel> it typically even is split
[18:29:22 CET] <nevcairiel> at least for h264
[18:29:37 CET] <JEEB> yes, for decoding. he was most likely talking about muxer code
[18:30:44 CET] <BtbN> encoder. nvenc
[18:30:47 CET] <nevcairiel> avcodec and avformat should be fine with that using the new api
[18:30:54 CET] <nevcairiel> ffmpeg.c is probably too dumb
[18:31:06 CET] <BtbN> nvenc outputs two picture slices when doing interlaced encoding
[18:31:19 CET] <BtbN> putting them in one packet basically drops the second field due to no timestamp
[18:31:31 CET] <BtbN> And emitting two packets causes weird problems left and right
[18:37:22 CET] <JEEB> BtbN: btw so what you tried was to set the encoder time base to *2 the input time base and output proper timestamps?
[18:44:02 CET] <BtbN> JEEB, it did that, yes
[18:44:35 CET] <nevcairiel> those problems are likely ffmpeg.c being limited however, not encoder api related
[18:44:52 CET] <JEEB> yea the encoder API is OK with that, the API client just needs to utilize the encoder time base
[18:45:04 CET] <JEEB> if the API client doesn't.... well, fuck that
[18:47:14 CET] <JEEB> although it could also be a case of the API client setting the stream time base first
[18:47:29 CET] <JEEB> and then converting those encoded timestamps to the muxer time base
[18:47:38 CET] <JEEB> which most likely goes the way of the dodo
[18:48:53 CET] <BtbN> it just doesn't seem to be intended for an encoder to modify the timebase
[18:59:16 CET] <nevcairiel> probably not, but you need to specifically enable interlaced encoding, at which point the api client could automatically double the timebase
[19:16:33 CET] <cone-945> ffmpeg 03Kieran Kunhya 07master:03b82b3ab988: h2645_parse: Allocate a single buffer per packet
[19:16:34 CET] <cone-945> ffmpeg 03Kieran Kunhya 07master:77748d12a01d: h264: Make Truncating SPS/PPS message debug.
[19:16:53 CET] <kierank> fuck
[19:17:15 CET] <kierank> committer	Your Name <you at example.com>
[19:17:17 CET] <kierank> bah
[19:17:26 CET] <JEEB> :)
[19:26:41 CET] <cone-945> ffmpeg 03Kieran Kunhya 07master:626d200e76e1: vc2enc: Calculate average slice quantiser correctly
[19:29:01 CET] <cone-945> ffmpeg 03Marton Balint 07master:84d31e2475c4: ffplay: create the window and the renderer before starting playback
[19:29:02 CET] <cone-945> ffmpeg 03Marton Balint 07master:415038f2bd32: ffplay: only use hardware accelerated SDL texture formats
[19:29:09 CET] <atomnuker> kierank: this wouldn't really work with more than one frame though :/
[19:29:21 CET] <kierank> crap pushed wrong version
[19:30:14 CET] <JEEB> \o/
[19:30:55 CET] <kierank> I'll revert I guess
[19:32:08 CET] <cone-945> ffmpeg 03Kieran Kunhya 07master:1358f7ddb3a0: Revert "vc2enc: Calculate average slice quantiser correctly"
[19:32:49 CET] <iive> kierank: i hope you are not driving today.
[19:32:52 CET] <iive> ;)
[21:00:48 CET] <kierank> does h264 lowres work?
[21:01:14 CET] <kierank> when I remove mpeg4video from mpegvideo.c lowres will stop working
[21:05:04 CET] <JEEB> no
[21:05:08 CET] <JEEB> lowres never worked for H.264
[21:09:16 CET] <kierank> maybe I should email the ml
[21:15:35 CET] <TD-Linux> I don't think it could ever work due to intra prediction
[21:17:44 CET] <JEEB> yea
[21:23:54 CET] <Compn> JEEB / kierank : for slice h264 only or maybe frame h264 only ?
[21:23:56 CET] <Compn> its been a while
[21:24:11 CET] <Compn> but i think been broken a long time
[21:28:08 CET] <kierank> there warned the ML in advance so the usual suspects can complain
[21:30:22 CET] <jamrial> kierank: lowres is deprecated and should be removed alongside AVStream->codec
[21:35:38 CET] <jamrial> actually, it could be removed now if you or someone can untangle it from the rest of the codebase
[21:36:06 CET] <jamrial> the depreation is older than two years old and the only reason i postponed it during last month's bump was because i coudn't untangle it, and nobody answered my call for help in that regard
[21:36:32 CET] <kierank> well I can untangle it from mpeg4video at least
[21:37:29 CET] <jamrial> if you can untangle it from the entire codebase, we can kiss it goodbye :p
[22:15:27 CET] <BBB> kierank: whats your opinion on separating mpegvideo and mpegvideoenc?
[22:16:03 CET] <kierank> i have no opinion
[22:16:07 CET] <BBB> ok
[00:00:00 CET] --- Sun Nov  5 2017