> On Dec 17, 2018, at 4:35 PM, Aleksey Skripka wrote:
>
> Evening!
>
> First of all, about playlist writeout:
> before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!)
> creating via .tmp file.
> after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become
>
Thanks for your attention, Adrian!
just one moment,
in hls_write_packet():
instead:
+if (use_temp_file) {
+hls_rename_temp_file(s, oc);
should be:
+if (use_temp_file && !(hls->flags & HLS_SINGLE_FILE))
+hls_rename_temp_file(s, oc);
or we a killing 'single
Evening!
First of all, about playlist writeout:
before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!)
creating via .tmp file.
after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become
dependent on +temp_file flag.
I suggest to return to original logic.
Non
Comments inline.
Regards
Adrian Guzowski
W dniu 17.12.2018 o 16:56, Aleksey Skripka pisze:
On 17 Dec 2018, at 18:45, Adrian wrote:
IMO temp_file+single_file should be mutually exclusive - why would you want to
have temp file when you're using only one file anyway? In this mode you would
eit
> On 17 Dec 2018, at 18:45, Adrian wrote:
>
> IMO temp_file+single_file should be mutually exclusive - why would you want
> to have temp file when you're using only one file anyway? In this mode you
> would either pool for file changes or just get updated playlist with new byte
> range (and
IMO temp_file+single_file should be mutually exclusive - why would you
want to have temp file when you're using only one file anyway? In this
mode you would either pool for file changes or just get updated playlist
with new byte range (and that one should be updated after video file). I
believe
Greetings!
Adrian,
with your variant of patch in case of '-hls_flags +temp_file+single_file' no
.tmp logic will be used.
not sure what is better, but all previous versions was doing so.
and also, i'm still sure, that for backward compatibility with all previous
versions, index.m3u8 should alway
Yeah, it does. My device is running as we speak and I do see tmp files being
created and renamed once done.
Regards
Adrian Guzowski17 gru 2018 16:19 Steven Liu napisał(a):
>
> > On Dec 17, 2018, at 23:11, Adrian wrote:
> >
> > Looks like it, though I've fixed some inconsistencies in file check
> On Dec 17, 2018, at 23:11, Adrian wrote:
>
> Looks like it, though I've fixed some inconsistencies in file checking too
> (i.e you're renaming file A, but checks file B for being able to be temp
> file) + added checking flag for HLS_SINGLE_FILE (it doesn't make sense to
> have HLS_TEMP_FIL
Looks like it, though I've fixed some inconsistencies in file checking
too (i.e you're renaming file A, but checks file B for being able to be
temp file) + added checking flag for HLS_SINGLE_FILE (it doesn't make
sense to have HLS_TEMP_FILE | HLS_SINGLE_FILE).
My bad I didn't check pending pat
> On Dec 17, 2018, at 22:23, Adrian wrote:
>
> Hello,
>
> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed
> stopped working.
> It looks like a regression introduced by
> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it
> cross-compi
11 matches
Mail list logo
