On Tue, Jul 25, 2017 at 00:25:36 +0530, Gyan wrote: > Running your conversion command on your source, I see > > Input stream #0:0 (video): 856 packets read (18695093 bytes); 104 frames > decoded; > > Muxing to TS and playing that throws invalid NAL warnings.
But that was a conversion, right? > mp4box -aviraw video hd.avi > > which produced hd_video.h264. This plays fine with ffplay. That was remuxing, right? > As best as I can tell, ffmpeg does have issues with parsing non-standard > H.264 bitstreams. It's certainly not as resilient as other decoders. I did a different test: - Playing the original video with ffplay produces the peculiar image Ute is probably seeing. - Playing with mplayer produces an acceptable image. (mplayer uses ffmpeg's libavcodec for decoding the video..) - Playing with "mplayer -demuxer lavf" produces the same junk as ffplay. So I come to the conclusion that ffmpeg/libavformat has an issue demuxing the file. mplayer's native AVI demuxer doesn't. The latter is also probably valid for VLC, if that works for Ute. mp4box also doesn't have an issue. So, I think this is worth tracking as an ffmpeg bug (on trac.ffmpeg.org), providing the sample as an attachment, the command line and the complete, uncut console output. My $0.02, Moritz _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
