[FFmpeg-user] AVCHD to QT and Avid

Thomas Worth dev at rarevision.com
Sat Sep 29 01:07:57 CEST 2012


On Fri, Sep 28, 2012 at 3:20 PM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>> The file you linked is compressed H.264 with B frames. I've
>> never had luck with ffmpeg / FFmbc when rewrapping H.264 with
>> B frames to MOV. Did you try MP4 with FFmbc? That's the only
>> way I've gotten it to work without the playback problems you
>> mention. ffmpeg still won't work even with MP4. You'll still
>> get the white frames because of what seems to be a bug in the
>> MOV muxer.
>
> Could you confirm with a high certainty that this
> was ever reported? (I ask because I think I only found
> out now about this problem.)

I don't know if it was reported, but it is definitely the case. I
don't know why there's a difference between MP4 and MOV, despite the
formats being nearly identical. QuickTime doesn't like AVC rewrapped
in MOV, although it will tolerate it rewrapped as MP4. This is the
case with both ffmpeg and FFmbc.


>> Carl, as a technical note the reason he is getting the white
>> frames at the head with ffmpeg output is because of a bug in
>> movenc.c. The the elst atom is being written with incorrect
>> values because it is confused by the negative DTS delay with
>> B frame media. Baptiste fixed this in FFmbc. The fix involves
>> modifying the start_time value based on I believe first_dts
>> and then adding packet.duration to it. I don't have the source
>> in front of me, but if you compare the source of ffmbc.c and
>> ffmpeg.c you'll see what I'm talking about.
>
> The last sentence sounds extremely unlikely to me,
> but see above...

Carl, there's an extremely easy and foolproof way to verify this.

Take Bouke's MTS file and rewrap it to MP4 with ffmpeg. Then rewrap it
to MP4 with FFmbc. You'll notice that FFmbc's output does not have the
"white frames" problem. Now look at the elst entries in the edts atom
in the video track in both files output by their respective programs.
See the difference?

first_dts and subsequent pts values influence the way elst entries are
written in the edts atom. Again, the problem stems from the fact that
B frame video has a "delay" of 2 or 3 frames between dts and pts. This
can be observed in the ctts atom, where the delta between dts and pts
is stored. The edts problem I believe is due to a discrepancy between
the values stored in ctts and the elst entries.

If this all sounds unlikely, it's probably because rewrapping H.264 to
MP4/MOV isn't the most popular use of ffmpeg and it has just simply
gone unreported. However, regardless of how likely/unlikely my
hypothesis is, the simple fact is this is still broken. Hopefully my
observations can benefit the project by saving some time in tracking
this bug down.

Perhaps what I'm about to say is obvious, but considering FFmbc is an
open source project and its output works in this situation, it might
be worth comparing the source between both projects to figure out why
ffmpeg's doesn't...


More information about the ffmpeg-user mailing list