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

[Nicolas George]

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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140119/8685412b/attachment.asc>