Re: [FFmpeg-user] Problems with mpegts and long running stream

[Reuben Martin]

On Wednesday, May 31, 2017 3:09:06 PM CDT Mathias Schneider wrote:
> During my search for a solution, I found this patch here:
> https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit
> 
> I’ve patched my ffmpeg with it and it seems to solve my issue!
> 
> Question: Did I something wrong or is there really a problem inside ffmpeg
> mpegts for long duration streams? And is this patch a correct solution?
> 

File a bug report and include a link to the patch.
-Reuben
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Problems with mpegts and long running stream

[Mathias Schneider]

Hello,

I have the following setup:
a mpegts stream is built by a gstreamer pipeline and re-muxed by ffmpeg. I want 
to use the rich feature set of the ffmpeg mpegts-muxer (i.e. fill null-packets 
into my mpegts stream), therefore I’ve chosen this setup.
ffmpeg version: 3.3 (latest static build for Linux from ffmpeg.org)
gstreamer version: 1.10
OS: Ubuntu 16.04

Example:

Start ffmpeg - it will wait for incoming stream from gstreamer:
ffmpeg -re -buffer_size 256 -i rtp://127.0.0.1:2335?listen -c copy -muxrate 
6000k -f mpegts  -mpegts_flags system_b udp://239.200.0.82:1234?pkt_size=1316

Start gstreamer:
 gst-launch-1.0 -e -m -v videotestsrc is-live=true name=vsource pattern=18 ! 
videoscale ! videoconvert ! videorate ! 
video/x-raw,width=1280,height=720,framerate=25/1 ! queue ! videoconvert ! 
videoscale ! videorate ! x264enc bitrate=5000 threads=0 byte-stream=true 
key-int-max=50 ! video/x-h264,profile=high ! queue ! h264parse ! mpegtsmux 
alignment=7 name=strmux ! rtpmp2tpay ! udpsink async=false sync=false 
host=127.0.0.1 port=2335

Everything works fine for around 1 day - 26,5 hours to be exact. Then, ffmpeg 
fires a lot of warnings, saying "Non-monotonous DTS in output stream“. The 
first of these messages gives a hint to the problem:

[mpegts @ 0x4f21ba0] Non-monotonous DTS in output stream 0:0; previous: 
8584531106, current: -5399886; changing to 8584531107. This may result in 
incorrect timestamps in the output file.

There is a overflow in the mpegts PCR-field (33 bits), I guess. Is there a way 
to make ffmpeg dealing correctly with this overflow?
I’ve already tried the options "-copyts" and "-copytb 1“ -  but without 
success. 

During my search for a solution, I found this patch here: 
https://github.com/arut/ffmpeg-patches/blob/master/mpegts-33bit

I’ve patched my ffmpeg with it and it seems to solve my issue! 

Question: Did I something wrong or is there really a problem inside ffmpeg 
mpegts for long duration streams? And is this patch a correct solution?

Thanks,
Mathias

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] need help in reducing the stream start latency in a network enviroment

[Ratheendran R]

Hi All,

I am wrote an app which reads elementary streams of encoded audio/video and
mux them into mpegts stream subsequently write to unix domain socket as
client, an Unix socket  server app using  libwebsocket takes this streams
and send it to websocket server.

Now this works as expected, currently mpegts stream start latency is ~ 10
sec.


Also this is an embedded system use case and encoding happens through
hardware accelarators on soc fixed properties.I would like to know if we
can further  reduce the size of library and bypass redundant task like
probe and parsing metadata of mpegts streams.

options used for configuring ffmpeg
--enable-decoder=h264  --enable-decoder=aac --enable-bsf=h264_mp4toannexb
---enable-muxer=mpegts --enable-protocol=unix

can any one in the forum share their experience on fixing the high latency
on mpegts streaming.

Thanks,
Ratheendran
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Rodolfo Medina  writes:

> Rodolfo Medina  writes:
>
>> Moritz Barsnick  writes:
>>
>>> On Wed, May 31, 2017 at 13:10:18 +0200, Cley Faye wrote:
 A shot in the dark here since I didn't have the patience to look at how
 -write_id3v1 work; but if I remember correctly, id3v1 tags are actually
 appended at the end of the mp3 stream in such a way that some older player
 would even play them, causing a small burst of audio at the end of such
 file.
 
 If ffmpeg really doesn't handle them when reading the stream, it would
 explain why 1- they get copied during stream copy, 2- why older tag would
 still show up first, and maybe also 3- why the new tag would show up after
 initial playing of the file, if the reader actually move from the end of
 the file to detect them after reading.
>>>
>>> That was my assumption, and why I suggested using the additional
>>>option. But I have had enough of shooting in the dark. I created a file with
>>>both v1 and v2 ID3 tags: $ ffmpeg -f lavfi -i anoisesrc -c:a libmp3lame
>>>-metadata title='Where is this found?' -write_id3v1 1 -t 1 -ac:a 1 -b:a 24k
>>>tmp/id3tagtest.mp3
>>>
>>> and converted it in three different ways: $ ffmpeg -i tmp/id3tagtest.mp3
>>> -metadata title='This is the new tag!' -c copy
>>> tmp/id3tagtest_copied_and_new_matadate_no_explicit_id3v1.mp3 $ ffmpeg -i
>>> tmp/id3tagtest.mp3 -write_id3v1 1 -metadata title='This is the new tag!' -c
>>> copy tmp/id3tagtest_copied_and_new_matadate_explicit_id3v1.mp3 $ ffmpeg -i
>>> tmp/id3tagtest.mp3 -map_metadata -1 -c copy
>>> tmp/id3tagtest_copied_and_map_metadata_minus_1.mp3
>>>
>>> and apparently ffmpeg *always* overwrites or at least deletes the old
>>> ID3v1 tag. None of the three resulting files contained a leak of the
>>> old tag. (Inspected with "strings".) Period, 'nuff said.
>>>
>>> So, unless I missed something, it's the player's fault.
>>
>>
>> It seems so.  Sorry for having engaged people in a problem that does not
>> concern ffmpeg.  Now I changed not only tags, but also file names and the
>> player still sees old file names.  When I click over them to listen to them,
>> another song is played in place of them.  It's sort of been crazy (after
>> having driven *me* crazy! ;-) ).
>
>
> ...then, after a while, say some hours, it suddenly detects the changes and
> shows the right new file names and tags.  So it seems that Moritz was right
> when speaking of some sort of `cache' my mplayer is doing...

...Unless this caching problem is not concerning the USB stick memory
though...  Possibile?

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Moritz Barsnick  writes:

> On Wed, May 31, 2017 at 13:56:40 +0100, Rodolfo Medina wrote:
>> well, how could I work it out...?
> [...]
>> ...then, after a while, say some hours, it suddenly detects the changes and
>> shows the right new file names and tags.  So it seems that Moritz was right
>> when speaking of some sort of `cache' my mplayer is doing...
>
> https://youtu.be/nn2FB1P_Mn8
>
> Sorry, I truly couldn't resist.

Yes, I did try turning it off and then on again... :-) 


> Honestly: no clue. What sort of player
> do you have? (This isn't the place to discuss this though. ;-))

I don't know, it came with the car, as part of it...  It sounds perfectly...
;-) 

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Moritz Barsnick]

On Wed, May 31, 2017 at 13:56:40 +0100, Rodolfo Medina wrote:
> well, how could I work it out...?
[...]
> ...then, after a while, say some hours, it suddenly detects the changes and
> shows the right new file names and tags.  So it seems that Moritz was right
> when speaking of some sort of `cache' my mplayer is doing...

https://youtu.be/nn2FB1P_Mn8

Sorry, I truly couldn't resist. Honestly: no clue. What sort of player
do you have? (This isn't the place to discuss this though. ;-))

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Rodolfo Medina  writes:

> Moritz Barsnick  writes:
>
>> On Wed, May 31, 2017 at 13:10:18 +0200, Cley Faye wrote:
>>> A shot in the dark here since I didn't have the patience to look at how
>>> -write_id3v1 work; but if I remember correctly, id3v1 tags are actually
>>> appended at the end of the mp3 stream in such a way that some older player
>>> would even play them, causing a small burst of audio at the end of such
>>> file.
>>> 
>>> If ffmpeg really doesn't handle them when reading the stream, it would
>>> explain why 1- they get copied during stream copy, 2- why older tag would
>>> still show up first, and maybe also 3- why the new tag would show up after
>>> initial playing of the file, if the reader actually move from the end of
>>> the file to detect them after reading.
>>
>> That was my assumption, and why I suggested using the additional option. But
>>I have had enough of shooting in the dark. I created a file with both v1 and
>>v2 ID3 tags: $ ffmpeg -f lavfi -i anoisesrc -c:a libmp3lame -metadata
>>title='Where is this found?' -write_id3v1 1 -t 1 -ac:a 1 -b:a 24k
>>tmp/id3tagtest.mp3
>>
>> and converted it in three different ways: $ ffmpeg -i tmp/id3tagtest.mp3
>> -metadata title='This is the new tag!' -c copy
>> tmp/id3tagtest_copied_and_new_matadate_no_explicit_id3v1.mp3 $ ffmpeg -i
>> tmp/id3tagtest.mp3 -write_id3v1 1 -metadata title='This is the new tag!' -c
>> copy tmp/id3tagtest_copied_and_new_matadate_explicit_id3v1.mp3 $ ffmpeg -i
>> tmp/id3tagtest.mp3 -map_metadata -1 -c copy
>> tmp/id3tagtest_copied_and_map_metadata_minus_1.mp3
>>
>> and apparently ffmpeg *always* overwrites or at least deletes the old
>> ID3v1 tag. None of the three resulting files contained a leak of the
>> old tag. (Inspected with "strings".) Period, 'nuff said.
>>
>> So, unless I missed something, it's the player's fault.
>
>
> It seems so.  Sorry for having engaged people in a problem that does not
> concern ffmpeg.  Now I changed not only tags, but also file names and the
> player still sees old file names.  When I click over them to listen to them,
> another song is played in place of them.  It's sort of been crazy (after
> having driven *me* crazy! ;-) ).


...then, after a while, say some hours, it suddenly detects the changes and
shows the right new file names and tags.  So it seems that Moritz was right
when speaking of some sort of `cache' my mplayer is doing...

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Moritz Barsnick  writes:

> On Wed, May 31, 2017 at 13:10:18 +0200, Cley Faye wrote:
>> A shot in the dark here since I didn't have the patience to look at how
>> -write_id3v1 work; but if I remember correctly, id3v1 tags are actually
>> appended at the end of the mp3 stream in such a way that some older player
>> would even play them, causing a small burst of audio at the end of such
>> file.
>> 
>> If ffmpeg really doesn't handle them when reading the stream, it would
>> explain why 1- they get copied during stream copy, 2- why older tag would
>> still show up first, and maybe also 3- why the new tag would show up after
>> initial playing of the file, if the reader actually move from the end of
>> the file to detect them after reading.
>
> That was my assumption, and why I suggested using the additional
> option. But I have had enough of shooting in the dark. I created a file
> with both v1 and v2 ID3 tags:
> $ ffmpeg -f lavfi -i anoisesrc -c:a libmp3lame -metadata title='Where is this
> found?' -write_id3v1 1 -t 1 -ac:a 1 -b:a 24k tmp/id3tagtest.mp3
>
> and converted it in three different ways: $ ffmpeg -i tmp/id3tagtest.mp3
> -metadata title='This is the new tag!' -c copy
> tmp/id3tagtest_copied_and_new_matadate_no_explicit_id3v1.mp3 $ ffmpeg -i
> tmp/id3tagtest.mp3 -write_id3v1 1 -metadata title='This is the new tag!' -c
> copy tmp/id3tagtest_copied_and_new_matadate_explicit_id3v1.mp3 $ ffmpeg -i
> tmp/id3tagtest.mp3 -map_metadata -1 -c copy
> tmp/id3tagtest_copied_and_map_metadata_minus_1.mp3
>
> and apparently ffmpeg *always* overwrites or at least deletes the old
> ID3v1 tag. None of the three resulting files contained a leak of the
> old tag. (Inspected with "strings".) Period, 'nuff said.
>
> So, unless I missed something, it's the player's fault.


It seems so.  Sorry for having engaged people in a problem that does not
concern ffmpeg.  Now I changed not only tags, but also file names and the
player still sees old file names.  When I click over them to listen to them,
another song is played in place of them.  It's sort of been crazy (after having
driven *me* crazy! ;-) ).

I know I shouldn't ask, but...  Do you know how this is possibile and...  well,
how could I work it out...?

Thanks, cheers

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Moritz Barsnick]

On Wed, May 31, 2017 at 11:37:50 +0100, Rodolfo Medina wrote:

> Now, you listers say that the problem is in that ffmpeg works with
> id3v2 tags whereas my car's mp3 reader does it with id3v1.

I said I *suspect*. What do I know. With your newest explanation, that
might not even be the case at all.

> Further tests show that changes in tags are actually detected by the reader 
> but
> with a delay: in a first moment they are not, then I `play' again with tags
> using ffmpeg and then the reader finally reads them...

One might now even suspect that your car's reader does some sort of
caching. (Based on what? File names?) So what happens if you put back
the original files? Does it still see the new tags?

That's why I suggested:
- using some tool which can give an authoritive view of *all* contained
  tags (and not rely on ffmpeg, the conversion tool, and the car player
  to give you all your information);
- using a dedicated tool made for tags.

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Cley Faye]

2017-05-31 12:37 GMT+02:00 Rodolfo Medina :

> Further tests show that changes in tags are actually detected by the
> reader but
> with a delay: in a first moment they are not, then I `play' again with tags
> using ffmpeg and then the reader finally reads them...
>

​A shot in the dark here since I didn't have the patience to look at how
-write_id3v1 work; but if I remember correctly, id3v1 tags are actually
appended at the end of the mp3 stream in such a way that some older player
would even play them, causing a small burst of audio at the end of such
file.

If ffmpeg really doesn't handle them when reading the stream, it would
explain why 1- they get copied during stream copy, 2- why older tag would
still show up first, and maybe also 3- why the new tag would show up after
initial playing of the file, if the reader actually move from the end of
the file to detect them after reading.

What I'd suggest first is to try transcoding mp3 to mp3 instead of using
stream copy, just to make sure this actually destroy the existing id3v1
tags. If it does, then ffmpeg most likely just ignore these tag when
reading, making any attempt to "just" modify them kinda futile when copying.

(also, on your output file, you can open the file with some form of text
editor and jump at the end of the file, to check if multiple TAG section
are present. They'll be mostly in plain text.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Rodolfo Medina  writes:

> Moritz Barsnick  writes:
>
>> On Mon, May 29, 2017 at 18:37:31 -0400, Ron Sparks wrote:
>>> > ... I also tried to remove all the tags with:
>>> >   $ ffmpeg -i input.mp3 -map 0:a -map_metadata -1 -c copy out.mp3
>>> > and then put them again, but the problem remains...
>>> 
>>> I suspect the problem might be that ffmpeg works with the id3v2 tags, 
>>> while your mp3 reader works with the id3v1 tags.
>>
>> I had the same thought, but why would ffmpeg, when remuxing, re-insert
>> the original id3v1 tags? Perhaps they're considered part of the stream,
>> *then* they would survive "-c:a copy".
>>
>> You may want to try adding "-write_id3v1 1", as hinted in the docs:
>> https://www.ffmpeg.org/ffmpeg-formats.html#mp3
>>
>> In both cases, that should either drop the metadata or insert both
>> versions. (I didn't manage to test, because I don't have any tools at
>> hand which expose both/all types of tags in MP3 files. exiftool should
>> manage.)
>>
>> Other suggestion (never confirmed):
>> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-June/001365.html
>>
>> Actually, there are so many forms of tags (incl. EXIF), metadata, and
>> so on, that other tools may be much more suitable for such operations.
>>
>> Cheers,
>> Moritz
>>
>> P.S.: I found "-map_metadata -1" on lists and superuser.com, but
>>   neither in the docs nor the wiki. Hmmm.
>
>
> Unfortunately "-write_id3v1 1" seems to have no effect.  I wish I could
> understand what the problem is.  Let input.mp3 be our file.  I do:
>
>  $ ffmpeg -i input.mp3 - c copy -metadata composer="Bach" output.mp3
>  $ mv -vi output.mp3 input.mp3
>
> , then get on my car and the reader reads fine the `composer' tag as `Bach'.
> Then I remember that J. S. Bach had children who were composers as well, get
> off the car, go to the PC and do:
>
>  $ ffmpeg -i input.mp3 - c copy -metadata composer="Bach J. S." output.mp3
>  $ mv -vi output.mp3 input.mp3
>
> .  Then I get back to the car and the reader keeps on reading simply `Bach'
> instead of `Bach J. S.'  I.e., it does not see the change occurred.  Now, you
> listers say that the problem is in that ffmpeg works with id3v2 tags whereas
> my car's mp3 reader does it with id3v1.  But, if so, why does it read them
> correctly the first time they are created and not the second time, when they
> have been changed?  Besides, it seems that sometimes, when the above ffmpeg
> command is repeated many times, at least the change is somewhat by my reader
> finally seen: but only after repeating it at least twice.


Further tests show that changes in tags are actually detected by the reader but
with a delay: in a first moment they are not, then I `play' again with tags
using ffmpeg and then the reader finally reads them...

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] id3 tags not really removed?

[Rodolfo Medina]

Moritz Barsnick  writes:

> On Mon, May 29, 2017 at 18:37:31 -0400, Ron Sparks wrote:
>> > ... I also tried to remove all the tags with:
>> >   $ ffmpeg -i input.mp3 -map 0:a -map_metadata -1 -c copy out.mp3
>> > and then put them again, but the problem remains...
>> 
>> I suspect the problem might be that ffmpeg works with the id3v2 tags, 
>> while your mp3 reader works with the id3v1 tags.
>
> I had the same thought, but why would ffmpeg, when remuxing, re-insert
> the original id3v1 tags? Perhaps they're considered part of the stream,
> *then* they would survive "-c:a copy".
>
> You may want to try adding "-write_id3v1 1", as hinted in the docs:
> https://www.ffmpeg.org/ffmpeg-formats.html#mp3
>
> In both cases, that should either drop the metadata or insert both
> versions. (I didn't manage to test, because I don't have any tools at
> hand which expose both/all types of tags in MP3 files. exiftool should
> manage.)
>
> Other suggestion (never confirmed):
> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2011-June/001365.html
>
> Actually, there are so many forms of tags (incl. EXIF), metadata, and
> so on, that other tools may be much more suitable for such operations.
>
> Cheers,
> Moritz
>
> P.S.: I found "-map_metadata -1" on lists and superuser.com, but
>   neither in the docs nor the wiki. Hmmm.


Unfortunately "-write_id3v1 1" seems to have no effect.  I wish I could
understand what the problem is.  Let input.mp3 be our file.  I do:

 $ ffmpeg -i input.mp3 - c copy -metadata composer="Bach" output.mp3
 $ mv -vi output.mp3 input.mp3

, then get on my car and the reader reads fine the `composer' tag as `Bach'.
Then I remember that J. S. Bach had children who were composers as well, get
off the car, go to the PC and do:

 $ ffmpeg -i input.mp3 - c copy -metadata composer="Bach J. S." output.mp3
 $ mv -vi output.mp3 input.mp3

.  Then I get back to the car and the reader keeps on reading simply `Bach'
instead of `Bach J. S.'  I.e., it does not see the change occurred.  Now, you
listers say that the problem is in that ffmpeg works with id3v2 tags whereas my
car's mp3 reader does it with id3v1.  But, if so, why does it read them
correctly the first time they are created and not the second time, when they
have been changed?  Besides, it seems that sometimes, when the above ffmpeg
command is repeated many times, at least the change is somewhat by my reader
finally seen: but only after repeating it at least twice.

Thanks,

Rodolfo

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".