Try this: Add -dts_delta_threshold 0 *before* the input and retest.
On Sun, 23 Feb 2020, 16:27 Crazy Red Elephant via ffmpeg-user, <
ffmpeg-user@ffmpeg.org> wrote:
> I tried adding "-fflags +ignpts" before input but that didn't help, there
> are still DTS warnings, however, this time the values
On 04/06/2020 10:01 AM, Crazy Red Elephant via ffmpeg-user wrote:
So what do you think, Mark? I also noticed that if I use 1.2 version of ffmpeg there are
no DTS errors and no dropping frames. The result file though acts weird when I try to
create gifs from it for example. My gif creation
So what do you think, Mark? I also noticed that if I use 1.2 version of ffmpeg
there are no DTS errors and no dropping frames. The result file though acts
weird when I try to create gifs from it for example. My gif creation software
detects like 15 fps in it while "normal" videos give me the
Thanks, CRE. Now I know.
On 04/01/2020 09:38 AM, Crazy Red Elephant via ffmpeg-user wrote:
Hi Mark, the option is called "Fix bitstream timing info", it's in the "Timestamps and default
duration" box which is on the right side of the "Input" tab...
On Sunday, March 15, 2020 3:41 PM, Mark
Hi Mark, the option is called "Fix bitstream timing info", it's in the
"Timestamps and default duration" box which is on the right side of the "Input"
tab...
‐‐‐ Original Message ‐‐‐
On Sunday, March 15, 2020 3:41 PM, Mark Filipak
wrote:
> On 03/15/2020 09:02 AM, Crazy Red Elephant
On 03/15/2020 09:02 AM, Crazy Red Elephant via ffmpeg-user wrote:
Are they actually disruptive, or could you just keep the original stream as is,
knowing 1 out of 120 frames or something will be dropped when playing back?
To me, yes. I know some other users also reported something about
> Are they actually disruptive, or could you just keep the original stream as
> is, knowing 1 out of 120 frames or something will be dropped when playing
> back?
To me, yes. I know some other users also reported something about playback
issues numerous times but the stream provider doesn't
Hi,
> I tried adding "-fflags +ignpts" before input but that didn't help, there are
> still DTS warnings, however, this time the values are not equal for some
> reason (except the first pair)
I think igndts is more likely to affect the result but not sure in what way.
Since you have bad
Am Di., 11. Feb. 2020 um 23:22 Uhr schrieb Crazy Red Elephant via
ffmpeg-user :
> Here is the console output
Sadly not, if you need support here, please always provide the command line
you tested together with the complete, uncut console output, don't forget to
test current FFmpeg git head,
On 2/23/2020 5:15 AM, Crazy Red Elephant via ffmpeg-user wrote:
Guys please, I still have not found a solution and I'm so desperate :-( I asked
this question on multiple sites and nobody is helping...
Perhaps nobody has help to give?
(As has been said many times, please do not top-post on
I tried adding "-fflags +ignpts" before input but that didn't help, there are
still DTS warnings, however, this time the values are not equal for some reason
(except the first pair):
[mp4 @ 01a902a100c0] Non-monotonous DTS in output stream 0:0; previous:
6030, current: 6030; changing to
Guys please, I still have not found a solution and I'm so desperate :-( I asked
this question on multiple sites and nobody is helping...
‐‐‐ Original Message ‐‐‐
On Wednesday, February 12, 2020 12:44 AM, Ted Park
wrote:
> > 4. A general question - is there any difference between (a)
> 4. A general question - is there any difference between (a) decrypting all
> .ts parts separately, then concatenating them into one big .ts file and
> remuxing it into .mp4 and (b) concatenating all encrypted .ts parts first,
> then decrypting the big .ts result file and then remuxing it into
I have a number of .ts segments (AES-128 encrypted), .m3u8 chunklist for them
and a key to decrypt them.
My goal is to losslessly remux these .ts segments into one .mp4 file with no
playback issues.
I'm using the following command:
"ffmpeg -allowed_extensions ALL -i chunklist.m3u8 -c copy
14 matches
Mail list logo