<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 20, 2017 at 2:33 PM, Carl Eugen Hoyos <span dir="ltr"><<a href="mailto:ceffmpeg@gmail.com" target="_blank">ceffmpeg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2017-11-20 23:12 GMT+01:00 Tyler Brooks <<a href="mailto:tylerjbrooks@gmail.com" target="_blank">tylerjbrooks@gmail.com</a>>:<br>
<br>
> My encoder gives me a timestamp on every frame (int64_t in microseconds).<br>
> The hardware is pretty good and the timestamps are very nearly always<br>
> separated to 1/framerate.  In my case the framerate is 30fps so the frames<br>
> come out of the encoder about every 30ms (lets just say for easy math for<br>
> now).<br>
><br>
> Of course, I could use those timestamps for my pts/dts.  Indeed, I have<br>
> tried.<br>
><br>
> But here is the root of my problem.  The key frames are handed to me as four<br>
> NAL packets (SPS, PPS, SEI, key_frame) all at the same time and all with the<br>
> same timestamp.  That makes sense.  The metadata meant for the decoder (SPS,<br>
> PPS and SEI) should to be associated with the leading key_frame and they<br>
> should all share the same timestamp.  My problem is I don't know how to make<br>
> a multi-packet 'AVPacket' to submit as a single frame to the<br>
> 'av_write_frame' call.<br>
<br>
</span>Did you try to concatenate SPS, PPS and SEI with<br>
the first key-frame?<br><br></blockquote></div>Carl...</div><div class="gmail_extra">I tried concatenating the meta data with the key frame but no joy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, a friend pointed out to me that I might be going at this the wrong way.  The basic problem I am having is that I don't have an input context so there is no h264 parser that can take the SPS, PPS and SEI packets and do anything with them.  I suspect that my loop appears to be working because I am writing to an 'mpegts' file which, I think, is just h264 packets with the leading NAL zeroes replace with length words (some bit-stream filter must be doing that).  But that would mean that there isn't much chance that I can get the timestamps right because I have to submit them as frames. I can't submit them as 'extradata/sidedata' because there is no codec to catch them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Apparently I am supposed to write a custom IO context for the output of my encoder and then do a normal input context.  I have done some experiments with this approach and it seems to work.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you for your help Carl.</div></div>