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. Also the S302 in fate is identified by a registration descriptor there should be nothing unreliable in its detection [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
