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

[burek]

[06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:8754147db668: lavc/libxavs2: remove unused context parameter
[06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:11751f62520b: lavc/libxavs2: use upper layer qp parameters first
[06:23:04 CET] <cone-706> ffmpeg 03hwren 07master:ff03418348dd: lavc/libdavs2: fix parameter setting error
[08:23:57 CET] <j-b> 'morning
[09:43:57 CET] <JEEB> wow
[09:44:24 CET] <JEEB> sub2video 100% depends on the subtitle codec context not being set proper during the first frame
[09:45:10 CET] <nevcairiel> everyone knows that sub2video is a bit of a hack :)
[09:45:13 CET] <JEEB> and if you have enough threads to have the subtitle decoder get its first frame and thus context width/height at the first frame fed to the filter chain
[09:45:28 CET] <JEEB> I was wondering why I was getting different results between 6 and 7 threads
[09:45:54 CET] <JEEB> sub2video: Generating AVFrame: (ist->sub2video: 1920x1080, dec_ctx: [-0x0)-]{+720x576)+} -> [-1920x1080-]{+720x576+}
[09:45:57 CET] <JEEB> sub2video: Feeding a [-1920x1080-]{+720x576+} AVFrame with pts 1441 to filter: graph 0 input from stream 0:2
[09:46:07 CET] <JEEB> first one is working one, second is non-working
[10:01:44 CET] <JEEB> then after the initial frame is fed, `sub2video: Generating AVFrame: (ist->sub2video: 1920x1080, dec_ctx: 720x576) -> 720x576`
[10:01:50 CET] <JEEB> so it actually starts feeding the smaller things
[10:02:16 CET] <JEEB> [auto_scaler_0 @ 0x35e3a00] w:720 h:576 fmt:bgra sar:0/1 -> w:1920 h:1080 fmt:yuva420p sar:0/1 flags:0x2
[10:02:19 CET] <JEEB> ^ and this happens
[10:04:06 CET] <JEEB> nevcairiel: and yes, it's a total hack but it still keeps surprising me
[10:19:23 CET] <JEEB> I guess scale2ref never gets hit proper or something
[10:24:02 CET] <durandal_1707> wut?
[10:25:04 CET] <JEEB> durandal_1707: figuring out how sub2video ends up not scaling things xD
[10:51:38 CET] <JEEB> ok, manually inserting scale2ref seems to be the thing to do
[10:52:19 CET] <JEEB> [dem_subs_stream][yadif_out]scale2ref[s2ref_subs][s2ref_video];[s2ref_video][s2ref_subs]overlay[overlay_out]
[10:56:02 CET] <JEEB> might just make a bug report about this sample, but it seems like this is how sub2video is supposed to work
[10:56:24 CET] <JEEB> the behavior differs heavily if you get your subtitles or not at the point of start
[10:56:41 CET] <JEEB> +unfortunately, the behavior differs...
[11:33:33 CET] <BtbN> philipl, I'm in Sweden helping at an event. The header should have precautions to be compatible with both SDK and non-sdk?
[11:33:50 CET] <BtbN> That's why it passes in the functions as parameters.
[11:34:19 CET] <BtbN> Going back to the old way also breaks compilation in some cases, due to a duplicated symbol.
[12:33:47 CET] <nevcairiel> Not if you do it right this time
[13:16:02 CET] <BtbN> How else would you do it? It had the same symbol in multiple libs, which broke in some edge cases with shared linking.
[13:22:33 CET] <JEEB> IIRC he said that oyu would onyl build the common symbol source with shared builds or so
[13:22:44 CET] <JEEB> somewhere in the IRC logs there was the thing mentioned
[13:33:11 CET] <nevcairiel> BtbN: the same unexported ff_ symbol in multiple shared libraries should never cause problems, we do that with other symbols already. What might be a problem is having the same ff_ symbol in  multiple static libraries, and you can avoid that by only cloning the object in shared builds, like with the other symbols that use this technique
[13:42:00 CET] <BtbN> nevcairiel, in the old approach it was exported though. Since there is no helper macro to mark it as "Do not export"
[13:42:36 CET] <BtbN> And the problem there currently is with it using symbols from ffnvcodec was there before, that part is unchanged
[13:42:58 CET] <BtbN> It can be relatively easily avoided by defining the function signature on its own.
[13:44:15 CET] <BtbN> git does weird things. I just pulled, and "rename libavutil/cuda_check.c => libavcodec/mips/vp3dsp_init_mips.c (50%)"
[14:30:35 CET] <nevcairiel> BtbN: anythign starting with ff is automatically not exported
[14:31:13 CET] <nevcairiel> or m ore precisely, anything not starting with av*
[14:31:59 CET] <nevcairiel> in any case, we use the same technique for other symbols, with one key difference: in static builds its not duplicated to avoid issues
[14:51:44 CET] <BtbN> Weird. I do think just having it a inline function in the header is the right way. It's pretty much a better macro anyway
[16:15:44 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/f028d813709cb14bdf08de898bc560e41e630763
[16:16:06 CET] <philipl> That was my attempt at making it compatible with both forms.
[16:20:24 CET] <BtbN> philipl, I'd say just don't use the typedefs and cast to the function type manually.
[16:49:19 CET] <philipl> BtbN: In other words, have local definitions of the function signatures in the header?
[16:49:25 CET] <philipl> sure. I'll try that.
[17:04:43 CET] <cassidy> Hi there! I sent a patch to the mailing list but didn't get any review so far. Any chance one of you could take a look? thanks! http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240026.html
[17:26:00 CET] <JEEB> cassidy: just check if there were any tests for that format (a quick git grep for cdg should be able to figure that out)
[17:26:14 CET] <JEEB> and check who's the maintainer for that module with git (gui) blame
[17:27:24 CET] <JEEB> aand james replied it seems :)
[17:27:59 CET] <JEEB> also that confirms that if I want to find out packets with unknown durations zero is relevant
[17:31:41 CET] <nevcairiel> it sort of makes sense since a duration of 0 is basically meaningless, but it can be a bit confusing to have everything else be NOPTS but this 0
[17:33:16 CET] <cassidy> JEEB, just tried and if I set it to 0, it ends up as 1 in my application (from av_read_frame()). Not sure why
[17:34:21 CET] <cassidy> while if I set to NOPTS I get it as it in my app so I can properly parse it as "no duration"
[17:48:14 CET] <BtbN> philipl, either that, or no definitions at all. Would be two very ugly casts.
[19:24:14 CET] <durandal_1707> anybody can capture mpeg with AC-4 audio with one of their cards ?
[19:26:34 CET] <kierank> I think people in paris can
[19:46:30 CET] <durandal_1707> who is in Paris? I think that only east is in AC-4 - firmwares for TV brands
[19:52:03 CET] <kierank> most videolan people
[19:53:30 CET] <durandal_1707> they are very silent here, are they on party? or are again on streets?
[19:55:20 CET] <kierank> getting drunk on wine and cheese
[19:55:38 CET] <durandal_1707> and breaking capture cards in process
[19:56:23 CET] <atomnuker> have you ran out of samples?
[19:56:39 CET] <JEEB> he needs to figure out the ID for MPEG-TS
[19:56:45 CET] <JEEB> since it's not in the specs
[19:56:49 CET] <JEEB> (unlike the mp4 one)
[19:57:03 CET] <JEEB> because the dshow module that he can use to verify if his stuff is more or less correct only does MPEG-TS
[19:57:13 CET] <durandal_1707> i'm too lazy to compile lavfilters to just find out that .ax file will not coperate
[19:57:53 CET] <JEEB> if the structure of the MPEG-TS broadcast is being published somewhere that'd be enough as well:P (like the identifiers and such)
[19:59:30 CET] <durandal_1707> ETSI standards is spreading incomplete standards as usual
[20:00:24 CET] <durandal_1707> some descriptor tags are already taken, pretty much all of them
[20:00:43 CET] <JEEB> yea, the stuff that's defined there is just the same that's used for other Dolby and DTS formats
[20:00:54 CET] <JEEB> you have a separate registration ID somewhere that specifies that it's AC-4
[20:01:05 CET] <atomnuker> can't you just check what's in the file? if it doesn't conflict with anything it could be correct
[20:01:16 CET] <durandal_1707> its probably just single byte
[20:01:37 CET] <durandal_1707> atomnuker: there are no mpeg-ts known samples, only mp4
[20:01:57 CET] <JEEB> >  * Add AC-4 format support in Mp4Extractor and TsExtractor
[20:02:04 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/commit/e462c6aab7dc5cab47c3daae5298626612d352be
[20:02:12 CET] <JEEB> so they have their own fork of ExoPlayer for it, lol
[20:02:55 CET] <JEEB> >  library/core/src/test/assets/ts/sample.ac4
[20:03:04 CET] <JEEB> is that a ts or raw ac4 sample
[20:03:05 CET] <JEEB> lol
[20:03:30 CET] <JEEB> probably raw
[20:04:15 CET] <durandal_1707> JEEB: you are GENIUS
[20:08:19 CET] <durandal_1707> this is raw AC-4, which is still something
[20:08:26 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/blob/dev-v2-ac4/library/core/src/main/java/com/google/android/exoplayer2/extractor/ts/TsExtractor.java
[20:08:32 CET] <JEEB> this seems to be the MPEG-TS bullcrap
[20:09:07 CET] <JEEB> TS_STREAM_TYPE_AC4 = 0xAC; /* DVB/ATSC AC-4 Descriptor */ and then AC4_FORMAT_IDENTIFIER = Util.getIntegerCodeForString("AC-4");
[20:09:30 CET] <JEEB> https://github.com/DolbyLaboratories/ExoPlayer/blob/dev-v2-ac4/library/core/src/main/java/com/google/android/exoplayer2/extractor/ts/TsExtractor.java#L640
[20:09:54 CET] <JEEB> private static final int TS_PMT_DESC_DVB_EXT_AC4 = 0x15;
[20:11:17 CET] <JEEB> ok, so one thing is registration descriptor where you have probably something like "AC-4"
[20:11:48 CET] <JEEB> and the other is the extension descriptor in ETSI EN 300 468
[20:12:01 CET] <JEEB> AC-4_descriptor in DVB (ETSI EN 300 468)
[20:14:00 CET] <JEEB> https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.15.01_60/en_300468v011501p.pdf
[20:14:03 CET] <JEEB> annex D
[20:14:17 CET] <JEEB> seems to contain the AC-4 bullcrap
[20:17:01 CET] <JEEB> and 6.3 "Extended descriptor identification and location" contains the 0x15
[20:17:08 CET] <JEEB> which is AC-4_descriptor
[20:43:20 CET] <durandal_1707> JEEB: does AC-4 nees special private crap in mpeg-ts, unlike AC-3?
[20:46:17 CET] <JEEB> it'sa custom descriptor that has to be written if you want to mux
[20:46:39 CET] <JEEB> not sure if demuxers check anything else than the size
[20:46:57 CET] <JEEB> then there's the stuff that mpegts.c calls REGD_types
[20:47:08 CET] <JEEB> that's another way, not sure if it's AC-4 or what tho exactly
[20:47:16 CET] <JEEB> probably exactly that
[20:48:16 CET] <JEEB> the other ETSI spec noted how the AC-4 data packets were put into a length-first thing
[20:48:32 CET] <JEEB> (just look for PES packets)
[21:16:32 CET] <durandal_1707> JEEB: looks like this sample.ac4 uses bitstream version 2, which is not documented at all in specification
[21:16:56 CET] <JEEB> it's in part 2
[21:16:56 CET] <JEEB> IIRC
[21:17:53 CET] <JEEB> ETSI TS 103 190-2
[21:18:16 CET] <JEEB> https://www.etsi.org/deliver/etsi_ts/103100_103199/10319002/01.02.01_60/ts_10319002v010201p.pdf
[21:19:27 CET] <JEEB> and yes, this darn spec has the MPEG-2 TS stuff
[21:19:40 CET] <JEEB> registration_descriptor 0x41 0x43 0x2D 0x34 (AC-4)
[21:20:05 CET] <JEEB> but primary means is the AC-4 descriptor
[21:20:21 CET] <JEEB> the registration thing is a fall-back for receivers that don't understand the AC-4 specific descriptor
[21:25:52 CET] <cone-287> ffmpeg 03Matthew Fearnley 07master:2d80b56ce0d4: libavcodec/zmbvenc: block scoring improvements/bug fixes
[21:25:52 CET] <cone-287> ffmpeg 03Matthew Fearnley 07master:f2e89fe4d34a: libavcodec/zmbvenc: motion estimation improvements/bug fixes:
[21:33:30 CET] <thardin> does FATE test encoders too?
[21:34:04 CET] <JEEB> it has the capability to, yes
[21:34:20 CET] <JEEB> if someone adds a test based on some input that can be generated or so
[21:34:48 CET] <thardin> so I notice
[21:35:04 CET] <thardin> just some codecs missing tests. looking at zmbv
[21:35:04 CET] <JEEB> usually with the bitexact etc flags in case the generated input is RGB and then you need to YCbCr'ify it in the middle
[21:35:09 CET] <JEEB> yea
[21:35:12 CET] <JEEB> unfortunately
[21:36:04 CET] <thardin> feels like something that could be automagically generated. for e in $ENCODERS ; do ffmpeg -i ref.avi -vcodec $e - | sha1sum  etc etc
[21:36:20 CET] <thardin> whatever that becomes in make parlance
[21:36:38 CET] <JEEB> there's various per-packet checksum things
[21:38:37 CET] <thardin> another thing: what's the procedure to get new samples into the fate collection?
[21:38:59 CET] <JEEB> poking michaelni or so who has rights to upload, then stuff should get propagated after ~48h
[21:39:06 CET] <JEEB> and then the actual tests can start getting merged
[21:39:14 CET] <cone-287> ffmpeg 03Tomas Härdin 07master:abc5ac3cf517: palettegen: Fill with last color, not black
[21:39:29 CET] <JEEB> note: I just don't remember all the people with fate-samples access
[21:40:03 CET] <thardin> I have some codec2 samples in mind, they're tiny enough to be attached on the ML
[21:41:08 CET] <JEEB> alright, that's another way of requesting them to get uploaded
[21:41:46 CET] <thardin> neither encoder nor decoder at bitexact tho, so testing is somewhat limited. but being confident they decode without problems is better than nothing
[21:42:46 CET] <thardin> besides remuxing, which should be bitexact
[21:58:35 CET] <atomnuker> we don't test external libraries though
[23:05:55 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:c950beb68dee: aarch64: vp8: Fix assembling with clang
[23:05:56 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:7ddfa5e9083b: aarch64: vp8: Fix assembling with armasm64
[23:05:57 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:fecf75a5c4f6: aarch64: vp8: Remove superfluous includes
[23:05:58 CET] <cone-287> ffmpeg 03Martin Storsjö 07master:c8bc9d1380dd: aarch64: vp8: Move the vp8dsp makefile entries to the right places
[00:00:00 CET] --- Wed Feb 20 2019