[FFmpeg-devel] [PATCH] lavf: split packets before muxing.

Reimar Döffinger Reimar.Doeffinger at gmx.de
Mon Dec 3 23:54:14 CET 2012


On 3 Dec 2012, at 23:36, Clément Bœsch <ubitux at gmail.com> wrote:
> On Mon, Dec 03, 2012 at 11:26:32PM +0100, Reimar Döffinger wrote:
>> On Mon, Dec 03, 2012 at 11:15:40PM +0100, Clément Bœsch wrote:
>>> After demuxing, data and side are merged. Before decoding, they are
>>> split. Encoder will perform with data and side split. This means that a
>>> muxer can receive split data (after encoding) but also merged data (if
>>> called directly after demuxing). This commit makes sure data and side
>>> are split for the muxer.
>>> ---
>>> libavformat/mux.c | 14 ++++++++++----
>>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/libavformat/mux.c b/libavformat/mux.c
>>> index 9bcee99..ce7a067 100644
>>> --- a/libavformat/mux.c
>>> +++ b/libavformat/mux.c
>>> @@ -484,13 +484,19 @@ static int compute_pkt_fields2(AVFormatContext *s, AVStream *st, AVPacket *pkt)
>>>     return 0;
>>> }
>>> 
>>> +static inline int split_write_packet(AVFormatContext *s, AVPacket *pkt)
>>> +{
>>> +    av_packet_split_side_data(pkt);
>>> +    return s->oformat->write_packet(s, pkt);
>>> +}
>> 
>> And if the muxer can't handle side data it will get lost.
> 
> In what situation do you need to actually mux these side data?

Try remuxing one of the codecs using AVI palette into some other container.
FLV demuxer I think stores even resolution change info in side data.

>> IMHO to do this properly you need to know what side data the
>> muxer supports, and those that are supported (or make no sense)
>> should be split and the rest should not.
> 
> That will require quite some changes… IMO the situation where some files
> are badly muxed (any muxer receiving merged side data will write
> data+magic+side_data in the payload, which will likely produce bad files;
> no muxer at the moment split the packet to extract the side data because
> the AVPacket is considered RO afaik) is worse than skipping the
> information…

Well, I maybe agree, but you can argue that. The current code maybe produce broken files, but at least FFmpeg should be able to play them fine. After splitting them there's a risk that you're silently discarding critical data and there's no way to ever play those files...


More information about the ffmpeg-devel mailing list