On 12/14/2015 12:15 PM, Carl Eugen Hoyos wrote:
On Monday 14 December 2015 12:10:48 pm Hendrik Leppkes wrote:
On Mon, Dec 14, 2015 at 12:03 PM, Carl Eugen Hoyos wrote:
On Monday 14 December 2015 09:37:22 am Hendrik Leppkes wrote:
On Mon, Dec 14, 2015 at 3:40 AM, Carl Eugen Hoyos wrote:
Hi!
Attached patch based on 3ece3e4c by Martin Storsjö fixes
ticket #5071 for me. I can't see how duplicating the code
from mov.c could be acceptable.
Personally I found toying with st->priv_data to make it look
like being in the MOV demuxer not acceptable.
Given that ff_mov_read_stsd_entries() is already used outside
of the mov demuxer and we generally avoid code duplication and
the (very short) specification of the structure only mentions
it is identical to stsd, I consider my patch the more
acceptable solution.
It has the potential for unpredicatble side-effects in the
long run.
If this potential exists, it also exists without this patch.
Just because its already used elsewhere doesn't make it a good
idea.
So how should we read the stsd atom from non-mov input?
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Are you ignoring me completely? Not that I'm surprised. I already
explained what I've been doing in my patch. Read it.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
