[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