[FFmpeg-trac] #1487(avformat:new): ffmpeg's mpeg mux bug(s) never fixed...
FFmpeg
trac at avcodec.org
Sun Jan 6 20:07:15 CET 2013
#1487: ffmpeg's mpeg mux bug(s) never fixed...
------------------------------------+------------------------------------
Reporter: downuse | Owner:
Type: defect | Status: new
Priority: normal | Component: avformat
Version: git-master | Resolution:
Keywords: mpegps | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
------------------------------------+------------------------------------
Comment (by downuse):
Replying to [comment:12 cehoyos]:
> I believe this was fixed, please test again.
---
Yes, scr is now begin with 0, but it's not continuous,
such as
00:00:00.00 (0)
00:00:00.00 (225)
00:00:00.01 (450)
00:00:00.01 (675)
00:00:00.01 (900)
00:00:00.01 (1125)
00:00:00.01 (1350)
00:00:00.50 (12233) -> it should be like 00:00:00.02
00:00:00.50
00:00:00.51
i think this line in avformat/mpegenc.c
line:985 scr= FFMAX(best_dts+1, scr);
cause the scr jmp.
and if it is possible, please do something with scr_ext, it's now 0
anywhere.
----
video stream should have both PTS and DTS in I and P frame, B frame only
have PTS because its PTS=DTS
PTS should have some time (like 00:00:00.04) later than DTS
the first PTS of each stream should be same,
and first PTS of video stream is AV_NOPTS_VALUE in current git head.
----
by the way, what do rel_space,premux_packet and predecode_packet mean...
i don't understand how to result "best_i".
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1487#comment:13>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list