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

[Clément Bœsch]

On Mon, Dec 03, 2012 at 11:54:14PM +0100, Reimar Döffinger wrote:
> 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...

So there is one case where the issue is hidden (playable with ffmpeg but
not the rest of the world), and another one pointing out there is an issue
(the muxer not honoring the side data as it should do). If there is
something to fix, then it should be done in the muxer, where we should
make use of these side data when necessary, or ignore them when
appropriate, I don't know.

Also note that currently some files are messed up especially because these
(non-mandatory in some cases) side data are not back to their place the
AVPacket and get muxed along with the payload.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121204/d42eec79/attachment.asc>