Opened 5 years ago

Closed 4 years ago

#4485 closed defect (needs_more_info)

Rewrapping (codec copy) no longer work as expected.

Reported by: dfavor Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: Rewrapping use to produce playable videos, now videos are jittery. Last working version I have notes about was around ffmpeg-2.3.2 ish.

I'm trying to accomplish this - lossless rewrap of an .mts file to .mp4, where video stream is copied + audio stream is converted from AC3 to AAC.

Same jittery playback behavior occurs in latest Movist + Quicktime Player.

Both VLC + ffplay seem to work for some clips + fail for others.

Background.

1) PTS data is missing from .mts footage. https://trac.ffmpeg.org/ticket/974 covers this problem. This ticket mentioned here as it may relate to the problem in this ticket.

Adding -fflags +genpts has no effect, before the input file seems to have no effect.

The following messages are still reported with or without -fflags +genpts, which seems to be related to the problem I'll detail now.

[mp4 @ 0x7feea3831000] Codec for stream 0 does not use global headers but container format requires global headers
[mp4 @ 0x7feea3831000] Codec for stream 1 does not use global headers but container format requires global headers
[mp4 @ 0x7feea3831000] track 1: codec frame size is not set

2) I'll list several permutations under how to reproduce the error in this ticket.

http://DavidFavor.com/ffmpeg-bug-rewrap contains the following:

1) clip.mts - 60 sec starting footage, which was produced from original footage via...

ffmpeg -i infile.mts -c:v copy -c:a copy -t 60 clip.mts

2) clip.$codec.mp4 + associated log files for each run.

There are four examples - copy + fdk + faac + aac. All these fail

3) Expected results should have been smooth playing video, independent of whatever audio codec is used for transcoding audio to aac.

4) List of example runs... bad means jittery video...

okay: ffmpeg -y -i clip.mts -c:v copy -c:a copy clip.copy.mp4 > clip.copy.mp4.log 2>&1

bad: ffmpeg -y -i clip.mts -strict experimental -c:v copy -c:a aac clip.aac.mp4 > clip.aac.mp4.log 2>&1

bad: ffmpeg -y -i clip.mts -c:v copy -c:a libfaac clip.faac.mp4 > clip.faac.mp4.log 2>&1

bad: ffmpeg -y -i clip.mts -c:v copy -c:a libfdk_aac clip.fdk.mp4 > clip.fdk.mp4.log 2>&1

All this said, seems any audio operations, whether copy or transcode, should have no effect on video stream. Since container settings - fps + tbr + tbc - are the same on all output files.

What really occurs is any audio transcode produces jittery video.

Using various interjections of -copyts different places in command line seems to have no effect either.

Also, looking at this data, if there is another way to create a lossless video conversion from .mts to .mp4 (even if this requires using bitstream filters producing intermediate .ts files), that's fine, if someone can provide an example.

Every approach I try, even the bitstream filter w/.ts intermediates, seems to fail.

Change History (5)

comment:1 Changed 5 years ago by cehoyos

If you want to make this is a valid ticket please provide your failing command line together with the complete, uncut console output. Do not use external resources, post everything here on the bug tracker.

comment:2 Changed 5 years ago by cehoyos

And please recompile current FFmpeg git head with ./configure && make or ./configure --enable-gpl && make, a few of the configure options you are using make no sense and make debugging here more difficult.

comment:3 in reply to: ↑ description Changed 5 years ago by cehoyos

Replying to dfavor:

1) clip.mts - 60 sec starting footage, which was produced from original footage via...

ffmpeg -i infile.mts -c:v copy -c:a copy -t 60 clip.mts

Don't do that, use dd instead.

comment:4 Changed 5 years ago by compn

what player plays the resulting files jerky? what version of the player(s) are you testing with?

Version 0, edited 5 years ago by compn (next)

comment:5 Changed 4 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

Please reopen this ticket if you can at least provide your original sample infile.mts (or ~60 seconds cut with dd).

Note: See TracTickets for help on using tickets.