[FFmpeg-devel] [PATCH 3/6] avcodec/h264_slice: export S12M timecode side data

[lance.lmwang at gmail.com]

On Wed, Jul 15, 2020 at 07:01:33PM +0200, Hendrik Leppkes wrote:
> On Wed, Jul 15, 2020 at 5:52 PM <lance.lmwang at gmail.com> wrote:
> >
> > On Wed, Jul 15, 2020 at 04:16:38PM +0100, Kieran Kunhya wrote:
> > > If you look a few lines above, we already set the timecode side data.
> > >
> >
> > are you saying av_frame_new_side_data() above?  that's total different, in fact,
> > I'm try to use the same way with ff_add_cpb_side_data(), it'll put TC in the codec
> > level: avctx->nb_coded_side_data instead of frame level. By this way, I can export
> > the correct TC in the following patch for movenc, dv file format. Please refer to:
> > libavformat/utils.c line 4154 add_coded_side_data() is used to copy all AVPacketSideData
> > side data to st level. If someone have better way to reuse the frame side
> > data, please give your advice.
> >
> 
> CBP is a stream-level property, it doesn't usually change.
> Timecodes are a per-frame property. There is no reason to store them
> globally in avctx.
> 
> There is a big difference between those two. TC should be a per-frame
> property, and if a muxer needs it, then the muxer should figure it out
> from packets, not from a global store.

The problem is most of muxer with TC support had used the timecode in stream-level, they're used
the first timecode for start always(so you can input the first timecode by
option also). So even I copy it to packet level, it doesn't used yet, that's why
I choose the global store.

For the TC need to sync with frame or packet strictly, so I think it's better
to add the the side copy(frame level to packet level) after encode_frame(), now
only v210enc need the packet level, so it'll copy in encode_frame().


> 
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang