[FFmpeg-devel] reordered_opaque
Is it possible for AVCodecContext 's reordered_opaque to be exactly the same for 3 or 4 consecutive frames when packet's pts is fed in it ? Is it because of B frames? I am seeing this, in this case how does one re-orders the pics to render? Ratin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Fwd: Questionable libav code
On Tue, Feb 2, 2016 at 11:41 PM, wm4 <nfx...@googlemail.com> wrote:
> On Tue, 2 Feb 2016 14:31:20 -0800
> Ratin <rat...@gmail.com> wrote:
>
> > libavcodec has codes like this one (utils.c):
> >
> > static AVPacket *add_to_pktbuf(AVPacketList **packet_buffer, AVPacket
> *pkt,
> >AVPacketList **plast_pktl)
> > {
> > AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
> > if (!pktl)
> > return NULL;
> >
> > if (*packet_buffer)
> > (*plast_pktl)->next = pktl;
> > else
> > *packet_buffer = pktl;
> >
> > /* Add the packet in the buffered packet list. */
> > *plast_pktl = pktl;
> > pktl->pkt = *pkt; <===
> > return >pkt;
> > }
> >
> > Here a struct variable is meant to be copied over via assignment, is that
> > 100% correct to always work the way was intended? Given that the struct
> > pkt is a big struct which has raw bytes that are malloc'd. I was always
> > trained to avoid such struct assignment operations. What do people think?
>
> There is no problem at all here.
>
Sorry a bit confused, what happens when second argument is not malloc'ed,
somebody uses
AVPacket pkt;
add_to_pktbuf(packet_list, , plastpkt)
___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Fwd: Questionable libav code
libavcodec has codes like this one (utils.c):
static AVPacket *add_to_pktbuf(AVPacketList **packet_buffer, AVPacket *pkt,
AVPacketList **plast_pktl)
{
AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
if (!pktl)
return NULL;
if (*packet_buffer)
(*plast_pktl)->next = pktl;
else
*packet_buffer = pktl;
/* Add the packet in the buffered packet list. */
*plast_pktl = pktl;
pktl->pkt = *pkt; <===
return >pkt;
}
Here a struct variable is meant to be copied over via assignment, is that
100% correct to always work the way was intended? Given that the struct
pkt is a big struct which has raw bytes that are malloc'd. I was always
trained to avoid such struct assignment operations. What do people think?
Ratin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] goto statements and multi-threaded app
While searching for goto across whole ffmpeg codebase resulted in 3253 instances (with goto statement) were found. How reliable is goto statements when it comes to multi-threaded apps? I was under the impression its pretty risky to use. Thanks, Ratin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
