It doesnt seem that ffmpeg is parsing the variables inside media_seg_name
when passing my own "-media_seg_name".
Can somebody confirm?
*Ibrahim Tachijian*CEO Net Sat AB
Email: bar...@netsat.se
_
*Net Sat AB*Langelandsgatan 8, 164 43 K
ext @ 0x55d203242680] Statistics: 32918185804 bytes read, 0 seeks
Anyone know why the transcode is dying at exactly 86400 seconds?
--
*Ibrahim Tachijian*CEO Net Sat AB
Email: bar...@netsat.se
_
*Net Sat AB*Langelandsgatan 8, 164 43 Kista, Sweden
Office: +46 (0)8 408 394 53
and I look at the difference.
I am currently considering a stream to be "out of sync" when the difference
is above 1.
What does difference of 1 in start_pts actually mean? Is it wrong or
correct to consider A/V out of sync when there is a difference in start_pts
?
--
*Ibrahim Tachijian*
go about to
solve that issue.
Any ideas?
On Wed, Jun 20, 2018 at 9:59 AM Gyan Doshi wrote:
>
>
> On 20-06-2018 01:25 PM, Ibrahim Tachijian wrote:
>
> >
> > If the diff is > 1 then I am considering the audio to be out of sync and
> > restart the process.
Hey,
So this is a problem that has been bugging me for years.
1. The source is udp and the actual source is satellite.
2. Knowing its satellite we also know the stream won't be 100% perfect,
there will be losses.
3. Tranacoding with h264 and fdk-aac and outputting to hls.
The problem is that aft
Hey,
I use live_start_index to control which segment ffmpeg starts with on a HLS
live stream. This is working as expected.
However, when the input file is NOT a HLS live stream then using
"live_start_index"
of course gives you a "Option live_start_index not found" and then quits
ffmpeg.
I'd like
Hello,
We have problems with long-running ffmpeg processes where the input source
is sometimes lossy. The input comes from Satellite and therefore there will
always be some loss sometimes, there is nothing we can do about fixing the
input.
Our issue is that, after lossy input signal, the audio a
Hey,
When using an HLS input transcoding processes can really be speeded up
compared to having a udp input simply because you have a few segments
cached and can transcode immediately as fast as CPU allows.
This means that ffmpeg will also produce the playlist and first segments
really quickly. Th
irst m3u8 list segments, After update m3u8 to the end of the
>> +first m3u8 list, @command{ffmpeg} will cut segments
>> +at duration equ @code{hls_time}.
>> +
>> @item hls_time @var{seconds}
>> Set the target segment length in seconds. Default value is 2.
>> Se
even Liu :
>
> >
> >
> > 2016-08-26 10:34 GMT+08:00 Ibrahim Tachijian :
> >
> >> In my use case scenario I only need it for the very first couple of
> >> segments.
> >> After 5 segments it is not a problem anymore to have 5 second segments
> >&g
In my use case scenario I only need it for the very first couple of
segments.
After 5 segments it is not a problem anymore to have 5 second segments
only.
On Fri, Aug 26, 2016 at 4:25 AM Steven Liu wrote:
> 2016-08-26 10:10 GMT+08:00 Ibrahim Tachijian :
>
> > yes that is co
yes that is correct Steven.
On Fri, Aug 26, 2016 at 3:41 AM Steven Liu wrote:
> 2016-08-26 8:17 GMT+08:00 Ibrahim Tachijian :
>
> > Steven, I am not sure you understood me correctly or perhaps I did not
> > explain myself optimally.
> >
> > We still want to split b
s it clear what I am trying to explain?
What do you think? Do you know how this can be achieved?
Thanks,
On Fri, Aug 26, 2016 at 2:06 AM Steven Liu wrote:
> 2016-08-26 7:39 GMT+08:00 Ibrahim Tachijian :
>
> > Hello,
> >
> > I've been thinking about an option for &qu
Hello,
I've been thinking about an option for "hls_time" that is not currently
supported by FFMpeg and I would like feedback to if some of you may think
this is useful or utterly unnecessary.
I find scenarios where we sometimes want to create an HLS output and would
like the *first couple of segm
14 matches
Mail list logo
