Hi Marton, > I still think ffmpeg.c should be fixed instead. There is even some logic in > ffmpeg.c to wait for a frame from all streams before writing the header, so > it seems doable.
I don’t disagree with this in principle, but we have to be a bit careful. There are stream types that generate packets on a very infrequent basis, and I’ve already had to add hacks to libavformat/mux.c to ignore certain codec types rather than waiting until avctx->max_interleave_delta gets hit. For example, I had cases where the decklink output would stall for several seconds whenever a SCTE-35 trigger was encountered. > Also as far as I see you cannot detect the field order in the muxer if it is > using a real codec (like v210) instead of a wrapped avframe. I had the same suspicion but haven’t confirmed it yet in this case. When I first ran into the problem I thought it might have been because of the v210 encoder not passing through the data that would have normally been in the AVFrame. However as soon as I saw the problem occurred with uyvy422 I stopped looking. This is a more general problem we have in other cases as well, such as relying on the codec parameters for frame width/height because we lost access to that information when it was converted from an AVFrame. The same goes for side data where we had to add code to the v210enc module to ensure it survived conversion from an AVFrame to an AVPacket. I know it’s been argued about in the past, but I really do think things like V210 should be a raw frame colorspace rather than a codec. Then we would be able to use a wrapped avframe for everything and wouldn’t lose all that data when translating from an AVFrame to an AVPacket. Devin --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
