I am pasting one of the administrators of the list in hopes that this may be fixed in the transcoding.c example; it is a rather significant error.
On Tue, Nov 5, 2019 at 3:28 PM Vassilis <[email protected]> wrote: > This is not set indeed. Since there is no frame rate conversion I simply > used the input stream (ifmt_ctx->streams[stream_index]->avg_frame_rate). > > On Tue, Nov 5, 2019 at 3:25 PM Gonzalo Garramuño <[email protected]> > wrote: > >> I am glad someone finally answered this as I complained about this long >> time ago, with no answer. >> >> El 05/11/19 a las 09:36, Vassilis escribió: >> >> Well that did the trick! I can't thank you enough James and also second >> your comment that this should be updated in the transcoding.c example. >> Is there anything we can do about this? >> >> I still cannot get it to work. I get a floating point exception with the >> division of this in my code: >> >> stream->avg_frame_rate.num * stream->avg_frame_rate.den; >> >> Where are you guys setting the avg_frame_rate? The transcoding.c example >> never sets it. >> >> >> On Tue, Nov 5, 2019 at 2:03 PM James Crisafulli <[email protected]> >> wrote: >> >>> Hi, >>> >>> I used to have the same issue with my application, which I based on >>> transcoding.c (not transcoding but anyways, writing H264 to MP4 file). >>> You need to set the AVPacket duration field, for some reason it shows >>> this issue if you let it automatically set it (set to -1). >>> I had to do this both using libx264 and mpeg4 encoders. >>> >>> Example in my code from the muxing section: >>> >>> av_packet_rescale_ts(&packet, codecCtx->time_base, stream->time_base); >>> packet.stream_index = 0; >>> // probably best to write this as av_rescale_* functions, but this is >>> old code >>> // for example, if 25 FPS, and time_base is 12800, then packet.duration >>> = 12800 / 25 = 512 >>> packet.duration = stream->time_base.den / stream->time_base.num / >>> stream->avg_frame_rate.num * stream->avg_frame_rate.den; >>> // now you can mux >>> ret = av_interleaved_write_frame(formatCtx, &packet); >>> >>> I am not sure why this is needed, I found this in another codebase with >>> a similar comment, and it fixed my issue. >>> >>> Might as well mention that in transcoding.c, it also doesn't set the >>> GLOBAL_HEADER flag at the right time, and as such you get a malformed file >>> if writing MP4 format. I noticed it wouldn't open in Adobe Premiere, and >>> Windows 10 Films & TV player, and ffprobe had warnings about it as well but >>> did manage to read it. >>> >>> // TOO LATE! has to be done before avcodec open!! In transcoding.c, it >>> does this after the call and as such the flags are ignored. >>> if (formatCtx->oformat->flags & AVFMT_GLOBALHEADER) >>> { >>> codecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER; >>> } >>> >>> To fix that, I have hard coded the flag early when I know I am writing >>> MP4, before avcodec_open(): >>> >>> codecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER; >>> AVDictionary *encoderOpts = nullptr; >>> ret = avcodec_open2(codecCtx, codecCtx->codec, &encoderOpts); >>> >>> And now everything works well for me. Hopefully it fixed the issues for >>> you as well. >>> Would be nice to see transcoding.c updated to fix these small issues as >>> it is used as a base by so many people looking into libav* development. >>> >>> - James >>> >>> On Tue, 5 Nov 2019 at 11:07, Vassilis <[email protected]> wrote: >>> >>>> This can not be reproduced with the ffmpeg cli, conversion works fine >>>> there. >>>> However it can be reproduced with transcoding.c for all input files. >>>> Additionally to what I mentioned, 29.96 fps test files result in 29.98 >>>> and 30 to 30.11. >>>> Another 24 fps file resulted in 24.03. The changes seem to be related >>>> with >>>> the duration of the file: the longer the file the shorter the marginal >>>> fps difference. >>>> The output frame rate can be determined with both fffmpeg -i as well as >>>> with >>>> QuickTime 7 and VLC. Like I mentioned, I have spent some time with >>>> investigating this >>>> and it looks like an issue with the correct conversion of the last >>>> frame; I was able >>>> to get different framerate values when tampering with the pts of the >>>> last frame >>>> but this looked like a nasty hack that I shouldn't be doing, plus it >>>> fails >>>> again when re-encoding the file. Here is the info from an input/output >>>> test file >>>> that has the frame rate changed from 24 fps to 24.03: >>>> >>>> Duration: 00:00:36.08, start: 0.000000, bitrate: 178309 kb/s >>>> Stream #0:0(eng): Video: dnxhd (DNXHD) (AVdn / 0x6E645641), >>>> yuv422p10le(tv, bt709/unknown/unknown), 1920x1080, 176160 kb/s, SAR 1:1 DAR >>>> 16:9, 24 fps, 24 tbr, 23976 tbn, 23976 tbc (default) >>>> >>>> Duration: 00:00:36.10, start: 0.000000, bitrate: 116072 kb/s >>>> Stream #0:0: Video: dnxhd (DNXHD) (AVdn / 0x6E645641), yuv422p(tv, >>>> bt709/unknown/unknown), 1920x1080, 116526 kb/s, SAR 1:1 DAR 16:9, 24.03 >>>> fps, 24 tbr, 12288 tbn, 12288 tbc (default) >>>> >>>> You'll notice that there is a slight change in the duration as well, >>>> but this happens with the ffmpeg conversion with the cli as well. >>>> >>>> Let me know if you need more information and thanks for the help! >>>> >>>> >>>> On Tue, Nov 5, 2019 at 3:42 AM Carl Eugen Hoyos <[email protected]> >>>> wrote: >>>> >>>>> Am Di., 5. Nov. 2019 um 00:16 Uhr schrieb Vassilis < >>>>> [email protected]>: >>>>> > I am trying simply to perform a transcoding process using the >>>>> transcoding.c example from doc/examples. However I am seeing a very >>>>> strange >>>>> result (even when the example is not modified at all, ie not even changing >>>>> codecs); the transcoded file has a marginally different frame rate than >>>>> the >>>>> original file. For example for a frame rate of 24 fps I get 24.14 fps. I >>>>> also implemented this with the newer av_send/receive packet/frame >>>>> functions >>>>> to no avail. I would be most grateful for any insights, I've spent quite >>>>> some time trying to troubleshoot this. >>>>> >>>>> Can you reproduce the issue with the ffmpeg cli or only with >>>>> transcoding.c? >>>>> >>>>> Why do you think that the output frame rate is 24.14? What does ffmpeg >>>>> -i show for your input file? >>>>> >>>>> Carl Eugen >>>>> _______________________________________________ >>>>> 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". >>>> >>>> _______________________________________________ >>>> 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". >>> >>> _______________________________________________ >>> 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". >> >> >> >> _______________________________________________ >> Libav-user mailing >> [email protected]https://ffmpeg.org/mailman/listinfo/libav-user >> >> To unsubscribe, visit link above, or [email protected] with >> subject "unsubscribe". >> >> >> _______________________________________________ >> 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". > >
_______________________________________________ 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".
