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

[burek]

[00:13:42 CEST] <jamrial> jkqxz: re annexb(8since i see you're handling it), i thought the idea was to treat that as a container format and make sure it was never propagated as is internally
[00:14:18 CEST] <jamrial> so packets would only ever contain Low Overhead Bitstream Format obus
[00:14:51 CEST] <jamrial> so no need to handle it in cbs
[00:15:15 CEST] <jkqxz> I haven't done any more with that, the stuff there is the same as before and won't match current libaom.
[00:15:28 CEST] <jamrial> ah ok
[00:15:49 CEST] <jkqxz> (Mostly a "wait and see".)
[00:16:32 CEST] <jkqxz> If it's a container, you'd put the size-handling stuff in lavf only if you wanted to implement it?
[00:18:07 CEST] <jamrial> you mean for obus without a leb128 size field?
[00:18:13 CEST] <jkqxz> Maybe it's best to handle it on input, but never create it.  That's not difficult to do.
[00:18:16 CEST] <jkqxz> Yeah.
[00:20:58 CEST] <jamrial> annexb demuxer would extract the obus from each annexb temporal unit, and add the size field if required to the last obu on each annexb frame
[00:21:48 CEST] <jamrial> better to have lavf handle that so no packet ever has annexb encapsulated data
[00:22:13 CEST] <jamrial> we were able to get mp4 and matroska to only use raw obus for this purpose :p
[00:33:00 CEST] <cone-735> ffmpeg 03Danil Iashchenko 07master:7cd58a8a8c53: lavfi/convolution_opencl: use CL_FAIL_ON_ERROR for error handling
[00:45:32 CEST] <jkqxz> Would "select operating point" want to be a separate bsf?
[00:45:53 CEST] <nevcairiel> whats an operating point
[00:46:47 CEST] <jkqxz> Stream layer identifer for scalable stuff.
[00:46:58 CEST] <nevcairiel> ie. a feature never going to be used?
[00:47:21 CEST] <nevcairiel> they try to add scalability features into all codecs, and i never see them used anywhere
[00:49:39 CEST] <jkqxz> Vidyo did it with H.264!  (And then spent years trying to convince everyone it was a good idea, but noone cared.)
[00:49:48 CEST] <nevcairiel> heh
[00:50:00 CEST] <jamrial> jkqxz: i think you should be setting frame_type on each refreshed AV1ReferenceFrameState in read_uncompressed_header
[00:51:03 CEST] <jamrial> you're reading the field when show_existing_frame == 1, but i can't see where it's being set
[00:51:06 CEST] <jkqxz> Hmm, yeah.
[00:51:41 CEST] <jkqxz> The reference frame information stuff needs to be cleaned up generally.
[00:54:05 CEST] <atomnuker> jkqxz: does that mean there may be multiple operating points within a single stream?
[00:54:31 CEST] <jkqxz> Yes.
[00:55:31 CEST] <atomnuker> so multple decodable video sizes from a single stream?
[00:57:58 CEST] <atomnuker> dunno if the decoder would be more appropriate
[00:58:39 CEST] <jkqxz> That's how H.264 SVC works.  I don't know if that stuff (including deterministic scaling for references to smaller layers) is actually defined here.
[00:59:44 CEST] <atomnuker> a separate bsf would work if the decoder could handle switching whilst keeping/resizing the reference frames
[01:00:23 CEST] <jkqxz> No, the decoder is too late for that.  The idea is that you can do things like dropping layers in the network if there isn't enough bandwidth.
[01:01:22 CEST] <cone-735> ffmpeg 03Carl Eugen Hoyos 07master:5545a6df879f: lavc/h263dec: Remove a variable declaration that can lead to a warning.
[01:01:51 CEST] <atomnuker> wouldn't the bsf just error out saying there's no such layer (anymore), so you'd reinit the bsfs with a new layer and feed the decoder the new packets?
[01:02:18 CEST] <atomnuker> the whole point of scalability was afaik to be able to switch instantly between qualities
[01:03:16 CEST] <jkqxz> The bsf isn't for decode-time.
[01:04:42 CEST] <atomnuker> oh, nvm then, I misunderstood
[01:05:02 CEST] <atomnuker> yeah, I think its reasonable to have a separate bsf for that
[01:08:41 CEST] <jkqxz> Though yeah, there is still the question of whether anyone will ever care.  (I do wonder what the people who semi-regularly ask for H.264 SVC in ffmpeg actually want it for.)
[01:11:44 CEST] <atomnuker> they kinda do; there's still a bounty for it afaik but the patches were rejected 2 or so years ago iirc
[01:16:20 CEST] <nevcairiel> patches get rejected when they are bad, not because we dislike the feature, apparently noone cared enough to make it nice then
[01:19:11 CEST] <atomnuker> yep, absolutely, and they were bad iirc
[02:22:35 CEST] <cone-735> ffmpeg 03Michael Niedermayer 07master:aba13dc13e52: avformat/mov: Break out of inner loop early in mov_estimate_video_delay()
[02:22:36 CEST] <cone-735> ffmpeg 03Karsten Otto 07master:ce372bc278ce: libavcodec/mpegaudiodecheader.h: fix version check pattern
[02:22:37 CEST] <cone-735> ffmpeg 03Michael Niedermayer 07master:b0644f7f72a9: avformat/mov: Simplify last element computation in mov_estimate_video_delay()
[03:25:33 CEST] <memeka> hi, is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line?
[03:26:54 CEST] <memeka> the AVCodecContext  pix_fmt
[06:42:43 CEST] <cone-290> ffmpeg 03Gyan Doshi 07master:1a31c2b5df11: avfilter/drawtext: fix box sizing
[07:16:10 CEST] <memeka> is it possible to set the pix_fmt sent to the decoder from the ffmpeg command line? the AVCodecContext  pix_fmt
[07:20:46 CEST] <seodisparate> I'm having trouble getting 'configure' to recognize the new filter I'm writing. Is there more documentation besides "doc/writing_filters.txt" about setting up a filter?
[07:25:28 CEST] <seodisparate> oh wait... wow for some reason it's working again? I'm not quite sure what fixed it but I guess I no longer need help on this issue..?
[07:26:04 CEST] <cone-290> ffmpeg 03Gyan Doshi 07master:97d766ff52fb: doc/filters: correct description of variables in blend filter
[07:26:52 CEST] <seodisparate> I'm guessing that invoking "git clean -xfd" to remove some cached files might have fixed it after changing configure...
[07:38:08 CEST] <seodisparate> I acutally identified my problem, it seems adding the string "gplv3" to the *_filter_deps of my filter in 'configure' seems to cause it to not be enabled even if the flag "--enable-version3" is set (for GPL3)
[07:38:56 CEST] <seodisparate> oh, it looks like I have to use "version3" instead of "gplv3"
[09:15:10 CEST] <gagandeep_> related to threads: what are the restrictions on reading and writing to a same memory block
[09:21:44 CEST] <gagandeep_> i need to understand this so as to properly allocate memory for the threads working
[09:23:16 CEST] <rcombs> that's a little bit vague
[09:23:38 CEST] <rcombs> are you asking about, like, how C's memory model works
[09:24:19 CEST] <gagandeep_> kierank: had told me that some write restrictions are there for multiple threads writing to memory
[09:28:37 CEST] <gagandeep_> so i am asking are there some restrictions in place in ffmpeg frame thread model
[09:28:39 CEST] <kierank> well if you have multiple threads writing you can obviously read
[09:28:41 CEST] <kierank> can't
[09:28:58 CEST] <kierank> because you can't guarantee the data will be consistent
[09:29:48 CEST] <gagandeep_> ok, so i shouldn't be getting a system generated error from that part
[09:30:21 CEST] <gagandeep_> it is a logical error but not a system error, right?
[09:30:49 CEST] <kierank> you'll have nondeterministic errors
[09:32:39 CEST] <gagandeep_> ok, so if in cfhd case, one thread is reading the coefficients for the next subbands and writing them in allocated memory, while the other thread is decoding the previous wavelet and writing it in the same memory but at an independent location in same memory
[09:33:02 CEST] <gagandeep_> i don't think here i should have error, from this part
[09:33:51 CEST] <kierank> should be ok
[09:34:04 CEST] <kierank> but not clear exactly what you mean "same memory"
[09:34:30 CEST] <gagandeep_> the large chunk of memory allocated in first thread to store all the coefficients in the packet
[09:34:39 CEST] <kierank> gagandeep_: there is a program called tsan which can help you check for race conditions
[09:34:56 CEST] <gagandeep_> i know about race conditions
[09:34:57 CEST] <kierank> as long as there is no overlap it's fine
[09:35:20 CEST] <gagandeep_> k, i am just working out the logic to get the decoding distributed across the 2 threads
[09:35:53 CEST] <gagandeep_> also, update_thread_context runs after finish_thread_setup?
[09:36:13 CEST] <kierank> not sure about that bit
[09:36:16 CEST] <kierank> not familiar with the thread code
[09:36:35 CEST] <gagandeep_> k, was not able to see this update bit in the code
[09:36:44 CEST] <gagandeep_> rest is much clear now
[14:19:49 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:896854b2336f: lavc/hevc_ps: Refine sps_range_extension parse.
[14:19:50 CEST] <cone-290> ffmpeg 03Jun Zhao 07master:d746a2e3cf5c: lavc/hevc_ps: use skip_bits instead of get_bits when skip bits.
[17:53:33 CEST] <Mathieu_Du> Hey, is it possible to cherry-pick e84212b78e00df17799e01be1e153a073eb8f689 to the release/4.0 branch ?
[17:56:09 CEST] <jdarnley> Ping the maintainer of 4.0?
[17:59:27 CEST] <Mathieu_Du> I assume that would be michaelni ?
[18:16:37 CEST] <jdarnley> God damn fuzzing people!  You broke dirac decoding with your "undefined behaviour"!
[18:17:40 CEST] <jdarnley> 575d8ca026 "avcodec/dirac_dwt_template: Fix undefined behavior in interleave()"
[18:18:47 CEST] <jdarnley> I guess it is only for >8bit otherwise fate would have caught it.
[18:31:21 CEST] <michaelni> Mathieu_Du, only 4.0 or do other releases need this too ?
[18:32:02 CEST] <Mathieu_Du> michaelni, afaict only 4.0 is affected, as the commit that introduced the issue happened recently
[18:32:08 CEST] <Mathieu_Du> let me find the hash
[18:32:38 CEST] <Mathieu_Du> that was b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b
[18:36:10 CEST] <michaelni> that one was backported so the fix is needed in more branches
[18:38:46 CEST] <Mathieu_Du> michaelni, I checked, it's indeed in 3.4
[18:38:59 CEST] <Mathieu_Du> not in 3.3 so I would assume nowhere elese ?
[18:40:34 CEST] <michaelni> ill backport it locally to all branches that seem to need it so it should be included where its needed 
[18:41:28 CEST] <Mathieu_Du> OK, thanks!
[18:45:39 CEST] <BtbN> Working on android sure is fun. "Let me rebase those two patches real quick!" Now it's 2 hours later. It still rebasing.
[19:03:26 CEST] <michaelni> jdarnley, ill fix it unless you already did ? can you add a fate test for this ?
[19:25:19 CEST] <Mathieu_Du> michaelni, want me to file an issue somewhere or that's not needed ? :)
[19:33:49 CEST] <jdarnley> michaelni: I have more fate tests.  I didn't fix only reverted but I will make a fix for both the "undefined behaviour" and the decoding error if that's what you want.
[19:48:08 CEST] <michaelni> jdarnley, already posted: (1,2K) [FFmpeg-devel] [PATCH 1/4] avcodec/dirac_dwt_template: Fix signedness regression in interleave()
[19:48:32 CEST] <michaelni> can you check if that works/fixes it, or was there some other issue too ?
[19:49:06 CEST] <michaelni> Mathieu_Du, not needed
[19:51:50 CEST] <Mathieu_Du> ack :)
[19:57:51 CEST] <jdarnley> michaelni: that does fix it.  I will also send an email reply for the record.
[20:01:13 CEST] <jdarnley> And I was wrong about the >8bit depth being the cause.  Only some of the wavelet transforms use that deinterleave function, haar and 5_3 which we don't test.
[20:03:30 CEST] <electron_rotosco> Hello I have a question about a bug I submitted a few weeks ago to trac.ffmpeg.org here https://trac.ffmpeg.org/ticket/7280 It got moved to "enhancement" but I think of it as a defect, I'm not sure how to tell the difference
[20:05:10 CEST] <jdarnley> A defect would be existing code producing an incorrect result.  You want 12-bit encoding added from what I read.
[20:05:14 CEST] <electron_rotosco> I'm sure problems with the dnxhd module aren't the highest priority in terms of how many users interact with it of course
[20:05:33 CEST] <electron_rotosco> Yes. 10-bit encoding is incorrect for the spec
[20:06:07 CEST] <electron_rotosco> So either it needs to be 12 bit or I would think it should be disabled.
[20:06:15 CEST] <jdarnley> Then perhaps we need to abort if we can't satisfy the spec with the current code.
[20:06:38 CEST] <electron_rotosco> I don't know if the current code could just be switched to 12 bit mode, I don't know what's involved with that
[20:06:49 CEST] <jdarnley> Along the lines of what x264 does when the users asks for or gives incompatible restraints.
[20:07:02 CEST] <jdarnley> I don't know either.
[20:07:30 CEST] <electron_rotosco> Yeah that makes sense. Or a warning like "This will be incompatible with some equipment" like x264 used to do (maybe still does) if you try to use it in 10 bit mode
[20:07:47 CEST] <kierank> That's not a correct statement
[20:08:06 CEST] <electron_rotosco> which statement is that?
[20:08:22 CEST] <kierank> Incompatibility with equipment 
[20:08:51 CEST] <JEEB> FFmpeg's libx264 wrapper notes that since you're not using 8bit 4:2:0 some (consumer) stuff might not be able to decode it
[20:08:57 CEST] <JEEB> it's not that the stream is out of spec for anything
[20:09:04 CEST] <nevcairiel> the x264 warning was not because it was invalid, just because it was uncommon
[20:09:08 CEST] <JEEB> yes
[20:09:11 CEST] <electron_rotosco> yes
[20:09:21 CEST] <nevcairiel> if its actually generating something thats invalid to the spec, then it should just not be able to do that anymore until its properly implemented
[20:09:26 CEST] <kierank> The underlying codec is fine
[20:09:26 CEST] <JEEB> yea
[20:09:34 CEST] <electron_rotosco> HQX recorded in 10-bit mode is technically outside of the spec, but some equipment will play it back
[20:09:43 CEST] <electron_rotosco> *encoded not recorded
[20:09:45 CEST] <kierank> That's not how dct codecs work
[20:10:18 CEST] <kierank> You can have whatever bitdepth you want in and whatever you want out
[20:10:31 CEST] <kierank> It's just shifting
[20:10:37 CEST] <electron_rotosco> I mean DNxHD HQX is a specific profile defined by Avid. Sure it will work but you can't just make it whatever bit rate you want
[20:10:55 CEST] <JEEB> bit depth != bit rate
[20:10:58 CEST] <nevcairiel> so its just going to be inaccurate?
[20:11:14 CEST] <kierank> Sure but it's dct to begin with
[20:11:23 CEST] <kierank> So it's inaccurate anyway
[20:11:48 CEST] <electron_rotosco> dnxhd and prores are dct codecs with specific profiles associated with them
[20:11:49 CEST] <nevcairiel> well more so, of course i dont know if any other bitdepth things are coded anywhere, like recording the input bitdepth in a header for example
[20:12:23 CEST] <electron_rotosco> there are pieces of hardware and software that expect certain profiles within those codecs
[20:12:28 CEST] <electron_rotosco> those profiles define bit rate and bit depth
[20:12:33 CEST] <kierank> I can put 1 bit data in if I want
[20:12:36 CEST] <kierank> Doesn't matter
[20:12:45 CEST] <electron_rotosco> yeah but it won't follow the profile
[20:13:25 CEST] <electron_rotosco> The current code for libavcodec\dnxhdenc.c has a line "pixel format is incompatible with DNxHR HQX profile" if you try to encode it in 12 bit mode
[20:13:46 CEST] <electron_rotosco> which is, as far as I can tell, inaccurate. The profile should only be 12 bit, and never 10 bit
[20:14:00 CEST] <JEEB> does the format have a concept of bit depth in itself?
[20:14:38 CEST] <electron_rotosco> I'm not sure if this is what you mean, but this documentarion for the format http://avid.force.com/pkb/articles/en_US/White_Paper/DNxHR-Codec-Bandwidth-Specifications specifies bit depth
[20:14:45 CEST] <electron_rotosco> *documentation
[20:14:50 CEST] <JEEB> if yes, and there's a spec that says that the profile we're advertising should require 12bit input, then we check the place that is the defining part of it
[20:15:00 CEST] <JEEB> *input and coding
[20:15:13 CEST] <JEEB> and then the thing gets disabled until the feature's in
[20:16:12 CEST] <kierank> electron_rotosco: it will follow the profile
[20:16:21 CEST] <kierank> you conflate input bit-depth with output bit-depth
[20:16:31 CEST] <kierank> an encoder can choose to support what it wants and it will play
[20:16:52 CEST] <JEEB> ok, so the format effectively encodes either at no bit depth or at 12bit?
[20:17:06 CEST] <JEEB> and the input for the codec just happens to be 10bit, since that's what mostly used as input for such encoder
[20:17:07 CEST] <electron_rotosco> for that profile yes, that would be the spec as I understand it
[20:17:17 CEST] <electron_rotosco> the input can be whatever
[20:17:27 CEST] <electron_rotosco> 8 bit, 10 bit, 12 bit, 16 bit
[20:17:34 CEST] <JEEB> in a larger application yes, which converts to whatevert the encoder part takes in
[20:17:37 CEST] <electron_rotosco> I mean according to the profile anyways there's no restrictions
[20:17:47 CEST] <electron_rotosco> I don't know about the code in ffmpeg
[20:18:00 CEST] <JEEB> encoders usually take their input at bit depth X
[20:18:07 CEST] <JEEB> in FFmpeg and outside of it
[20:18:16 CEST] <JEEB> some just hide it from you :P
[20:18:32 CEST] <JEEB> also some video formats will internally always code at bit depth X, but then have a flag about "what was the input bit depth"
[20:18:37 CEST] <electron_rotosco> @kierank: the encoder currently forces output to 10 bit but it should be forcing to 12 bit
[20:18:38 CEST] <BradleyS> commercial encoders will likely make 12-bit from any bit depth input
[20:18:52 CEST] <kierank> electron_rotosco: nope, the encoder doesn't do anything
[20:19:04 CEST] <electron_rotosco> Avid Media Encoder only produces 12-bit content if you use the DNxHR HQX profile
[20:19:05 CEST] <kierank> there an "internal bit-depth"
[20:19:11 CEST] <BradleyS> so the issue is whether that's a manual step in ffmpeg at the input/filter stages or whether the encoder does this internally
[20:19:38 CEST] <BradleyS> (not literally internally, but forces the appropriate depth conversion)
[20:19:54 CEST] <electron_rotosco> @keirank: I'm not sure, but lines 385 to 398 of libavcodec\dnxhdenc.c seem to be forcing a bit depth of 10 bits on output
[20:20:02 CEST] <JEEB> encoders only take input
[20:22:04 CEST] <electron_rotosco> I guess specifically lines 394 to 398
[20:22:35 CEST] <electron_rotosco> "if (ctx->profile == FF_PROFILE_DNXHR_HQX && avctx->pix_fmt != AV_PIX_FMT_YUV422P10)" then produce error
[20:23:20 CEST] <electron_rotosco> but the flagship product that was released with this format, Avid Media Composer, only makes files in that profile at yuv422p12le
[20:24:51 CEST] <BradleyS> so input format/depth is restricted but incorrectly
[20:25:36 CEST] <kierank> no you're conflating a number of different things here
[20:25:43 CEST] <kierank> if I understand correctly
[20:26:35 CEST] <kierank> but ask paul
[20:27:12 CEST] <JEEB> I see in the decoder at least that there's a random flag in the bit stream that says 8/10/12, and a separate DCT function is used for 12bit
[20:27:24 CEST] <JEEB> so now the question is how defines that profile
[20:27:43 CEST] <JEEB> is it somewhere in ISO/SMPTE/licker place, or some random proprietary vendor
[20:28:01 CEST] <JEEB> and then whatever is hte authority should be checked regarding that profile
[20:28:26 CEST] <electron_rotosco> I think it's known to SMPTE as VC-3
[20:28:59 CEST] <JEEB> wasn't VC-3 the gopro thing?
[20:29:03 CEST] <JEEB> or was that VC-4
[20:29:53 CEST] <electron_rotosco> VC-3 was DNxHD
[20:30:03 CEST] <electron_rotosco> I'm not sure if DNxHR falls under that or not
[20:30:31 CEST] <BradleyS> kierank: genuinely, i'm not sure what else the quoted line would do... what are we missing?
[20:31:33 CEST] <kierank> you can produce 12-bit output with 10-bit input
[20:32:03 CEST] <electron_rotosco> not as the code is now
[20:32:21 CEST] <electron_rotosco> if you feed it 12 bit input or 10 bit input and try to force the output to 12 bit it just gives an error and stops
[20:32:32 CEST] <JEEB> electron_rotosco: btw the guy who edited the ticket and the guy who commented "This is just not correct" are not the same person
[20:32:49 CEST] <electron_rotosco> @JEEB yeah I know. I wasn't sure at the motivations for either thing
[20:32:52 CEST] <JEEB> electron_rotosco: also in FFmpeg generally the encoders don't take in anything else than they support
[20:33:37 CEST] <JEEB> as in, if the encoder supports 12bit it should do that with 12bit input being a requirement
[20:34:23 CEST] <JEEB> as far as I can see the dnxhdenc only supports 10bit, and thus the encoder requires 10bit input for that. and then there's some random profile limitation which you have noticed.
[20:34:30 CEST] <JEEB> I should check who added that chekc
[20:34:52 CEST] <JEEB> that might lead one to the source/definition of that requirement
[20:35:27 CEST] <electron_rotosco> There has been some confusion online about that in the past so that might be where that came from. I suspect Avid originally intended it to be a 10 bit profile and then changed their mind
[20:35:41 CEST] <electron_rotosco> Avid the company that is
[20:36:06 CEST] <JEEB> aand it was durandal_1707 in f078bc4c5e6675a93166a7e5b23feb5b04ac9320
[20:36:20 CEST] <JEEB> so if he based that requirement on something he should know what he based that requirement on :)
[20:36:36 CEST] <electron_rotosco> Makes sense! :)
[20:38:14 CEST] <JEEB> also the 2016 12bit thing is for the decoder
[20:38:18 CEST] <JEEB> which supports 12bit IDCT
[20:39:05 CEST] <electron_rotosco> Which is good, since that's the only way that Avid makes HQX files
[20:39:12 CEST] <electron_rotosco> Avid Media Composer that is
[20:40:02 CEST] <electron_rotosco> Actually my code output at https://trac.ffmpeg.org/ticket/7280#comment:1 is decoding a 12 bit stream
[20:40:30 CEST] <JEEB> yes, that thing you linked was just an unrelated patch adding a decoding test sample for 12bit mode
[20:40:46 CEST] <electron_rotosco> aaah I see
[20:41:48 CEST] <durandal_1707> electron_rotosco: i have actual specification
[20:42:24 CEST] <JEEB> durandal_1707: so SMPTE defines these profiles?
[20:43:25 CEST] <JEEB> specifically "DNxHR HQX profile"
[20:46:00 CEST] <durandal_1707> yes, and 444 one
[20:46:09 CEST] <durandal_1707> they can be both 10 and 12 depth
[20:46:27 CEST] <JEEB> and we just don't implement 12bit, which is OK because both are then valid
[20:46:41 CEST] <JEEB> if you can get a quote/screenshot of the spec
[20:46:48 CEST] <JEEB> and link it in the trac issue, that'd be fabulous
[20:47:00 CEST] <durandal_1707> 12 could be added easily if someone wants to actually sponsor that
[20:47:22 CEST] <JEEB> yea, definitely not free work because of where that format gets used :)
[20:47:44 CEST] <electron_rotosco> oh man is there a place to get information about that
[20:47:56 CEST] <electron_rotosco> We've never sponsored development before
[20:48:50 CEST] <JEEB> I'm not sure if we have guide lines on that - most such work tends to be a contract between a developer and the sponsoring party. or then something like VideoLAN's bounties.
[20:49:04 CEST] <electron_rotosco> right now 10 bit HQX is useless because of https://trac.ffmpeg.org/ticket/4973
[20:50:55 CEST] <electron_rotosco> Well not useless completely, but can't be used with Avid Media Composer in the same timeline as HQX generated by Avid
[20:51:33 CEST] <JEEB> also whatever trac is doing to that log is weird
[20:51:46 CEST] <JEEB> it makes firefox hide it and then show it again a bit later
[20:52:06 CEST] <JEEB> also I saw the word NAL pop up which is not something I'd expect with something that isn't H.264/H.265
[20:52:19 CEST] <JEEB> and MBAFF
[20:52:44 CEST] <electron_rotosco> is that in 4973? That's an H264 encode I think in that giant log
[20:53:08 CEST] <JEEB> yea
[20:58:48 CEST] <durandal_1707> http://0x0.st/sOsx.png
[20:59:50 CEST] <JEEB> cool
[20:59:59 CEST] <JEEB> that brings the QED to this thing then :)
[21:00:26 CEST] <JEEB> HD HQX is 10bit, RI HQX is 12/10bit
[21:01:18 CEST] <JEEB> thank you
[21:01:23 CEST] <electron_rotosco> Thanks!
[21:01:26 CEST] <BradleyS> nice
[21:02:25 CEST] <electron_rotosco> I guess to start out with the error could change to "12 bit is not currently supported in ffmpeg"
[21:02:40 CEST] <JEEB> I think there should be two errors
[21:02:45 CEST] <JEEB> one for not 10/12
[21:02:47 CEST] <electron_rotosco> yeah that would make sense
[21:02:52 CEST] <JEEB> and one for 12bit
[21:30:20 CEST] <cone-680> ffmpeg 03Carl Eugen Hoyos 07master:0576ef466d8a: lavc/aarch64/h264dsp_init_aarch64: Fix weight function prototypes.
[21:41:01 CEST] <jamrial> jkqxz: re cbs_av1, some streams may have no temporal delimiter obus (mp4, mkv), so the whole seen_frame_header logic as is wouldn't work with those
[21:41:52 CEST] <jamrial> libaom's decoder doesn't complain when they are missing, so i guess it internally assumes that new packet == new temporal unit, and handles it as if a TD obu was there
[22:50:36 CEST] <cone-680> ffmpeg 03Marton Balint 07master:85bfcc46d192: ffplay: add support for various YUV conversion modes
[22:50:37 CEST] <cone-680> ffmpeg 03Marton Balint 07master:5982078e8d56: avcodec/utils: report insane channel count errors
[22:50:38 CEST] <cone-680> ffmpeg 03Marton Balint 07master:3e0f3be2b027: avcodec/internal: increase FF_SANE_NB_CHANNELS to 256
[23:14:15 CEST] <cone-680> ffmpeg 03Marton Balint 07master:e5ff2c0c0618: avformat/mxfdec: only return stream indexes which have a corresponding track
[00:00:00 CEST] --- Sat Jul 14 2018