> > > Ok, next problem - I have parsed all the command line parameters and > assigned them to the output context using: > > ret = avformat_write_header(ofmt_ctx, &opt); > > where opt contains the options dictionary. I know it is accepting this > because the returned dictionary is empty. Also, I know because it is > clearing out older .m4s segment files so that my disk doesn't fill up, so > it's accepting the window_size parameter. What it's not doing though, when > it runs, is outputting continuously updated manifest.mpd data - which if I > run ffmpeg with the same command line options I do get. So ultimately my > manifest.mpd file has a single segment in it, and my dash player never > plays anything. > > Looking through dashenc.c it would appear that the manifest should be > updated whenever write_packet is called, and I'm assuming this is called > because otherwise I wouldn't get the .m4s files being output. But > something must be failing here. Is there anyway I can see what options the > dash mux is using and why it wouldn't be outputting manifest updates? > > To write the frames out I am using the same line as in remuxing.c, namely: > > ret = av_interleaved_write_frame(ofmt_ctx, &pkt); > > should I just use av_write_frame? > > Regards, > Simon >
I've tried av_write_frame and the results are better, in that the manifest is updated each segment, but it still only has 1 segment in it, whereas if I use ffmpeg it has multiple segments, so still nothing plays in the browser. I don't see what can be going wrong here - it MUST have the same options because otherwise it would be forever adding new .m4s files without deleting the old ones. Cheers, Simon
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
