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

[burek]

[00:20:08 CEST] <durandal_1707> atomnuker: i need 1, 2, 3, 4, 5, .., 256 dct 
[00:30:08 CEST] <atomnuker> eh, there's already a 5-point fft, I suppose I could use that to make a dct
[00:30:50 CEST] <atomnuker> the rest (3, and those above 5) will be very complicated
[00:47:47 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:2e700b082c81: Revert "avcodec/nvenc: make hw_frames_ctx fully optional"
[00:47:48 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:baabd3c2adb0: avcodec/nvdec: avoid needless copy of output frame
[00:47:49 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:c85568342741: avutil/hwcontext_cuda: add CUstream in cuda hwctx
[00:47:50 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:880236e898fd: avcodec/nvdec: pass CUstream in vpp parameters
[00:47:51 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:9b82e333b7c4: avutil/hwcontext_cuda: explicitly synchronize cuMemcpy calls
[00:47:52 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:93d1756af290: avcodec/cuviddec: explicitly synchronize cuMemcpy calls
[00:47:53 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:41a18982d092: avutil/hwcontext_cuda: add support for nvenc rgb formats
[00:47:54 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:ece068a771ac: avutil/hwcontext_cuda: use generic size and pointer assignment functions
[00:47:55 CEST] <cone-942> ffmpeg 03Timo Rothenpieler 07master:1c15d266150c: avfilter/vf_hwupload_cuda: update supported pix_fmts
[01:14:54 CEST] <klaxa> grml, apart from heisenbugs i think i'm ready to send the httpd-independent ffserver to the ML, will look through it tomorrow after having slept and clean it up a bit
[01:20:54 CEST] <tmm1> JEEB: woohoo http://0x0.st/sjjR.txt
[01:22:40 CEST] <JEEB> interesting
[01:31:52 CEST] <JEEB> that said completely new PIDs appear as well so a client needs to be dynamic. so in that sense I'm not sure if I have thought enough about abstracting this. esp. since A/V/S formats can switch between PMT updates with switching PIDs
[01:32:29 CEST] <JEEB> I'll try to review your PMT thing tomorrow^Wtoday after I get some sleep
[01:34:47 CEST] Action: JEEB hits the sack
[02:52:15 CEST] <cone-942> ffmpeg 03Thomas Mundt 07master:a3a6d4da6253: avformat/mxfenc: add h264 profiles
[03:28:16 CEST] <philipl> BtbN: found the hevc problem. bug in scaling list handling.
[11:36:31 CEST] <durandal_1707> atomnuker: have you answered my question about 2-256 dct? maybe I missed it?
[11:40:53 CEST] <BtbN> philipl, it's always scaling lists. It was when I implemented HEVC for vaapi. Those things are a mess
[11:53:25 CEST] <nevcairiel> took multiple tries for dxva as well, mostly because the way we store them disagrees with how hardware wants them, apparently
[12:03:51 CEST] <BtbN> it's also not a commonly used feature it seems
[12:03:58 CEST] <BtbN> so them being broken can go unnoticed for quite a while
[12:05:56 CEST] <BtbN> hm, I wonder if I should/can backport the cuvid frame mapping to 4.0
[12:06:13 CEST] <BtbN> it does not change any behaviour to the outside
[12:06:23 CEST] <BtbN> *nvdec
[12:06:32 CEST] <BtbN> And it makes it go fast
[12:06:47 CEST] <nevcairiel> its still a "feature" with potential new bugs
[12:07:56 CEST] <BtbN> I'm actually amazed how nothing broke with doing that
[12:08:08 CEST] <BtbN> I expected it to break at least something, but it really didn'T
[12:25:57 CEST] <atomnuker> durandal_1707: I think I did, but anyway, even-numbered DCTs will be done as usual, of the odd-numbered ones a 5-point (there's already an fft), a 15-point (already an fft), and maybe a 3-point if I can find a kernel
[12:34:03 CEST] <durandal_1707> atomnuker: i need at least: every number between 2 and 16
[13:00:09 CEST] <atomnuker> ok, I'll leave a naive dft for anything prime-numbered (which it will be optimal for) or unoptimized
[13:04:00 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:1655e1096e53: lavf/network: fix doxygen comments.
[13:38:34 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:b30575bc982f: checkasm/sw_rgb: fix the function declaration warning
[13:38:35 CEST] <cone-593> ffmpeg 03Jun Zhao 07master:74a7ddd985c4: lavfi/tests/filtfmts: fix the build warning.
[13:38:40 CEST] <durandal_1707> why i get heavy block artifacts when I do inverse dct of filtered coefficients?
[13:38:51 CEST] <durandal_1707> should I remove mean or something?
[13:45:16 CEST] <durandal_1707> i'm just doing hard thresholding - changing some too low coefficients to 0
[14:09:34 CEST] <durandal_1707> found it!
[14:15:13 CEST] <durandal_1707> if there is no comments i will apply fftdnoiz
[14:33:54 CEST] <durandal_1707> all denoisers that operates on blocks sucks, they need big overlap to be useful
[14:46:39 CEST] <cone-593> ffmpeg 03Paul B Mahol 07master:974eb4aaaa7d: avfilter: add fftdnoiz filter
[14:54:01 CEST] <atomnuker> durandal_1707: its just an inherent property of ordniary DCTs, you can't fix it
[15:44:03 CEST] <kierank> durandal_1707: hmmm gagandeep don't spent much time on irc
[16:02:44 CEST] <durandal_1707> kierank: he appeared for short time
[16:02:58 CEST] <kierank> he needs irc bouncer
[16:27:09 CEST] <durandal_1707> i wrote basic denoising for bm3d - its pretty good
[16:41:44 CEST] <BtbN> When backporting to 4.0, do I also backport the fix for the const warning? Even though it's not technically required, it fixes a warning and can't possibly cause any harm
[16:47:33 CEST] <philipl> BtbN: I would.
[16:48:36 CEST] <JEEB> right, that libbluray thing I should back-port as well
[16:49:25 CEST] <BtbN> Not sure if I should wait for longer with the const fix, or just push it. Can't think of anything it could possibly break or any unintended side-effects.
[16:56:26 CEST] <philipl> It's a compiler thing - either it leads to warnings/errors or it doesn't. :-)
[16:56:57 CEST] <philipl> And I want to push mine so I don't have to think about it anymore
[17:00:09 CEST] <JEEB> oh yes, cherry-pick -x is useful
[17:00:20 CEST] <JEEB> thank you to the kind people here for making me find it <3
[17:00:58 CEST] <cone-593> ffmpeg 03Jan Ekström 07release/4.0:8fde71acd9d1: lavf/bluray: translate a read of 0 to EOF
[17:01:08 CEST] <JEEB> I think I did it right
[17:44:53 CEST] <durandal_1707> ubitux: have you debuged why it can get bad edges in nlmeans filter?
[17:45:36 CEST] <ubitux> no, i haven't reproduced anything like that
[17:47:45 CEST] <durandal_1707> ubitux: with sample i sent you, i can only get blurry results, and not detailed like their filter
[17:48:11 CEST] <durandal_1707> if not blurry, then it have messed edges
[17:52:15 CEST] <ubitux> i don't know, i need time to work on this, i try to look at subtitles currently
[17:59:09 CEST] <gagandeep> kierank: i have obtained a progressive ip frame structured file
[17:59:22 CEST] <gagandeep> the one in ffmpeg samples is really messed up
[17:59:44 CEST] <gagandeep> also adobe after effects has only implemented i-frame structure currently
[18:00:07 CEST] <kierank> I thought you said ffmpeg file played in after effects
[18:00:14 CEST] <gagandeep> they don't support intra and inter(p-frame) encoding
[18:00:14 CEST] <kierank> gagandeep: btw you need to be on irc all the time
[18:00:21 CEST] <kierank> gsoc is a full time job
[18:00:50 CEST] <gagandeep> ok i will use my cell for irc during commute
[18:01:48 CEST] <gagandeep> and i confirmed with david newmann that group is the naming scheme for p frames
[18:01:53 CEST] <JEEB> I recommend grabbing one of those student benefit packages from github or whatever
[18:01:56 CEST] <kierank> gagandeep: so the ffmpeg file is not legal?
[18:02:10 CEST] <gagandeep> not legal? meaning
[18:02:12 CEST] <JEEB> which gives you a year's worth of free stuff like virtual servers
[18:02:39 CEST] <JEEB> so you can just have a client there and connect to it so you have a 24/7 client from which you can look at the backlog
[18:02:47 CEST] <JEEB> if you want something simpler there's also irccloud
[18:02:56 CEST] <JEEB> but that costs money for a constant connection
[18:03:17 CEST] <gagandeep> kierank:i mean the file on ffmpeg was not getting parsed correctly through TestCFHD
[18:03:27 CEST] <gagandeep> JEEB: i will look into it
[18:03:38 CEST] <kierank> gagandeep: yes and I think you should fix testcfhd to decode the file
[18:03:41 CEST] <kierank> it's a file in the wild
[18:03:48 CEST] <kierank> or fix it at ffmpeg level i guess
[18:03:54 CEST] <kierank> now that you have another p-frame sample
[18:04:39 CEST] <gagandeep> yeah
[18:05:14 CEST] <gagandeep> i mean ffmpeg and adobe was able to handle but TestCFHD being a bit simple decoder couldn't
[18:06:03 CEST] <kierank> I think you should figure out and patch TestCFHD to fix the problem
[18:06:12 CEST] <kierank> otherwise we can never bitexact verify the file
[18:08:22 CEST] <gagandeep> kierank: yeah and it might require looking into ffmpeg source as to how packets are handled
[18:08:51 CEST] <gagandeep> well i can't look into after effects
[18:09:22 CEST] <kierank> does anything actually decode the file correctly?
[18:10:04 CEST] <gagandeep> ffmpeg gives the error that a certain transform type 2 is not implemented
[18:10:15 CEST] <kierank> gagandeep: please answer the question
[18:10:51 CEST] <gagandeep> after effects was playing the file but the data is corrupt after half the file
[18:10:56 CEST] <kierank> ok
[18:11:11 CEST] <kierank> there is also mplayer binary loader I guess
[18:11:20 CEST] <gagandeep> what is that
[18:11:39 CEST] <kierank> gagandeep: MT_BeartoothHighway_1min_Cineform.avi  
[18:11:40 CEST] <kierank> this file?
[18:11:52 CEST] <gagandeep> yeah i am talking about this file
[18:12:10 CEST] <kierank> what about timelapse-pt-momsapt.avi
[18:13:32 CEST] <gagandeep> timelapse also has issues in after effects (corrupt data or something else) and the output in ffplay with this file i don't know if it is correct 
[18:14:37 CEST] <gagandeep> timelapse file does not even output anything in testcfhd
[18:14:46 CEST] <gagandeep> maybe also problems in container
[18:15:19 CEST] <kierank> I would guess these files work in mplayer binary loader
[18:15:22 CEST] <kierank> maybe worth setting that up
[18:15:35 CEST] <kierank> ask Compn
[18:15:42 CEST] <JEEB> nostalgy line
[18:16:46 CEST] <JEEB> was the OSS implementation from gopro in any way or form integrate'able? it might be useful to be able to compare the internal thing and that through FFmpeg?
[18:16:57 CEST] <JEEB> or am I thinking of the wrong format?
[18:17:14 CEST] <kierank> could be integrated yes, fair point
[18:17:23 CEST] <kierank> gagandeep: that's another approach JEEB suggests
[18:17:31 CEST] <kierank> might be easier than mplayer binary loader
[18:18:25 CEST] <gagandeep> i mean they have provided sdk so yes
[18:20:10 CEST] <kierank> gagandeep: yes, I think you should fork ffmpeg and integrate their sdk, would need to remove internal decoder or disable it somehow for that
[18:21:03 CEST] <JEEB> just disabling the internal one might be enough
[18:22:11 CEST] <gagandeep> let me get this straight, this is only for testing purposes
[18:22:43 CEST] <gagandeep> still the internal decoder needs to be written afterwards
[18:23:34 CEST] <JEEB> yes
[18:26:01 CEST] <gagandeep> i probably will need to hook the sdk after demuxers seperate packets or something like that
[18:26:09 CEST] <durandal_1707> JEEB: why disabling internal one? do not advise bad stuff
[18:26:32 CEST] <JEEB> did you miss the context?
[18:27:01 CEST] <durandal_1707> nope
[18:27:03 CEST] <JEEB> let me read it out for you then: he was recommended that he'd make a wrapper decoder for the official OSS decoder
[18:27:22 CEST] <durandal_1707> it can have both just fine
[18:27:31 CEST] <kierank> durandal_1707: sure but not for upstream
[18:27:36 CEST] <JEEB> ok, can you make ffmpeg.c prefer one or the other?
[18:27:37 CEST] <kierank> official decoder has simd-only codepaths
[18:27:45 CEST] <kierank> JEEB: i guess so because prores did it
[18:27:55 CEST] <JEEB> ok, then yes - that is the best alternative
[18:28:02 CEST] <JEEB> I just didn't remember about things in containers
[18:28:12 CEST] <JEEB> since I've had issues trying to override video or audio formats read from containers
[18:28:19 CEST] <JEEB> but I guess decoders are a different thing
[18:28:31 CEST] <gagandeep> yeah that simd threading
[18:28:38 CEST] <durandal_1707> kierank: sure, otherwise gagandeep would not be here
[18:29:00 CEST] <JEEB> but in any case, I don't see disabling the internal one for development purposes in a configure line as evil
[18:29:08 CEST] <durandal_1707> JEEB: there is options to select decoder in ffmpeg
[18:29:10 CEST] <JEEB> and I don't see that as necessarily *bad* *Advice*
[18:29:31 CEST] <durandal_1707> he can not compare their output easily
[18:29:31 CEST] <JEEB> yes, I goddamn know c:v perkele
[18:29:37 CEST] <JEEB> agreed
[18:29:45 CEST] <JEEB> I do fucking agree with you for fuck's sake
[18:29:53 CEST] <JEEB> stop arguing
[18:29:54 CEST] <JEEB> thank you
[18:30:21 CEST] <gagandeep> chill out guys, i am looking into it
[18:30:35 CEST] <JEEB> at the point of writing I was not 100% sure and the two alternatives kierank mentioned was removal from code base and disabling in configure
[18:30:45 CEST] <JEEB> so I pointed at the less hard of those
[18:30:48 CEST] <JEEB> jesus
[18:30:54 CEST] Action: durandal_1707 thinks mpv devs are nothing compared to mplayer ones
[18:31:04 CEST] <JEEB> lol
[18:31:54 CEST] <JEEB> I don't know what's your issue today, but you're getting pretty childish there
[18:32:09 CEST] <gagandeep> kierank: by the way how do you have all this knowledge regarding p-frames
[18:33:21 CEST] <gagandeep> i have no idea how reverse engineering works but did you get hands on some internal team doc, just asking
[18:33:42 CEST] <kierank> gagandeep: I saw file and saw that it had smaller frames
[18:33:46 CEST] <kierank> so assumed it must be p-frame
[18:33:54 CEST] <kierank> and I met david newman once and he said i was kinda right
[18:34:05 CEST] <durandal_1707> gagandeep: seriously it is not that hard, except if you look at VC-1
[18:34:32 CEST] <gagandeep> i mean i also had to confirm with david newmann about the ip structure
[18:35:02 CEST] Action: wm4 thinks durandal_1707 is a dumbass
[18:35:41 CEST] <wm4> annoyed me for weeks with some shitty bug reports that couldn't be reproduced
[18:35:53 CEST] <wm4> and broke stuff in libavformat trying to incompetently fix it
[18:36:20 CEST] <durandal_1707> i broke nothing, the seeking code is correct
[18:36:23 CEST] <wm4> and completely fucking unable to describe his problems accurately
[18:37:18 CEST] <gagandeep> kierank: ok will look into the virtual server cause frankly at campus while moving around the connection breaks and keeps reconnecting because of proxy
[18:38:16 CEST] <JEEB> gagandeep: https://education.github.com/pack
[18:38:19 CEST] <kierank> gagandeep: how long at university do you have left?
[18:38:32 CEST] <JEEB> I think this provides some credit for some VPS providers
[18:39:04 CEST] <gagandeep> i will be staying at university with summer stay
[18:39:24 CEST] <gagandeep> i mean the environment is more work friendly
[18:39:27 CEST] <JEEB> although depending on your capability of setting up something like a bouncer or irssi (and if you have the cash for it), irccloud might be a less technical alternative
[18:40:11 CEST] <kierank> gagandeep: ok
[18:40:24 CEST] <kierank> gagandeep: what are your working hours
[18:41:30 CEST] <gagandeep> currently from 2pm to 11pm
[18:42:04 CEST] <gagandeep> i take a bit of break in between for lunch or refreshments
[18:42:55 CEST] <cone-593> ffmpeg 03Timo Rothenpieler 07master:46c1ee19171c: avcodec/hevcdec: make ff_hevc_frame_nb_refs take a const pointer
[18:42:56 CEST] <cone-593> ffmpeg 03Philip Langdale 07master:126100370032: avcodec/nvdec_hevc: fix scaling lists
[18:43:11 CEST] <kierank> gagandeep: ok
[18:45:41 CEST] <gagandeep> from your uk standards that would be 8:30 - 17:30
[18:50:41 CEST] <kierank> ok good, quite convenient for me
[18:56:49 CEST] <cone-593> ffmpeg 03Timo Rothenpieler 07release/4.0:61b673b1f101: avcodec/hevcdec: make ff_hevc_frame_nb_refs take a const pointer
[18:56:50 CEST] <cone-593> ffmpeg 03Philip Langdale 07release/4.0:2a44f706aa14: avcodec/nvdec_hevc: fix scaling lists
[20:07:13 CEST] <aakravchenko188> Hi
[20:20:12 CEST] <akravchenko188> Hello guys, I would like to support AMF encoder + implement few new AMF components in FFmpeg.
[20:21:13 CEST] <akravchenko188> I sent patch 2 weeks ago, but didn't receive any comments
[20:22:45 CEST] <akravchenko188> could you help me what to do?
[20:24:15 CEST] <akravchenko188> I could propose myself as maintainer of amf at the beginning and other HW support later
[20:36:23 CEST] <akravchenko188> is this ok?
[20:38:24 CEST] <BtbN> ping it
[20:48:58 CEST] <atomnuker> akravchenko188: too soon, you're not going to push anything without review!
[20:49:18 CEST] <atomnuker> ping the patchset again until someone's bothered enough to review it
[20:50:29 CEST] <atomnuker> last time someone nominated themselves as a maintainer for something few cared about we got dash and hls issues
[20:51:56 CEST] <JEEB> but coming to the IRC is a good idea; generally you can catch different people here :P
[20:52:43 CEST] <JEEB> unfortunately I have nfi about AMF so I cannot be of help
[20:53:29 CEST] <JEEB> tmm1: I'm finally getting to looking at your PMT fixup :| so many darn distractions
[21:03:57 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:7e78801fa580: vaapi_encode: Add an assert in vaapi_encode_truncate_gop()
[21:03:58 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:bed670a1de29: hwcontext_vaapi: Add an assert in vaapi_map_from_drm()
[21:05:54 CEST] <jkqxz> akravchenko188:  I need to reconstitute a Windows+AMD machine to try it, I'm intending to do that this weekend.
[21:06:43 CEST] <jkqxz> If you have any following patch using it then I suggest sending it.  It's easier to review things when the use is there as well.
[21:16:16 CEST] <jkqxz> Is the Sony_4K_Camp HDR demo video meant to contain random shit in the HDR metadata fields?
[21:16:22 CEST] <JEEB> yes
[21:16:30 CEST] <JEEB> it has like 0.05 nits or something set for max brightness
[21:16:39 CEST] <JEEB> that's the reason why mpv got some sanity checks on those fields
[21:16:43 CEST] <JEEB> you'd think sony got that stuff right
[21:16:53 CEST] <JEEB> they probably meant 5000 nits but got the range wrong or something
[21:17:02 CEST] <JEEB> since the value is literally five if I recall correctly
[21:18:03 CEST] <jkqxz> <https://0x0.st/sj45.txt>.  I like those display primaries, too.
[21:19:03 CEST] <JEEB> lol
[21:19:35 CEST] <jkqxz> (The unit is *10^-4 nits, yeah.)
[21:20:08 CEST] <JEEB> yup
[21:33:06 CEST] <jkqxz> Apparently LG and Samsung are better at this.  (Or at least, the values look vaguely sensible.)
[21:34:02 CEST] <JEEB> yea
[21:50:52 CEST] <durandal_1707> atomnuker: when to expect that dct patch?
[21:52:24 CEST] <JEEB> tmm1: can you remind me which point of the H.222 spec that stuff you poked was in?
[21:53:49 CEST] <akravchenko188> thanks for your answers
[21:56:18 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:56ed01169269: cbs_h265: read/write HEVC PREFIX SEI
[21:56:19 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:345b6962b68b: vaapi_encode_h265: Insert mastering display colour volume
[21:56:20 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:2943dd35b759: cbs_h265: read/write content light level information SEI message
[21:56:21 CEST] <cone-593> ffmpeg 03Haihao Xiang 07master:0612e29b59d4: vaapi_encode_h265: Insert content light level information
[21:58:59 CEST] <tmm1> JEEB: i didnt check the spec, not sure if its in there or this is something only my cable provider does
[21:59:47 CEST] <JEEB> if something like dvb inspector implements it, it's in the spec
[21:59:59 CEST] <JEEB> of course the usage of the spec is up to the broadcasters
[22:01:25 CEST] <JEEB> but yea, will need to figure what structure it is that your
[22:01:28 CEST] <JEEB> *you're parsing
[22:02:40 CEST] <tmm1> sure, it should be wherever it describes the contents of PMT
[22:02:51 CEST] <akravchenko188> I just proposed myself as maintainer of amf, because nobody listed in maintainers for amfenc and I know architecture of AMF quite well. probably I need more experience in FFmpeg development but it is matter of time. may be later
[22:03:21 CEST] <JEEB> oh, so that was PMT itself... let's see
[22:03:49 CEST] <JEEB> I'm really thankful for ITU-T that they mistakenly opened access to H.222 back in 2012 :P
[22:03:58 CEST] <JEEB> was really nice for the young student me
[22:06:41 CEST] <kierank> yes, same
[22:07:58 CEST] <JEEB> kierank: btw in your cases would you drop or buffer all packets that come for a program before you got PCR?
[22:08:08 CEST] <atomnuker> durandal_1707: this weekend
[22:08:12 CEST] <kierank> JEEB: pcr?
[22:08:18 CEST] <JEEB> Program Clock Reference
[22:08:21 CEST] <JEEB> which you probably knew
[22:08:37 CEST] <kierank> yeah, i mean the question is strange
[22:09:04 CEST] <kierank> i would just parse packets as normal, wouldn't need pcr for anything
[22:09:05 CEST] <JEEB> basically I'm thinking of the best way of fixing an issue that happens when weirdly timestamped packets get ingested before PCR is around to help the demuxer unmangle the timestamps
[22:09:39 CEST] <JEEB> because I've seen some people mux unrelated subtitle streams with their original PTS
[22:09:46 CEST] <kierank> some teletext has no pt
[22:09:47 CEST] <kierank> pts
[22:10:03 CEST] <JEEB> yea, I've checked that the PTS is there, but it's 8.5h before video PTS :D
[22:10:13 CEST] <JEEB> after you receive PCR there's some logic to fix that
[22:10:40 CEST] <JEEB> but the framework goes berserk if you ingest multiple streams' packets before you get PCR
[22:11:11 CEST] <JEEB> "oh we just got 8xxxxx, and now we got 5xxxxx - there must have been a wrap-around!" and then you suddenly you have timestamps way in the future
[22:11:35 CEST] <JEEB> so I need to either decide on dropping packets before PCR, or buffering them so that they can be re-adjusted if needed after PCR is received
[22:11:46 CEST] <tmm1> what if read_header doesnt return until it sees pcr?
[22:12:04 CEST] <tmm1> so pcr is always set after probe finishes
[22:12:54 CEST] <JEEB> that sounds like one way of doing it
[22:12:59 CEST] <kierank> JEEB: in my use case i wouldn't be able to handle that kind of stuff
[22:13:14 CEST] <JEEB> ok
[22:13:36 CEST] <JEEB> I did tell the people muxing this stuff to not do it, but it seems like they just really like to have teletext in a mux
[22:15:01 CEST] <kierank> teletext I can handle
[22:15:06 CEST] <kierank> well upipe and vlc can
[22:15:11 CEST] <kierank> they do pcr+offset
[22:15:24 CEST] <JEEB> yea
[22:15:29 CEST] <JEEB> I mean, the demuxer does handle that
[22:15:42 CEST] <JEEB> but I get stuff like video packet - teletext packet - PCR - teletext packet
[22:15:57 CEST] <JEEB> and the framework gets really confused at the second packet
[22:15:57 CEST] <JEEB> :D
[22:16:18 CEST] <JEEB> the second teletext packet gets fixed with the PCR
[22:16:40 CEST] <JEEB> which is why I thought I'd either discard packets until PCR, or buffer them
[22:16:45 CEST] <akravchenko188> guys, one more question, could you recomment mobile irc chat software. for ios?
[22:17:04 CEST] <JEEB> akravchenko188: if you don't like mobile ssh clients, irccloud seems to be alright?
[22:17:12 CEST] <JEEB> they basically keep a session open for you for 2 hours for free
[22:17:21 CEST] <JEEB> (as in, when you are not connected)
[22:17:38 CEST] <JEEB> and if you pay some they just give you eternal connections
[22:18:24 CEST] <JEEB> and of course tmm1's way of making sure PCR is set at probe is also a good idea I guess
[22:18:44 CEST] <akravchenko188> thanks, I will try
[22:21:14 CEST] <JEEB> lol, just ran static analysis on mpegts.c
[22:21:49 CEST] <JEEB> au_end_flag is not utilized anywhere in read_sl_header. I guess it's from the spec, but still kind of funny :)
[22:41:44 CEST] <cone-593> ffmpeg 03Anton Leontiev 07master:94818025394b: lavd/v4l2: Add ARGB and XRGB packed pixel formats
[22:44:10 CEST] <jkqxz> akravchenko188:  I replied with what I can see from just reading it; I will try to actually test it later this week.
[23:04:44 CEST] <cone-593> ffmpeg 03Carl Eugen Hoyos 07master:6dc79637f34f: lavc/qdrw: Read PixMap palette.
[23:14:09 CEST] <akravchenko188> jkqxz: thanks, I will send answer and fixes tomorrow
[23:17:05 CEST] <kierank> JEEB: btw, in my use case i don't buffer
[23:17:10 CEST] <kierank> variable latency and all that
[23:17:29 CEST] <JEEB> yea
[23:18:01 CEST] <JEEB> the only reason I'd do that is because people would start complaining about "lost" packets if I just dropped everything from before PCR arrives
[23:18:11 CEST] <kierank> true
[23:18:13 CEST] <JEEB> I think vlc drops things before
[23:18:19 CEST] <JEEB> although I'm not 100% sure
[00:00:00 CEST] --- Fri May 11 2018