Am Thu, 4 Jun 2015 03:18:20 +0200 schrieb Michael Niedermayer <michae...@gmx.at>:
> On Sun, May 31, 2015 at 06:35:18PM +0200, Wolfgang Lorenz wrote: > > 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? > > Do i understand correctly that you put data in a mpegts file and > you leave absolutely no way to identify this data except that its > a private stream ? > > I think its a very bad idea not to add some reliable method to > identify your data. You are right, there. Ich should at least add some magic number to each packet, and I will. This wouldn't solve my original problem though. > Also the S302 in fate is identified by a registration descriptor > there should be nothing unreliable in its detection > > > [...]
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel