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 <[email protected]> wrote: > > > On Feb 9, 2019, at 10:52 AM, Andriy Gelman <[email protected]> > 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
