[FFmpeg-devel] [PATCH 2/5] ffmpeg: use the write_uncoded_frame() API.

Michael Niedermayer michaelni at gmx.at
Sat Jan 25 15:28:02 CET 2014


On Sat, Jan 25, 2014 at 02:47:38PM +0100, Lukasz Marek wrote:
> On 25.01.2014 04:12, Michael Niedermayer wrote:
> >On Sun, Jan 19, 2014 at 03:29:15PM -0200, Ramiro Polla wrote:
> >>On Sun, Jan 19, 2014 at 12:31 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>>On Sun, Jan 19, 2014 at 12:04:26PM +0100, Nicolas George wrote:
> >>>>Le decadi 30 nivôse, an CCXXII, Michael Niedermayer a écrit :
> >>>>>why do you need all this special casing and complexity compared to
> >>>>>ramiros patch ?
> >>>>
> >>>>Two reasons: Ramiro's patch only handles video, while this patch handles
> >>>>audio too; in Ramiro's patch, the RAW_FRAME code path skips the timestamps
> >>>>rescaling and such.
> >>>
> >>>i was thinking of having the existing unchanged encoder generate
> >>>AVPackets and all the timestamp rescaling done to them and then
> >>>close to where the call to av_interleaved_write_frame() is
> >>>take the timestamps from the AVPacket, put them in a AVFrame
> >>>and pass that to the uncoded frame API
> >>>i may very well be missing something but that would avoid having to
> >>>build these fake AVPackets and would put the code in fewer seperate
> >>>places
> >>>There would be a useless memcpy in the encoder (but if the code is
> >>>only intended for test coverage then this should not matter much
> >>>and could be fixed by setting a flag telling the encoder not to do it)
> >>
> >>This patch started off as a way to remove an extra memcpy. In my
> >>example (decklink at 1080p) it amounted to ~10% of the total time.
> >
> >in that case something should be done to avoid the memcpy
> 
> I haven't follow this discussion deeply, but is it blocking to merge
> first patch from the set: [PATCH 1/5] lavf: add
> write_uncoded_frame() API.?

no, just needs nicolas/the author to ask for it to be merged

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140125/2b87faf6/attachment.asc>


More information about the ffmpeg-devel mailing list