[FFmpeg-devel] [PATCH 1/1] This change adds an encoder for Camera metadata motion. This is a type of sensor data associated with video, such as GPS, acceleration, gyro, and camera orientation. It does not encode video itself, but rather, this metadata.

[Louis O'Bryan]

It sounds like my code should be outside an encoder then. I think this
stems from my misunderstanding of how the API can be used. I will rewrite
my code that muxes streams to use an AVPacket directly instead.

On Fri, Jul 7, 2017 at 3:47 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:

> On Sat, Jul 8, 2017 at 12:24 AM, Louis O'Bryan
> <louiso-at-google.com at ffmpeg.org> wrote:
> >
> > The use case is to write data to a new stream in the mp4 container. The
> > encoder isn't changing the data. This data would reside in the same mp4
> > container as video and audio streams. Are you suggesting there is a way I
> > can accomplish that task without creating this encoder (and if so, how)?
>
> You don't need an encoder to create AVPackets, you can just do that
> yourself, even more so if the encoder apparently doesn't do any
> encoding.
> So why does it need encoding in the first place? Why can't you just
> pass the finished data in an AVPacket to the mov muxer? Thats how data
> streams are supposed to work.
>
> >
> >> +static av_cold int encode_init(AVCodecContext *avctx) {
> >> > +    // Use dummy values for the height and width.
> >> > +    avctx->width = DUMMY_ENCODER_SIZE;
> >> > +    avctx->height = DUMMY_ENCODER_SIZE;
> >> > +    avctx->max_pixels = DUMMY_ENCODER_SIZE;
> >> What? This makes no sense.
> >
> > Using avcodec_encode_video2() seems to require that the width and height
> be
> > nonzero. What is the recommended way to avoid that?
> >
>
> Clearly you should not use a video encoder to encode something thats
> not a video. This entire approach is not acceptable.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>