[FFmpeg-devel] [Bug] Problem on remuxing AVC in mkv to mp4, how to fix it?

[Michael Niedermayer]

On Wed, Aug 05, 2009 at 05:29:16PM -0700, Baptiste Coudurier wrote:
> On 08/05/2009 04:01 PM, Michael Niedermayer wrote:
>> On Thu, Aug 06, 2009 at 12:46:08AM +0200, Aurelien Jacobs wrote:
>>> On Tue, Aug 04, 2009 at 03:09:18PM -0700, Baptiste Coudurier wrote:
>>>
>>> I guess your reply wasn't intended only for me ?
>
> Not really, I think you know that we have an h264 parser :)
>
>>>> On 8/4/2009 3:00 PM, Aurelien Jacobs wrote:
>>>>> This is already known as issue807 [1].
>>>>>
>>>>>> Since matroska does not provide dts (mp4 does), ffmpeg assumes dts = 
>>>>>> pts, which is completely wrong if b-frames are used.
>>>>>> Is that where the problem is and can anybody give suggestions on how 
>>>>>> to fix that?
>>>>> IIRC the problem is that FFmpeg is missing a h264 parser that would
>>>>> generate dts for streams which don't have it.
>>>> FFmpeg already has a h264_parser, it does not work with MKV bitstream
>>>> however.
>>> I know we have a h264_parser but AFAIK it is not able to generate any 
>>> dts.
>>> Is Matroska the only format storing h264 without dts ?
>>
>> nut doesnt store dts either, but nut defines how one can calculate dts 
>> from
>> pts and the decoder delay that is a mandatory syntax element in nut.
>> This is of course independant of the used codec so the codec id or 
>> bitstream
>> never has to be touched for it ...
>
> Well bpyramid + nut + stream copy fails in the same way.

but not for the same reason ...
with nut the bug is in lavf/ffmpeg failing to find the decoder delay
in the stream copy case i _think_
to fix that the h264 parser would have to figure out has_b_frames and
av_find_stream_info() would have to wait until the parser did that



>
> h264 parser and compute_pkt_fields generates dts for mpeg ts/ps because 
> parser supports this bitstream format, but not mkv format.

the parser does sadly not fully support mpeg ts/ps, just the most common
case.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090806/8a6a3df1/attachment.pgp>