On Thu, Apr 21, 2011 at 3:34 PM, Mike Scheutzow <[email protected]> wrote: > > Tony Strauss wrote: >>> >>> You can reproduce by running: >>> ffprobe -loglevel debug -show_packets 720.no_b_frames.ts > > This .ts file does not look valid to me. I find no start codes in the video > elementary stream. As far as I know, H264 should be using Annex-B format > within a transport stream.
Hmm. I don't have the command-line that I used to produce that file anymore. Perhaps I uploaded the wrong file. Just to clear up any doubts, I've uploaded some new .ts files, and I've provided the ffmpeg command-lines that I used to create them from an .mp4 below: The original mp4: https://s3.amazonaws.com/tony-strauss-public/clip.mp4 A .ts file encoded with b-frames: https://s3.amazonaws.com/tony-strauss-public/clip.bframes.ts ffmpeg -y -t 5 -i clip.mp4 -an -vcodec libx264 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -crf 18 -coder 1 -flags +loop -cmp chroma -g 48 -keyint_min 15 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -i_qfactor 0.71 -partitions parti8x8+parti4x4+partp8x8+partb8x8 -trellis 1 -bf 1 -flags2 +wpred+mixed_refs-dct8x8-bpyramid -me_method umh -me_range 16 -subq 7 -refs 1 -threads 0 -f mpegts clip.bframes.ts A .ts file encoded without b-frames: https://s3.amazonaws.com/tony-strauss-public/clip.no_bframes.ts ffmpeg -y -t 5 -i clip.mp4 -an -vcodec libx264 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -crf 18 -coder 1 -flags +loop -cmp chroma -g 48 -keyint_min 15 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -i_qfactor 0.71 -partitions parti8x8+parti4x4+partp8x8+partb8x8 -trellis 1 -bf 0 -flags2 +wpred+mixed_refs-dct8x8-bpyramid -me_method umh -me_range 16 -subq 7 -refs 1 -threads 0 -f mpegts clip.no_bframes.ts The only difference between these two command-lines is the -bf (1 for b frames, 0 for no b frames). I believe that ffmpeg automatically takes care of the annex-b repackaging during a re-encode. Certainly, when I explicitly added the filter on the command-line, the output file checksum didn't change: https://s3.amazonaws.com/tony-strauss-public/clip.no_bframes_and_filter.ts ffmpeg -y -t 5 -i clip.mp4 -vbsf h264_mp4toannexb -an -vcodec libx264 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -crf 18 -coder 1 -flags +loop -cmp chroma -g 48 -keyint_min 15 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -i_qfactor 0.71 -partitions parti8x8+parti4x4+partp8x8+partb8x8 -trellis 1 -bf 0 -flags2 +wpred+mixed_refs-dct8x8-bpyramid -me_method umh -me_range 16 -subq 7 -refs 1 -threads 0 -f mpegts clip.no_bframes2.ts blackberry:~/sandbox tony$ sum clip.no_bframes.ts 41807 608 clip.no_bframes.ts blackberry:~/sandbox tony$ sum clip.no_bframes2.ts 41807 608 clip.no_bframes2.ts > >>> The >>> key thing is that this file was encoded without b frames, so pts == >>> dts for every frame. > > It requires more than "no B frames" for this statement to be true. > > Does the video contain P-frames? If it contains P-frames, then pts != dts. > Please post a link to a valid file so we can see. Interesting. I really don't know much about video encoding, but this surprises me. Certainly a patched ffprobe shows pts == dts for clip.no_bframes.ts (and this does have p frames, since refs=1). Why would the presence of p-frames change pts == dts? Since p-frames only depend on an earlier frame, can't they be presented as soon as they're decoded? Tony _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
