[FFmpeg-user] ffprobe with mpegts/udp

[Andriy Gelman]

To follow up, it is possible to send a binary file with upd/mpegts by
adding a timeout on the decoder:

#encoder
$ ffmpeg -f bin -i testfile.dat -c copy -f mpegts udp://127.0.0.1:6500

#decoder - start decoder first
$ ffmpeg -loglevel trace -timeout 10000000 -f mpegts -i udp://127.0.0.1:6500
-c copy -map 0 -f data out.dat

There are two reasons why a timeout is needed:
1. mpegts_read_header needs to buffer 8192bytes before decoding the header.
So if your binary file is short, the decoder will not be able to even get
past this point.
2. avformat tries to identify the type of codec used for the binary file by
calling probe_codec function. This call returns a low score for binary
data  (i.e. unknown codec), and so avformat continues to buffer the packets
without releasing them. If you use the API you can skip probing the codec
by setting request_probe=0 in struct AVStream.  I do not know if there is a
similar command line expression.

The timeout forces an exit from these conditions, removes mpegts container
and correctly writes binary file.

Andriy


On Sat, 9 Feb 2019 at 21:26, Andriy Gelman <andriy.gelman at gmail.com> wrote:

> Thanks for your suggestion. Please see my response below.
>
> > Surely there were some errors in the output that might give some
> indication as to what is happening? I don’t see how stream > copying a text
> file into a TS would result in a working stream, I assume it has something
> to do with that.
>
> I've always believed that MPEGTS supports binary attachments. Please
> correct me if I'm wrong.
> Also, there is no reason why saving/reading .ts file works, whereas udp
> does not.
>
> > Are you running the commands in that order? If everything else was
> working, the first command would finish streaming very > quickly, and the
> second command would get nothing. You would have to start listening on the
> port first.
>
> The commands are in two shells. The decoding part is started first.
>
> Regards,
> Andriy
>
>
>
> On Sat, 9 Feb 2019 at 11:31, Ted Park <kumowoon1025 at gmail.com> wrote:
>
>>
>> > On Feb 9, 2019, at 10:52 AM, Andriy Gelman <andriy.gelman at gmail.com>
>> wrote:
>> >
>> > I also have the issue when trying to recover the binary data from the
>> > mpegts container via udp:
>> >
>> > For example, this works fine
>> >
>> > *$ echo "hello" > testfile.dat *
>> > *$ ffmpeg -f bin -i testfile.dat -c copy -f mpegts output.ts*
>> > *$ ffmpeg -f mpegts -i output.ts -c copy -map 0 -f data out.dat    #
>> > out.dat is the same as testfile.dat*
>> >
>> > However, when using udp, ffmpeg hangs (maybe expecting more data?):
>> >
>> > *$ ffmpeg -f bin -i testfile.dat -c copy -f mpegts udp://127.0.0.1:6500
>> > <http://127.0.0.1:6500>*
>> >
>> > *$ ffmpeg -f mpegts -i udp://127.0.0.1:6500 <http://127.0.0.1:6500> -c
>> copy
>> > -map 0 -f data out.dat*
>>
>> Surely there were some errors in the output that might give some
>> indication as to what is happening? I don’t see how stream copying a text
>> file into a TS would result in a working stream, I assume it has something
>> to do with that.
>>
>> > However, when using udp, ffmpeg hangs (maybe expecting more data?):
>>
>> Are you running the commands in that order? If everything else was
>> working, the first command would finish streaming very quickly, and the
>> second command would get nothing. You would have to start listening on the
>> port first.
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>
>