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

[Michael Niedermayer]

On Sun, Jan 19, 2014 at 12:04:26PM +0100, Nicolas George wrote:
> Le decadi 30 nivôse, an CCXXII, Michael Niedermayer a écrit :
> > Do you know of such applications (i mean one actually existing not a
> > hypothetical one) ?
> 
> As far as I know, lavd's output devices are not widely used, if at all, and
> are mostly considered useless toys, unlike actual output formats and input
> devices. I would like to change that (and apparently Lukasz too).
> 
> But for now I have no real world example to provide; I can at least quote my
> own simple music player, whose inner playback loop looks like
> "av_read_frame(in_file); avcodec_decode_audio4();
> manually_pack_pcm_into_packet(); av_write_frame(alsa);".
> 
> > I can understand you and i agree but somehow your actual patch to
> > ffmpeg.c is doing exactly what you are trying to avoid.
> > if ffmpeg would need this hackery then its sort of in the public API
> > even if not litterally so, the need for the hackery is in case of
> > ffmpeg like applications.
> > and ffmpeg like would be any file transcoding tool here.
> > not ffmpeg like would be a player using libavformat for displaying
> > decoded frames.
> 
> That is exactly the issue: lavd's output devices are not really useful in a
> transcoding application, they would be meant for players.
> 
> ffmpeg.c should not be using this API at all, except for the principle that
> all library features should be covered inside ffmpeg.c. If you prefer it
> that way, I can drop this patch and replace it by an example simple
> audio-video player using xv and alsa (or uncodedframecrc).
> 
> > 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)


> 
> > I mean why isnt a simple if() / else around
> > av_interleaved_write_frame() enough ?
> 
> Actually, this is mostly what it is. The extra code is meant to prevent
> ffmpeg.c doing with the fake packet the same things it does with a real
> packet (copying, freeing, etc.), and that would be necessary anyways.
> 
> > also if pkt.size is set like this then the output statistics will
> > be wrong unless i miss something (didnt test)
> 
> I will need to check on the next iteration.
> 
> Regards,
> 
> -- 
>   Nicolas George



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20140119/d5f2b01d/attachment.asc>