On Sun, 17 Jan 2021, lance.lmw...@gmail.com wrote:
On Sun, Jan 17, 2021 at 03:30:15AM +0100, Marton Balint wrote:
On Sun, 17 Jan 2021, lance.lmw...@gmail.com wrote:
> On Sat, Jan 16, 2021 at 09:49:42AM +0100, Marton Balint wrote:
> > This reverts commit 6696a07ac62bfec49dd488510a719367918b9f7a.
> >
> > It is wrong to restrict timecodes to always contain leading zeros or for hours
> > or frames to be 2 chars only.
> Sorry, I think I was misunderstood by the following syntax description:
> syntax: hh:mm:ss[:;.]ff
>
> maybe it's better to change it to hour:minute:second[:;.]frame?
That would better reflect on what the code did before the patch.
>
> After revisiting the code, I think we may support more valid syntax for the timecode
> string:
> ss
> ss[:;.]ff
> mm:ss
> mm:ss[:;.]ff
> hh:mm:ss
> hh:mm:ss[:;.]ff
I don't like this idea much, it is good if we are strict about the timecode
format (e.g request all components to be present and no garbage after the
parsed string), the main reasons I suggested the revert are because timecode
has to support > 100 fps and >= 100 hours because our timecode API also has
support for such timecodes.
Sure, please revert it anyway.
Ok, thanks, reverted.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
