On Tue, 10 Apr 2012, Luca Barbato wrote:
On 10/04/12 16:45, Luca Barbato wrote:
On 10/04/12 16:17, Ronald S. Bultje wrote:
Hi,
On Tue, Apr 10, 2012 at 4:11 PM, Johan Andersson <[email protected]> wrote:
Hallå.
Cherry picked this fix from ffmpeg and it fixes bugreport 263
OK.
Not ok, how's possible we get a packet that isn't for any stream allocated?
lu
The faulty code seems to be
No, this is not faulty, it is actually correct and intentional. It might
be the thing that leads to this issue yes, but it is not faulty.
For chapter tracks and for RTP hint tracks, we add MOVTracks for these
"generated tracks", that doesn't have any associated public AVStream. This
has worked for ages, it just happened that my commit broke it.
mov->nb_streams = s->nb_streams;
if (mov->mode & (MODE_MOV|MODE_IPOD) && s->nb_chapters)
mov->chapter_track = mov->nb_streams++;
since then we pass
if (mov->chapter_track)
mov_create_chapter_track(s, mov->chapter_track);
and it result to
static void mov_create_chapter_track(AVFormatContext *s, int tracknum)
{
MOVMuxContext *mov = s->priv_data;
MOVTrack *track = &mov->tracks[tracknum];
AVPacket pkt = { .stream_index = tracknum, .flags = AV_PKT_FLAG_KEY };
And eventually leads to
if (trk->entry)
frag_duration = av_rescale_q(pkt->dts - trk->cluster[0].dts,
s->streams[pkt->stream_index]->time_base,
AV_TIME_BASE_Q);
Looks like we are trying to do too much in mov_write_packet_internal ...
Sure, this perhaps could be changed to be done only for packets passed
from the user and not for packets generated within the mov muxer itself.
But until then, I'd like to apply the patch, which is a fully acceptable
fix to me.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
