Am Sat, 30 May 2015 12:58:38 +0200 schrieb Hendrik Leppkes <h.lepp...@gmail.com>:
> On Sat, May 30, 2015 at 12:39 PM, Wolfgang Lorenz <wl-c...@gmx.de> wrote: > > Am Sat, 30 May 2015 11:00:18 +0200 > > schrieb Wolfgang Lorenz <wl-c...@gmx.de>: > > > > [...] > > > > Okay. Now I get the same errors Michael had, after the first version of > > the patch, but with the second version: > > > > Test aac-latm_000000001180bc60 failed. Look at > > tests/data/fate/aac-latm_000000001180bc60.err for details. > > make: *** [fate-aac-latm_000000001180bc60] Error 1 > > make: *** Waiting for unfinished jobs.... > > Test aac-latm_stereo_to_51 failed. Look at > > tests/data/fate/aac-latm_stereo_to_51.err for details. > > make: *** [fate-aac-latm_stereo_to_51] Error 1 Okay, that was due to some old library versions, that were still lingering in my LD_LIBRARY_PATH. Now, also acodec-s302m fails. > You should check out the .err files it mentions and actually see what > its complaining about. That didn't help much. There doesn't seem to be much information available, but as I understand it s302m is some kind of codec defined by SMPTE, that writes PCM data into a private stream of an MPEG-TS. Without the patch the stream is identified as an AVMEDIA_UNKNOWN and AV_CODEC_NONE by mpegts.c. Later the missing codec leads to probing the stream for a codec id. The type is set to AVMEDIA_AUDIO and the codec id is set accordingly. All is well. With the patch the stream is identified as AVMEDIA_DATA and AV_CODEC_ID_BIN_DATA. In this case ffmpeg doesn't find any audio data to transcode and the fate test fails. This may be too bold, but I think the acodec-s302m test is broken. I think, that trying to decode private data is a bad idea. There's no way to see whether the chosen coder is the correct one. In my case FFMPEG thought AAC might be a good choice to decode random data. I'm not sure, what can be done about this, though. Just applying the patch, since the standard says so, might break other people's code. Maybe it is possible to implement a function, that changes the codec of a stream after probing for one that works. This could then be used by someone who knows what to expect in a private stream. Also, this would break other people's code. A third idea is to add a flag to each stream, that states whether FFPEG should still probe the stream, even if it is defined as a data stream. If this flag is set to true by default, this would not break other people's code. I've been trying to implement something like this for the last couple of hours, but it just doesn't work. :-( Well, I just don't know the internals of FFMPEG well enough. I guess the best I can do now, is to open a bug report describing my problem. What do you think? Greetings, Wolfgang _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
