On 12/14/2015 12:30 PM, Mats Peterson wrote:
On 12/14/2015 12:21 PM, Mats Peterson wrote:
On 12/14/2015 12:16 PM, Mats Peterson wrote:
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
The contents of the stsd atom IS ALREADY IN THE PRIVATE DATA.
Mats
And "how should we read it", well, exactly what I've been doing, by
using offsets into the private data to get at the various values.
Mats
I bet you haven't even looked at my patch yet, Carl. Do it, and you will
(hopefully) understand.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
