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

[burek]

[00:00:49 CEST] <Lynne> is there any way to completely disable v4l2_m2m?
[00:01:04 CEST] <Lynne> its always enabled, even with --disable-everything --disable-autodetect
[00:01:57 CEST] <JEEB> welcome to that list of stuff that always gets probed&enabled
[00:02:25 CEST] <JEEB> I wonder if it was alsa or something similar that I had to disable by commenting out the check in configure
[00:02:47 CEST] <JEEB> something something "system libraries"
[00:03:13 CEST] <JEEB> in theory "disable-xxxx" should work, but I didn't have that work too well as I think the things on that one list get auto-enabled
[00:03:24 CEST] <JEEB> (or I failed at using the correct command)
[00:04:50 CEST] <Lynne> nope, adding --disable-hwaccel --disable-v4l2-m2m doesn't work.
[05:56:02 CEST] <soreau> In case anyone is interested, I filed https://bugs.freedesktop.org/show_bug.cgi?id=111235 (gallium_drv_video.so report support for packed headers)
[06:23:24 CEST] <soreau> jkqxz: do you think I should submit the patch to mesa-devel list with a link to the bug report as well?
[09:47:11 CEST] <durandal_1707> vel0city: i see no point in working for speed, when it should first work correctly
[09:59:39 CEST] <vel0city> @durandal_1707: ok, agreed
[13:46:50 CEST] <durandal_1707> Lynne: where we will store rnn models?
[14:00:14 CEST] <Lynne> durandal_1707: dunno, a separate repo somewhere sounds good
[14:01:48 CEST] <Lynne> we could always upload them on aws and stream them via some restful api over http
[16:14:46 CEST] <Lynne> durandal_1707: where do you plan to use the double fft?
[16:16:57 CEST] <durandal_1707> Lynne: in libavfilter/af_afir.c
[18:16:23 CEST] <jkqxz> soreau:  No, because packed headers aren't supported by that driver.  Making it say that they are just moves the problem to a different place and makes it weirder.
[18:17:13 CEST] <soreau> jkqxz: So it's producing a 'bad' mkv but it just happens to work because video players are lenient?
[18:17:15 CEST] <jkqxz> With that change, lavc will include headers in the extradata and pass them to the driver, but the driver will ignore them and generate something completely different.  You'll end up making even more broken files, where the header data doesn't match the stream at all.  (But which will still work with some decoders because of the inline headers, though in fewer cases than no headers because seeking will 
[18:17:21 CEST] <jkqxz> break too.)
[18:18:06 CEST] <soreau> jkqxz: so what's the problem with just implementing proper packed header support in the driver?
[18:19:45 CEST] <jkqxz> Nothing, that's exactly the right solution.
[18:19:56 CEST] <soreau> I don't even know what this means. Does the gpu have to do work to produce the headers or can it be a static header reused with things that need to be changed, changed?
[18:20:37 CEST] <soreau> how do you even know where to start on something like this
[18:21:24 CEST] <soreau> I'd love to do it, I just don't know how or what to do
[18:21:43 CEST] <soreau> presumably the intel vaapi driver implements packed headers?
[18:22:00 CEST] <jkqxz> Yes.
[18:22:26 CEST] <soreau> so maybe I could peek in there to fill in some blanks
[18:22:47 CEST] <JEEB> I know we support multiple parameter set things in mp4 out of band nowadays, but do we have an interface/callback for the things to call when they want to pass new parameter sets to us?
[18:22:52 CEST] <durandal_1707> how to setup irc logger bot for ffmpeg channels? the current one is clearly dead.
[18:22:54 CEST] <JEEB> as in, in encoders
[18:23:02 CEST] <jkqxz> I'm not sure it's even possible on Polaris with publicly available information, though.  Raven Ridge+ (VCN targets) do look like they can do it, and it's vaguely on my todo list to look at at some point.
[18:23:15 CEST] <soreau> jkqxz: you mean packed headers?
[18:23:59 CEST] <jkqxz> Yes.
[18:27:19 CEST] <soreau> jkqxz: What does the gpu have to do? Can't it just have a function to produce headers using plain cpu/software?
[18:29:17 CEST] <JEEB> if you can receive the paramter sets etc from the hw encoder
[18:29:40 CEST] <JEEB> if the API is in-band you can also embed a parser and extract the parameter sets etc :P
[18:29:47 CEST] <JEEB> and pass them out as out of band things
[18:30:07 CEST] <JEEB> the problem of course is then that you have to keep checking if it duplicates them on each GOP
[18:30:13 CEST] <jkqxz> You don't want the hardware to have anything to do with generating headers, you just want it to insert the headers provided by the caller.  The AMD stuff has weird proprietary blobs running on a separate processor inside their hardware which messes with some of this in an unhelpful way, though.
[18:30:25 CEST] <JEEB> or if you got a new set of parameter sets
[18:33:51 CEST] <soreau> jkqxz: Why can't the caller just insert them? :P
[18:36:38 CEST] <soreau> jkqxz: isn't it just like the first frame? or not always true
[19:27:42 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:c2a91645c5b5: mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description
[19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:b71a0367a6e7: cbs: Remove useless initializations
[19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:d9182f04caa5: cbs_mpeg2: Fix parsing of picture and slice headers
[19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:43a188847cce: av1/h264_metadata: Don't reinitialize data
[19:30:39 CEST] <soreau> How can I check a video file to see if it has proper packed headers?
[19:32:32 CEST] <thardin> what kind of file?
[19:32:45 CEST] <soreau> mkv or mp4?
[19:33:09 CEST] <soreau> or any kind
[19:57:31 CEST] <jkqxz> Look at trace_headers and make sure extradata and anything inline matches.
[20:06:23 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:abb2e9ac3cb9: vp9_metadata: Improve spec-compliance and warnings
[20:06:53 CEST] <soreau> jkqxz: So run `ffmpeg -i input.mkv -c:v copy -bsf:v trace_headers`? I don't see anything that says extradata or inline
[20:08:53 CEST] <jkqxz> Then your file probably has no headers.  (Try with a file made with something else for comparison.)
[20:10:13 CEST] <soreau> does metadata == extradata?
[20:10:50 CEST] <jkqxz> No.  You'll get a line explicitly saying "Extradata" in the trace_headers output.
[20:11:17 CEST] <soreau> Do I actually need to specify an output file?
[20:12:44 CEST] <soreau> I get "Trailing options were found on the commandline."
[20:13:06 CEST] <soreau> maybe it's not using trace_headers I am passing
[20:17:57 CEST] <JEEB> ffmpeg -i FILE -map 0:v -bsf:v trace_headers -vframes 1 -f null -
[20:18:10 CEST] <JEEB> possibly redirect stderr into a file with 2> blah.log
[20:18:26 CEST] <JEEB> that should give you all the things that happen until the first frame is decoded
[20:18:49 CEST] <JEEB> also I probably forgot -c copy there :P
[20:21:43 CEST] <soreau> JEEB: thanks, is there no way to just dump this to stdout/err?
[20:22:21 CEST] <soreau> oh right, eliminate the redirect
[20:27:45 CEST] <soreau> Some files show "4 bytes left at end of AVCC header." but most that I've created with ffmpeg show nothing at all
[20:29:14 CEST] <jkqxz> The lines after "Extradata" but before any "Packet:" lines are the extradata.
[20:30:07 CEST] <soreau> and what's the inline stuff?
[20:31:34 CEST] <JEEB> inline stuff comes in packets
[20:31:48 CEST] <JEEB> extradata is what's in the extradata field that is the out-of-band initialization data
[20:32:24 CEST] <soreau> How do I view inline stuff?
[20:32:51 CEST] <JEEB> it should be there
[20:33:30 CEST] <soreau> I don't see anything that says inline
[20:33:38 CEST] <JEEB> no
[20:33:40 CEST] <soreau> where are you talking about?
[20:33:55 CEST] <JEEB> in-band (data in packets) and out-of-band (extradata)
[20:34:11 CEST] <soreau> I'm askig how to view the inline data
[20:34:39 CEST] <soreau> I'm kinda surprised there isn't some programmatic way to verify headers are valid
[20:35:00 CEST] <soreau> Is there a video player that is known to reject invalid headers or anything?
[20:35:24 CEST] <JEEB> within lavc there's the parsing functionality utilized by trace_headers
[20:36:07 CEST] <JEEB> soreau: you can view it just the same way as the extradata stuff
[20:36:28 CEST] <soreau> JEEB: I don't see anything that says inline though
[20:36:32 CEST] <JEEB> of course not
[20:36:40 CEST] <JEEB> "inline" is not a word we use within the FFmpeg framework
[20:36:46 CEST] <JEEB> nor is in-band or out-of-band
[20:36:56 CEST] <JEEB> it's just words to mean if the data is in the (av)packets or the extradata
[20:37:00 CEST] <soreau> ok so how do I view the inline data?
[20:37:12 CEST] <JEEB> jsut let me post a quote of a dump I just did with trace_headers
[20:39:15 CEST] <JEEB> soreau: http://up-cat.net/p/c2b91d58
[20:39:30 CEST] <JEEB> the first part is what's in extradata which is where stuff from f.ex. mp4's AVCc is put
[20:39:46 CEST] <JEEB> then you have stuff that comes out of packets, that's in-band.
[20:39:51 CEST] <JEEB> like the SEI that comes out first there
[20:40:11 CEST] <JEEB> parameter sets in packets = "headers" in-band
[20:40:26 CEST] <JEEB> I hope this makes the output of trace_headers a bit more understandable :P
[20:40:58 CEST] <JEEB> so in here we have SPS and PPS in extradata (out-of-band, from the container header like AVCc)
[20:41:07 CEST] <JEEB> and then SEI and a slice header from in-band
[20:44:02 CEST] <JEEB> now if I use this same thing with an MPEG-TS file I will most likely get the SPS/PPS within a packet
[20:44:17 CEST] <JEEB> as MPEG-TS has decoder initialization data within the strema
[20:44:19 CEST] <JEEB> *strea,
[20:44:22 CEST] <JEEB> *stream
[20:44:57 CEST] <soreau> JEEB: Look for parameter sets (SPS, PPS, VPS) for in-band "headers" <-- I don't see SPS, PPS, VPS anywhere but this line
[20:45:17 CEST] <soreau> and also I see no wway to compare extradata with inline data
[20:45:45 CEST] <thardin> what do you actually want to do?
[20:45:54 CEST] <soreau> <jkqxz> Look at trace_headers and make sure extradata and anything inline matches. <-- is there a programmatic way to do this?
[20:46:14 CEST] <JEEB> if you don't have grep -i -B1 "parameter set" anywhere else than in extradata, then there are no in-band parameter sets :P
[20:46:32 CEST] <soreau> thardin: trying to find a reliable test to validate packed headers
[20:46:43 CEST] <JEEB> soreau: yes. feed the packets' data to the same functionality that the trace_headers stuff uses?
[20:46:54 CEST] <JEEB> if you really want to parse that
[20:47:09 CEST] <JEEB> otherwise you can just a binary check :P
[20:47:10 CEST] <JEEB> if they match
[20:47:36 CEST] <soreau> I mean if there's no video player that checks this, then what's the point? Why does it matter if the headers are ok or not?
[20:47:52 CEST] <thardin> what do you mean by packed headers?
[20:48:09 CEST] <thardin> if you want your videos to work in $PLAYER then you need to test in that player
[20:48:28 CEST] <thardin> there are validators for some formats
[20:48:36 CEST] <thardin> sometimes that's enough, but not always
[20:49:24 CEST] <JEEB> soreau: many software players just take whatever they take last so if your last set of parameter sets are correct they might "just work", accidentally :P still doesn't make any more sense to write incorrect parameter sets into the AVCc block of mp4
[20:49:42 CEST] <soreau> thardin: The problem is that for instance when trying to use vaapi with gallium state tracker, it doesn't have packed header support so it produces a video file that's apparently technically wrong but I'm trying to discover why these headers even matter
[20:50:08 CEST] <thardin> ah
[20:50:15 CEST] <soreau> thardin: and mkv checks but mp4 doesn't (though it might in the future) so vaapi wont work for mkv and mp4 containers as output
[20:50:33 CEST] <thardin> sounds like missing extradata
[20:51:24 CEST] <soreau> and I've found out that the driver caller has the header and the driver is supposed to add it but there are complications with missing hw specs apparently so I am trying to figure out if the caller can just add the headers afterward or something
[20:51:31 CEST] <JEEB> soreau: we've made FFmpeg based stuff way too resilient to broken crap, but that doesn't mean that you should create more code that creates even more spec-breaking or incorrect files vOv
[20:51:51 CEST] <cone-024> ffmpeg 03Shiyou Yin 07master:62e6b634a802: avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi.
[20:52:01 CEST] <soreau> JEEB: that's why I'm wanting to do something to fix it
[20:52:16 CEST] <JEEB> yup, and as you can see I've tried to help you :P
[20:52:33 CEST] <soreau> JEEB: so how would I do a binary check or whatever you were talking about?
[20:52:47 CEST] <JEEB> is there a memory compare thing?
[20:52:51 CEST] <JEEB> just check if the bytes are the same
[20:53:01 CEST] <soreau> I have no idea how to do this
[20:53:10 CEST] <thardin> there are tools that will pick apart an h.264 stream for you
[20:53:34 CEST] <soreau> thardin: But is there something that will just say headers are valid or not
[20:53:44 CEST] <thardin> uhm, that probably depends
[20:54:00 CEST] <JEEB> if you want an actual parser then the stuff used by trace_headers exists
[20:54:01 CEST] <JEEB> as I noted
[20:54:06 CEST] <JEEB> it will error out on incorrect data :P
[20:54:20 CEST] <soreau> JEEB: but you're not telling me how to do this
[20:54:28 CEST] <JEEB> of course not, I've barely looked at the API!
[20:54:31 CEST] <JEEB> I cannot know everything
[20:54:31 CEST] <soreau> I have no idea to do what you're talking about
[20:54:32 CEST] <JEEB> sorry
[20:54:41 CEST] <JEEB> see for cbs_
[20:54:43 CEST] <JEEB> in libavcodec/
[20:54:52 CEST] <JEEB> then you know as much as I do
[20:55:03 CEST] <JEEB> libavcodec/cbs.h
[20:55:14 CEST] <thardin> a friend of mine wrote his own goloumb decoder for dealing with h.264 stuff
[20:55:32 CEST] <thardin> maybe there's something similar around
[20:55:41 CEST] <thardin> or that trace_headers thing yes
[20:55:52 CEST] <JEEB> the CBS stuff is the closest we have for coded bit stream parsing as far as I can tell
[20:57:10 CEST] <JEEB> soreau: but if you do not want to get discouraged by hopping into this coding stuff, my recommendation as noted before would be to just compare the text output of trace_headers between different paramter sets etc
[20:57:26 CEST] <JEEB> if you like coding then you have CBS framework right there
[20:57:45 CEST] <JEEB> I have no idea how to use it, but the trace_headers and a few other bit stream filters are already using it
[21:04:11 CEST] <soreau> JEEB: coding isn't the problem, I just don't know why there isn't something like this if having invalid headers is a 'problem'
[21:04:41 CEST] <JEEB> very good question
[21:05:16 CEST] <JEEB> in some cases there's an explode mode
[21:05:16 CEST] <soreau> If something like this is in fact needed, there should be a dedicated program for it IMO
[21:05:38 CEST] <JEEB> I do agree
[21:05:42 CEST] <soreau> or a program that can be used for this purpose at least
[21:06:10 CEST] <soreau> I mean even if someone were to implement proper packed header support in the driver, how would you know if it's working or not?
[21:06:27 CEST] <JEEB> we have some checkers for isobmff and matroska I think, but that's for the container level in general. they don't take opinion on the actual data within in many ways
[21:06:31 CEST] <soreau> from what I can tell so far, there isn't a clear cut way
[21:06:53 CEST] <JEEB> soreau: don't output any parameter sets in packets and see if it plays
[21:07:37 CEST] <JEEB> of course FFmpeg itself sucks at this check because you can probably have Annex B in the extradata and the effing thing might still play through FFmpeg's parser&decoder :P
[21:09:41 CEST] <JEEB> there's seemingly a bit stream filter called extract_extradata which seems to have an option to remove parameter sets etc from streams when they are in-band
[21:09:57 CEST] <JEEB> I have never used it but it might be useful for testing
[21:10:09 CEST] <soreau> I mean if this extradata was comparable to the inline stuff I probably could write a script to parse stuff and compare but it's like these values don't even remotely match
[21:10:15 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#extract_005fextradata
[21:10:26 CEST] <soreau> between extradata and inline, the stuff isn;t comparable
[21:12:20 CEST] <JEEB> I don't 100% remember if extradata field contains the whole AVCc which is the mp4 structure, or just the parameter sets
[21:12:49 CEST] <JEEB> if it's the full AVCc structure then you will have to of course parse the actual parameter sets from that
[21:13:08 CEST] <JEEB> but as I noted, the trace_headers filter already does that
[21:13:18 CEST] <JEEB> for me it output the values of the parameter sets from the extradata nicely
[21:13:34 CEST] <JEEB> and then if I would have another set in the stream then that would pop up in there as well
[21:13:56 CEST] <JEEB> I am not sure if I have such an example on hand right now so I can't exactly give you a nice example :P
[21:14:09 CEST] <JEEB> if I do trace_headers on MPEG-TS I get stuff in-band only
[21:14:20 CEST] <soreau> JEEB: you're speaking greek to me. I need to know what I'm comparing because it isn't obvious
[21:15:09 CEST] <JEEB> well, sorry. clearly I suck at helping people
[21:17:27 CEST] <soreau> Extradata: Sequence Parameter Set, Picture Parameter Set;  Inline: Supplemental Enhancement Information, User Data Unregistered, Slice Header
[21:17:46 CEST] <soreau> jkqxz: what is supposed to match to what?
[21:18:33 CEST] <JEEB> the parameter sets are supposed to match to the actual stream (aka "the stream should be decode'able"
[21:18:50 CEST] <JEEB> somehow there was an understanding that you had something that generated files with parameter sets in-band
[21:18:59 CEST] <JEEB> so you would have packets that would contain paramter sets
[21:19:17 CEST] <JEEB> my example only had SEI in there in front because it properly had the paramter sets only in the extradata
[21:20:00 CEST] <JEEB> I would have given an example with parameter sets in both places if I had such
[21:21:40 CEST] <soreau> <JEEB> the parameter sets are supposed to match to the actual stream <-- So Sequence Parameter Set and Picture Parameter Set parameters should be compared to what? Supplemental Enhancement Information and Slice Header?
[21:21:58 CEST] <JEEB> did you read the last two messages I wrote?
[21:22:12 CEST] <JEEB> you would have the same kind of SPS/PPS within the stream (in packets)
[21:22:12 CEST] <soreau> JEEB: yes but I'm having trouble understanding
[21:22:25 CEST] <soreau> I don't know what SEI, SPS/PPA is
[21:22:35 CEST] <JEEB> SEI is Supplemental Enhancement Information
[21:22:47 CEST] <JEEB> PPS is Picture Parameter Set, SPS is Sequence Parameter Set
[21:23:08 CEST] <soreau> ok but how does that invalidate my question?
[21:23:35 CEST] <soreau> I'm trying to figure out what to compare against each other to know if it's a valid header
[21:23:40 CEST] <JEEB> it doesn't, I just noted that I had just said that if I had such an example that the earlier discussion looked like you were having, you would have the parameter sets in *both*
[21:24:05 CEST] <JEEB> if you only have parameter sets in extradata then that's of course great
[21:24:47 CEST] <JEEB> for H.264 it's the SPS and PPS that matter for decoder initialization; those have to be right
[21:24:54 CEST] <JEEB> for HEVC I think it is SPS, PPS and VPS
[21:25:05 CEST] <JEEB> all of those are _something_ parameter sets
[21:25:12 CEST] <soreau> but if I am to write some tool I need to know for sure
[21:25:19 CEST] <soreau> is there no real documentation about this?
[21:25:39 CEST] <JEEB> at this point I'm confused about what you are exactly confused about
[21:25:51 CEST] <JEEB> possibly as confused as you are towards WTF I've talking about
[21:25:55 CEST] <JEEB> *I'm
[21:26:10 CEST] <JEEB> also please let's have one thing verified first
[21:26:35 CEST] <JEEB> let's see if the problem to begin with was what I expected from how your discussion with jkqxz went
[21:27:13 CEST] <JEEB> `ffmpeg -i FILE -c copy -map 0:v -bsf:v trace_headers -vframes 1 -f null - 2> blah.log`
[21:27:23 CEST] <JEEB> do this on one of those files that was generated with the problematic encoder
[21:27:30 CEST] <JEEB> and that would fail now with matroska
[21:27:56 CEST] <JEEB> then paste the AVBSFContext parser stuff
[21:28:02 CEST] <JEEB> onto a pastebin.com or gist or something
[21:28:04 CEST] <JEEB> and link here
[21:28:23 CEST] <JEEB> or just paste the full log
[21:28:28 CEST] <JEEB> in pastebin/gist/whatever
[21:28:30 CEST] <JEEB> and link here
[21:29:17 CEST] <JEEB> I just want to verify what that supposed broken file looks like :P
[21:29:54 CEST] <soreau> JEEB: https://www.hastebin.com/raw/uzamojodem
[21:29:57 CEST] <JEEB> thank you
[21:30:30 CEST] <JEEB> ok, that one shows that you have parameter sets both in extradata and in the stream
[21:30:41 CEST] <soreau> JEEB: what does that mean?
[21:31:30 CEST] <JEEB> it means that the decoder initialization data is both in the stream and in the container structure for decoder initialization
[21:31:44 CEST] <JEEB> they look pretty similar
[21:31:55 CEST] <JEEB> if you look at the SPS and PPS values between the two
[21:34:25 CEST] <JEEB> or actually no, the one in extradata has a lot of various additional values; sps is much longer
[21:35:02 CEST] <soreau> yea that's another question I had, does it matter if one or the other has extra entries or do they have to perfectly match
[21:36:16 CEST] <jkqxz> They're not compatible.  Some of the fields affecting slice parsing are different, like log2_max_pic_order_cnt_lsb_minus4.
[21:36:22 CEST] <JEEB> right
[21:36:50 CEST] <soreau> jkqxz: how can I know all the criteria?
[21:37:20 CEST] <JEEB> I would expect the encoder to give you those parameters of its encode
[21:37:39 CEST] <jkqxz> And transform_8x8_mode_flag, which changes a lot of the macroblock layer.
[21:37:57 CEST] <jkqxz> soreau:  By reading the standard.
[21:38:10 CEST] <jkqxz> (As facetious as that sounds, there isn't really any better answer.)
[21:38:34 CEST] Action: soreau doesn't even know where the standard is
[21:38:44 CEST] <JEEB> https://www.itu.int/rec/T-REC-H.264/en
[21:39:14 CEST] <JEEB> latest one is pre-published so grab the 04/17 one
[21:39:24 CEST] <JEEB> https://www.itu.int/rec/T-REC-H.264-201704-S/en
[21:39:56 CEST] <JEEB> anyways, in the worst case you could just wait in the encoder until you have the first packet from the encoder and parse the parameter sets from there?
[21:40:09 CEST] <JEEB> and set extradata at that point?
[21:40:18 CEST] <JEEB> not sure how well that works with our framework, though
[21:40:49 CEST] <soreau> yea I want to know if the caller can write the header too
[21:41:09 CEST] <JEEB> you *can* but you'll have to generate it according to the spec with the parameters of the encoder
[21:41:27 CEST] <JEEB> and if the encoder anyways outputs parameter sets in-band then why not extract that?
[21:41:46 CEST] <soreau> according to jkqxz, the caller already has the header generated to pass to the driver
[21:41:57 CEST] <JEEB> ok, that's great then
[21:42:10 CEST] <soreau> but the gallium driver doesn't support writing it so I was just wondering if the caller can
[21:42:10 CEST] <JEEB> then why are the two parameter sets different? :D
[21:43:05 CEST] <JEEB> soreau: theoretically you can very much write headers by yourself but the problem is that you are supposed to match that with whatever the encoder itself is going to configure itself for :D
[21:43:33 CEST] <JEEB> and when you are guessing I can see stuff like what you have in your paste happening
[21:43:45 CEST] <JEEB> maybe I am just mis-understanding something of course
[21:43:46 CEST] <soreau> JEEB: well if it's the one passing the headers, I presume they should already be correct
[21:44:05 CEST] <JEEB> yes, I would presume the headers in the stream that came from the encoder apparently should be what the encoder wants to write
[21:44:12 CEST] <JEEB> I may be incorrect of course
[21:44:31 CEST] <JEEB> but that is why I noted the possibility of extracting the headers from the first packet of data that you get from the encoder
[21:45:40 CEST] <soreau> yea if the generated headers aren't correct that's another matter but it reportedly works with intel ok so I guess they're correct..
[21:45:48 CEST] <soreau> but without a header checking tool, who knows
[21:46:08 CEST] <JEEB> well the paste already contains all the values that you would be comparing/checking
[21:46:40 CEST] <JEEB> you would get an error from the decoder if at that point the values would be incorrect
[21:47:26 CEST] <soreau> JEEB: what would give an error?
[21:47:49 CEST] <JEEB> the decoder. if actual decoder initialization related values do not match what's in the actual coded pictures then you will get an error
[21:50:08 CEST] <soreau> JEEB: are you suggesting this could be a header checker?
[21:50:18 CEST] <JEEB> and now you've officially lost me
[00:00:00 CEST] --- Mon Jul 29 2019