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 o
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
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, curren
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
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
>> whe
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'
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 mp
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
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
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.
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
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...
>>
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
13 matches
Mail list logo
